Tag Archives: security

Stop Users using Stupid Passwords

Been some discussion recently on the WPUK mailing list after some recent mass attacks on WordPress Sites. Lots of good advice from people.

  • Do you need to to allow access from all IP’s
  • Do you need to be able to login all the time or can you say they never login a 2am in the morning so we can stop login at that time.
  • Keep up to date obviously
  • Changing default locations of login pages, wp-admin etc
  • using two factor authentication (yubikey mentioned)
  • captchas on login screen
  • blacklisting of visitors by IP address
  • renaming the default ‘admin’ user

All suggestions worth considering depending on your circumstances.
Someone mentioned about a user with a password of ‘password’, I wondered if there was a way of preventing users injuring themselves by using such a password. By default my current WordPress 3.5 allows a user to do pretty stupid stuff like create a user with a username of ‘e’ and a password of ‘password’.

Not added in list popular passwords that would pass as secure should do that. Could probably extend to exclude dictionary words not sure if its worth doing that.

Dave of interconnect.it mentioned a plugin called ‘better-wp-security’ which does quite a few other things as well, seems worth looking at, Dave had had it recommended to him. There are also a few similar plugins with more restricted scope that just stick to the password ‘force-strong-passwords’ and
‘enforce-strong-passwords’.
I’ve not tried these so I can’t recommend them, I bashed out my own because I was interested. Its probably not quite so client friendly as its called ‘Stop users using stupid passwords’, might have to rename that.

Seems something worth checking on especially as you create a new site. If the password isn’t towards the top of the list of ones a bot attacker might try, it will at least take them longer. Will also stop a human guessing it quite so easily as well.

SQL injection attacks

Was talking to my friend about a site he is working on that had been attacked by SQL injection. Its something that makes you think hes not an idiot, I better recheck I’m not creating sites that are vulnerable to attacks. If the client is annoyed if some idiot can put his weird video up over their homepage thats nothing to how embarrassed the developer of that site feels.

What is a SQL Injection attack

A SQL injection attack is where someone manages to inject SQL into a database query on your site in order to alter that query so they can modify the database for your site. They can then go on to inject undesirable data, delete your data or expose data you don’t want exposed.

What to do to stop it

There are a number of steps you can take to reduce the likely hood of a SQL injection attack happening to you. If your using ready made software such as WordPress or another CMS the manufacturers should have dealt with these vulnerabilities. That is one of the best reasons to use ready made software but you should keep it up to date.

  • Check input, filter it and escape it
  • Set the database up securely – so that that user can only access the information they need to and has the lowest amount of privileges they need
  • Parameterize your queries – so even with weird inputs the intent of the query can’t be changed.
  • Don’t display useful error information – to a user, but do log it for you to analyze later.
  • Encrypt sensitive data – even if someone gets into the database they won’t be able to use it.
  • Know your database – SQL injection can be pretty clever, and different databases have different vulnerabilities. SQL SERVER for example has some quite esoteric features that can do some pretty weird stuff, you need to be aware of that if your going to use it.

You can hire specialists to do penetration testing1 which may be worthwhile depending on your budget and the value of your data.

Its a great idea to review your database backup regime. The morning you wake up and find your database has been compromised is bound to be the day when you find there isn’t a backup to restore to.

1) They do insist on calling themselves ‘pen testers’ which just makes me laugh.

Web Application Security Checklist

Been assessing the vulnerabilities of a site I’m building at the moment and trying to come up with a list of potential vulnerabilities so that I can check that I’ve dealt with them all. This is where I’ve got to so far please point out any you think I’ve missed.

Errors

  • errors aren’t displayed, other than we just had an error if really necesary, not the details
  • errors are logged
  • if logged to files those files aren’t accessible by visitors

Only public viewable files are visible

  • access to any non public folders are restricted
  • includes, class definitions settings files etc.
  • if you were to try and access they would act like a resource that doesn’t exist

Parameter filtering

  • input isn’t trusted
  • input is filtered, escaped etc
  • output is escaped

SQL injection

  • query params are quoted, bound dealt with according to your database
  • the security of access to the database itself
  • database users
  • database server access

Vulnerabilities of software included

Any ready made systems, libraries used in the site are at the latest version and they don’t publish what version they are at. Including language and server software versions e.g. say ruby don’t say ruby 1.9

Cross site scripting

Origin of requests

  • where origin of requests should be via self make sure it is.

Brute force

  • login points throttle repeated requests in order to slow down dictionary attacks
  • log repeated login attempts by ip and useragent
  • block abusers according to blocking policy

Passwords

  • passwords are non dictionary words and of adequate length and variety of case and character
  • passwords are stored encrypted in a way that makes unencrypting them awkward if they were ever accessed.

Spam

  • all public forms have some form of captcha device
  • all public email addresses are obscured in some way

File system access

  • ftp, sftp, ssh users
  • file permissions are correct

Access with curl and more bot like access paths mirror that of normal browser based viewer or are more restricted.

Login

  • unsuccessful logins and successful logins are logged.

Monitoring of access and file modification times to check files havn’t been modified when they shouldn’t have been by some other than authorised source.

Well that is my first attempt I guess I can always add to it as I think of new issues and read more. Hopefully without getting too paranoid.

References