#web assessment

[advaiya]

To get best business opportunity with us. Choose best for your business.

[miscsecurity]

In-House Web Application Assessment Methodology

A lot of great documentation exists for web application assessment from an external or contracted pen-testing side, like that provided by SamuraiWTF. One area that I haven't found a lot of documentation on is the situation I happen to be, performing web assessments on in-house developed applications before they go on to a third party company for an assessment.

A lot of companies are in a situation that a Q/A tester might do the initial review, and then it may go on to an internal security team for an assessment.  Being in-house you have a lot of benefits that an external tester doesn't have, usually more time, a great understanding of how the application functions, and a safety net in having the external test to hopefully catch anything you've missed.  

Your goal should be to find everything, but to focus on the things that automated scanners and external testers with time constraints are not going to find.  These are logic errors, server and application misconfigurations, and session hijacking or accessing data that belongs to another user by other means.  You should have more context on the application, and unlike the external test, a majority of your test should be hand testing, not application scanners and other automated tools.  That being said, I like to cover my bases so I use a couple of them.

1. Nikto, this will identify typical misconfigurations on the server-side and may also help fingerprint vulnerable libraries.

2. SQLmap, good tool to help you find parameters worth playing with later on.

3. skipfish, check for a variety of issues as well as do some basic load testing of the application to make sure you won't be likely to DoS it.

4. Build a chain of proxies, I like to setup ratproxy on a machine, BURP suite on another, and Zed Attack Proxy on my workstation, so ZAP goes to BURP which goes to ratproxy which makes the real requests.  The reason you want to chain is to maximize the requests you are making.  Technically you could do this before running the above tools as well, but the type of requests sent by them typically yield some additional false positives.

5. Once you have your proxy chain its time to actually start the manual assessment.  If the application has a login, login and navigate through the application and attempt to use any functions offered, visit each page possible.  You will see information being logged in ZAP and it will also show any alerts it is detecting in real time.  If you are not seeing glaring issues, you may want to utilize ZAP's spider and scan features to ensure that everything has been visited.

6. Having navigated the application manually you should have a sense of application logic and be able to make educated guesses as to what types of input might cause an exception that can be exploited, or put the application in an unexpected state.  Does everything work as it should?  Maybe something got past QA. This is the step that you attempt manual SQL injection, cross site scripting, and cross site request forgery exploits.

7. Next let's test the security of the session.  For this we will use Firefox's Tamper Data Addon.  Make a request and tamper, is the application setting a cookie or session value?  If yes, that opens some possibilities and also note if a nonce is being used; if not, how is the application maintaining session state? What other values appear to be passed via GET and POST values, or via cookie settings?

8. Now I circle back.  I logout of the application.  Login, logout, and hit back, I shouldn't get logged back in, but if I do, the login screen is vulnerable to session replay attack.  Upon login, is my sessionid changing?  If not, let's test to see if the application is vulnerable to session fixation attacks by spawning a second browser on another computer, and using Tamper Data to spoof the first computers sessionid.  If you are able to view the data without authenticating, the application is vulnerable to session fixation attacks.  Note there are three ways session fixation can be made more difficult, changing sessionid upon login (and hopefully log out), using only HTTPS so an attacker would also need to compromise the SSL session granted this can be trivial, and is a nonce being used.

9. At this point, I utilize the other computer and login with another set of credentials and test session hijacking again.  Can the hijacking elevate privileges?  Next I test the variables, for example, if the application allows some users access to certain data, and not others, let's see how the application handles getting a request for data the user doesn't have permissions to.  If it shows the data, thats a big issue, and potentially opens up a can of worms for attacks.  If it does prevent unauthorized access, let's try to defeat that.  Next, lets try incremental and decremental attacks.  If you notice numbers or patterns, try creating something that should work, do you get access to something you shouldn't have?

10. Repeat, iterate, and repeat again.  Each pass you are getting more information and more familiarity with the application, this is where you are showing your value versus the vendor that is on a tight timeframe and budget.  Learn the application inside and out, research vulnerabilities of its programming language, application server, can something be exploited outside of the application, or through the application?  If any file browsing is offered in the application, is it vulnerable to directory traversal attacks?  

Of the OWASP Top 10, I'd say about half are easily found by automated tools, and the other, and a majority that don't make the Top 10 are found with manual testing.  Again, this is where taking time and being diligent adds value over a vendor, and also where you sometimes have the potential to find the most elaborate exploits.  While these may not be sexy for conferences if your company is not okay disclosing issues, these are the findings that reinforce the value you provide your company.

Once you have your method, apply it to other web applications you may use.  You will be amazed how many mature, commercial applications are vulnerable to the simplest of session fixation attacks with Tamper Data.  Session fixation often gets overlooked because of the use of HTTPS.  People overlook that even if it is not possible to compromise the SSL session, how many companies run a transparent proxy that is decrypting SSL, if they have their logging set high enough, the logs are providing you the session ids, compromise the proxy server and own the applications.