phillips321.co.uk

So it grinds my gears that every time I do a pentest I end up reporting the same sh!t every time. You’d think before I turn up you’d at least patch your kit, but nope!

Here’s a little Top 5 for web developers to consider doing before I break their kit. If you also want to look after your kit the application is hosted on I suggest you read this post; Things to do before a pentest – Infrastructure.

1. Secure communications. Many issues can be mitigated against by using a secure comms channel. Many modern web servers offer HTTPS and can forward all HTTP requests to the HTTPS port, so why not enable it? But ensure that the encrypted service is configured appropriately, and this means using a cert from a valid and trusted CA and not supporting SSLv2 or weak ciphers!
2. Input validation. This is where most attacks happen, you need to ensure that any user input is validated and correctly escaped, ensure that protection modules offered by Apache or IIS are enabled and ensure that any user input that is passed back to the user is HTML encoded. Client side validation using JavaScript is a viable form of input validation but this can be easily by bypassed so it’s important to ensure that all user input is validated server side; never trust the client!
3. Sessions. All to often we see sessions that are not terminated correctly after log out or the same session identifier used pre and post authentication. You’ll need to ensure that a user can log out of the web session (unless you’re using SSO) and that unused sessions time out after a set period. You need to make sure that any session identifiers cannot be guessed, are completely random, is changed after login/logout and that the session ID is updated server side.
4. Database Privileges. All too often I see applications connect to the database using the root account. There is no need for this. The application only ever needs to read, write and modify records from the application DB; it does not need the ability to create new DB accounts or to modify the privileges of existing DB accounts.
5. Account Enumeration. This is all too often overlooked but is an easy way for an attacker to identify valid accounts on the system. You’ll need to ensure that when a client tries to login and fails the error message is the same regardless of whether or not the account name was valid. This also applies to password reset functions such as entering an email address, regardless of a correct email address or not the response to the client should be the same.