Information and advice to avoid the top security risks found by NTA Monitor during testing in 2010.
- SQL injection: to address SQL issues, it is important that all user input is parameterised (where possible). Most databases and languages support parameterised queries (i.e. PREPARE for MySQL? and PreparedStatement? for Java). If prepared statements are not possible, it is important that all META characters (i.e. single quote) input be sanitised before being allowed to pass to the backend database (i.e. htmlspecialchars with ENT_QUOTES for PHP).
- Patch management: it is recommended that systems are updated with the latest service pack and patches. It is also suggested that a patch management policy to update IT systems on a frequent basis is implemented.
- Cross-site scripting: to avoid XSS, all areas of an application must be checked and sanitised against invalid character input where user input is required. All Meta characters and HTML tags (i.e. < >) should be restricted where possible before allowing it to the backend.
- Password issues: tighter restrictions must be placed on password length and more stringent controls on what users can choose as their password needs to be applied. This will help users protect their account more effectively. It would also be beneficial to provide some online documentation on choosing secure passwords. In addition, characters allowed in the password and all other fields submitted using web forms should be reviewed, taking care to filter out any characters, which may cause back-end systems to execute unwanted commands.
- Denial of Service (DoS Apache): if web servers are running a version of Apache Web Server that is vulnerable to a denial of service, appropriate patches should be applied or servers upgraded to the latest version.
- No account lockout mechanism: it is recommended locking accounts out after around three consecutive failed logon attempts. This will prevent attackers from being able to brute force accounts. To avoid locking an account out indefinitely, best practice is to lock a user out for a substantial amount of time e.g. between 30 mins and two hours after three incorrect attempts. There is a good chance that this won't affect the user, but will certainly hamper an attacker's progress.
- Static session ID is used before and after authentication: it is recommended that an old session ID is expired and a new session ID is issued after successful authentication.
- No, or weak, encryption: access to sensitive or confidential information should only be allowed over SSL. It is particularly important to ensure login form details are submitted to an HTTPS URL.