Some little things that you can just make habits:
- When you are testing fields instead of typing in names or cities use `~!@#$%^&*()-_=+[{]}\|;:'",<.>/? etc as a string. This will quite quickly highlight if there are any validation issues and if you get any unhandled errors it could indicate that there is a risk of XSS or SQL Injection. Handled validation errors are what is expected, what you don't want is it failing because of a Database error or when go the the view page that characters are missing or the HTML is broken.
- Also in the fields type <script type=“text/javascript”>alert('XSS');</script> and then go to the view page and if you see a JS alert people there is an issue with XSS on the site under test.
- If there is a login authenticated section try going to all the URLS while you aren't logged in, especially true if you are using a caching proxy. Yes it does happen and it is number 7 on the 2013 OWASP TOP 10.
Then there is raising your awareness:
- You shouldn't see any stack traces being display to the client. This information can be used by an attacker to glean additional information.
- Your error messages should be safe they shouldn't leak information. There shouldn't be information like code references, IPs, Server names, App Server names, Cities etc in the error messages.
- Login error messages shouldn't allow username enumeration and should just return the one error message regardless of the reason it can't log you in; OWASP has a cheat sheet on login and some testing info.
Another valuable thing that testers can do is to ask questions:
- Has and the architecture/design had a review from a security perspective?
- Is there penetration test planned, budgeted for, scheduled and a gated hurdle before Go Live?
- Are the developers aware of the OWASP Top Ten and actively putting in processes to avoid the issues that it outlines?
- Is HTTPS being used for everything that has a cookie or other sensitive information? Yes a cookie is highly sensitive and must be protected have a read about Firesheep if you have any doubt.
- Is there a list of all third party libraries being used? Is there a process in place to keep checking for updated versions?
If there is more time you can start doing some reading:
- If it is an ongoing project and there has been a previous penetration test done, have a look at that report and look for the same types of issues in the new functionality. This is particularly going to happen if no changes to the team's processes have been made to help support the development of a secure application. Have a look at the Microsoft Secure Development Lifecycle (SDL) which is a good framework for improving team practises around security.
- Have a look at the OWASP site and do some up skilling. There is a testing guide that can aid your testing. There are also a series of cheat sheets which can help in design and also testing.
0 comments:
Post a Comment