Testing for Authentication loop holes / bugs

Question

We've got a web application which is 99% complete prior to public beta, were currenlty securing the site from security perspective, locking down the server, db etc, one thing I'm concerned about but not really sure of the best way to test is for authentication loop holes.

For instance there a 3 user types - System admin, Staff, Client.

There are urls on the site that I would only want the System admin to be able to access, and there are other pages, that I would want everyone to access, but not view all of the data. System admin would be able to see everything, but Staff and Client would be able to see some content, similarly some pages would be read only for some users.

Is there a workflow for testing this, at the moment I've come up with a script that has the credentials of a each user type and goes to every url on the site trying to access pages and reports if it's able to see a page it's not meant to, similarly it checks for read / write data on the page.

• Is there anything else I should be checking for to make my authentication tests more robust ?

• Tulains Córdova: Remember that "I" in english is always capitalized.
• Cameron McKay: You could test the edge case of logging in as admin, logging out and logging in as client to make sure the permissions of admin don't carry forward. You might also want to check if a not logged in user is re-directed back to the login page if they visit a page that is not available to a guest.
• Eric: If securing your web application is 1%, I'd hate to see the other 99%.

Answer 1

Sounds like you have the ordinary stuff covered. If you know all the root entry points to the site, a simple spider can easily retrieve the set of pages reached by each of 4 kinds of users (don't forget anonymous), and determine whether the page retrieved has the extra sensitive content.

You don't have to worry too much about mistakes that wrongly block access. Your users will find those for you, and no harm is done. You need something extra for the admin pages and sensitive content that might be accessible when they shouldn't.

At some point you have to switch hats and try to break into your own site. The rules are: you get full access to the source code and a set of user names, but not the passwords. Can you retrieve any sensitive data or do any damage? If there are such vulnerabilities, you won't find them by dumb pounding on the keyboard. You have to think like a hacker.

• toasted_flakes: Better yet, hire one. It's often harder to break your own code.