Quick & Easy Wins to do some security testing

Well last week I lead a discussion at WeTest on Security isn't Scary. One thing that came easy quick wins which testers can do to to find the low hanging fruit to knock out some security issues earlier rather than later. These things shouldn't be too hard for a lot of testers and isn't too much of a learning curve or take up too much time when you are meant to be functional testing. This is not to replace a pen test, just some easy methods that can be employed to help find bugs early and add value without taking up too much time.

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.