If you’re interested in security testing web applications, these tips will help a non-security tester to consider some techniques to get started. The world of security testing is perhaps the most important, yet it’s often the most neglected aspect to testing. A lack of security testing opens an organization to business risks and could have severe implications to the financial future of a company. If you haven’t made security testing part of your repertoire, consider integrating it today into your regular test suite.
Consider these tips:
- Directory listing is enabled or disabled – If it is enabled then there might be a problem. You can see if it’s enabled or disabled by browsing into some directory, Example: http://example.com/images/ — If this directory lists all the image files in the directory then the directory listing is enabled. If it gives a message like “Directory listing denied” or there are no results even though there are files in it then it means it is disabled.
- HTML tags execution – You can do it on any of the text fields. Example: In “My Profile” page I will type <h1>Santhosh</h1> in the First Name text field and save the page. I see that my name is appearing in <h1> font size in “Welcome, Santhosh” text which means there is no validation being done which is security vulnerability as even the <script> tag could be executed resulting in XSS (Cross-site scripting) attack.
- Bypassing the mandatory fields – You can use Firebug add-on for Firefox to use this technique.
a. Install Firebug add-on
b. Press F12 (Windows) key to invoke Firebug
c. Use Inspect Element feature to highlight the mandatory field
d. The code gets highlighted when you inspect the UI element
e. Just delete the code for that mandatory field
f. Submit the form
If the form gets submitted, then it means that there is no validation on the server end or database end for the mandatory data. If it doesn’t and gives you an error message then it means it does validation on both the ends. - Token generation – When you initiate Forgot Password you will receive an e-mail with token, this token shouldn’t always be the same but, should randomly be generated every time and the length of the token shouldn’t be too short that it could be cracked. The token should expire once used and also there should be maximum hours when the token gets expired even when it’s not used. This applies even for registration token and any other modules where tokens are used.
- Error Messages / Error Information – If you have used WordPress login you can enumerate the username through the error message. When you enter correct username and password, the error message is such that it indicates that the username is right and only the password is wrong. When you enter both as wrong then it gives different error messages which indicates that the username is also wrong. So, here it is easy for the attacker or cracker to design his / her attacks accordingly. The error message which would read:
a. Your username and password did not match
b. We could not find your details on our database
c. Invalid username / password
The above messages can be tweaked but, I am speaking in terms of security here. Speaking about some system error messages, these are of potential risk when they reveal the directory structure or part of the SQL queries or any other sensitive information which would be a delicious meal for an attacker. Do not forget that even hackers are the end-users of web application. - Robots.txt – Want to know when a website is asking the bots to not index specific pages? Then robots.txt is your source. Example: http://google.com/robots.txt Sometimes this might help you getting to know the URL of admin page or any confidential information pages. This would help to do your tests for security.
- Guessing the admin pages: Let’s say you see a customer login, often times the admin page from where login could be done with the administrator privileges’ could be http://example.com/admin/ http://example.com/admin.aspx or something similar to the customer login. There are also brute force scanners for the directory structure. Find it out or how about writing your own brute force scanner?
- HTTPS or just HTTP – Analyze what kind of protocol needs to be used to access a specific module. Learn about Firesheep (By Code Butler) which could be used to steal the session of other people who are logged in using the same LAN that you are connected to. If HTTPS then it is hard to steal, if not then it’s too easy to steal.
- We, testers at Moolya have created a mind-map with add-ons which includes security testing category you might want to refer to http://moolya.com/blog/2011/03/04/addon-mindmap-for-testers-from-moolya/ — They will help you in doing more tests which could add value to your security testing (You will love them).
- Participate in discussions and learn from other security testers / hackers at http://bangalorehackers.com/ – Watch security related videos at http://securitytube.net/
- Account Lockout Policy – This is important for any login function. Different products have different account lockout policies. Example: Bank account might have 3 attempts. Most of the products do not have this policy but in my opinion it is required for any login function. Forgot Password can get a user the password in case if they forgot it, so why not have an account lockout policy to ensure brute force attacks cannot be employed by any attacker.
These tips are not all-inclusive but are a good start for newbies to get involved and get their feet wet in the world of security testing web apps. If you have any questions about these tips or security testing overall feel free to contact Santosh: Twitter: @santhoshst | Skype: santhosh.s.tuppad
About the Author
Santhosh Tuppad: Santhosh Tuppad is the Co-founder & Senior Tester of Moolya Software Testing Private Limited (www.moolya.com). He also recently won the uTest Top Tester of the Year 2010 apart from winning several testing competitions from uTest and Zappers. Santhosh specializes in the exploratory testing approach and his core interests are security, usability and accessibility amidst other quality criteria.
Santhosh loves writing and he has a blog at: http://tuppad.com/blog/. He has also authored several articles and crash courses. He attends conferences and confers with testers he meets. Santhosh is known for testing skills and if you are passionate in testing, feel free to contact him at: Twitter: @santhoshst | Skype: santhosh.s.tuppad