Going left
Another one of my favourite tests is to have one of the application administrators login legitimately, bookmark any administrative page (e.g., "add a new user page"), and log out. I test to make sure that the session expires upon logout by opening a browser and clicking on the bookmark. A surprisingly high number of times the application will automatically grant me administrator rights.
Another technique is looking for dead code that has been commented out, but not removed from the baseline. I'll login as a guest user -- or any user with limited rights -- and attempt to surf to dead code. Again, a lot of dead code is kept in baselines.
Quite often developers will build a startup page during development that is not intended for deployment -- one that bypasses the login process and sets up a test environment. When it comes time to release the system, typically Web programmers comment out the original call, or rename the page but leave the test page out in the Webroot. I also examine the code to determine if there are multiple login or startup screens and test to see which one allows me administrator access to the system without providing credentials. I'll also attempt to navigate outside the controls, especially if the developer put navigation guides. Usually, I can take a look at the browser history or cache to see where other users have navigated for guidance. Temporary Internet files provide a wealth of information if not cleared. If the application clearly wants me to go right, I test to ensure there are controls preventing me from going left.
May I, please
Generally developers aren't responsible for miss-set permissions -- unless the application was built relying on them. For example, if a Web application requires that a specific directory to be world writeable, or worse read, write, and execute for everyone, the application provides a perfect spot for hiding (and triggering, perhaps) malicious logic.
Many applications have directories for storing temporary reports. I will usually try traipsing through folders on the Web server by modifying the URL to get a feel for permissions. If the application provides ad hoc query capability (there are typically world writeable folders for storing results), I'll attempt to post an executable file there and then call it from the browser to see if it executes.
If the application provides any upload capability, I'll check for execute permissions. Very rarely should anyone have execute permissions to Web folders. Nor should a user be able to run executables on the server. If I can shell outside the application (which I often times can), any process spawned is generally owned by a privileged account, such as "oracle", "root", or "system" and has the rights of the owner. Potential problems arise if the application facilitates the uploading of data or fails to constrain access to the data once it is uploaded. Another common mistake is requiring weak permissions on upload directories.
Avoid vulnerabilities
While this list isn't all inclusive, it contains the common mistakes I've seen developers make when building Web-based applications. There are a few excellent resources for developers and testers wanting more information about common vulnerabilities. I strongly suggest that all developers read the OWASP report for 2004. You should also read the SANS top 20 list. While it is not specifically addressing Web applications, it will give developers an idea of what to defend against. Armed with this knowledge, you should be able to avoid most of the common "gotchas."
