Starting with a QA team that deals mainly with functional requirements testing and has little real security testing experience, what simple practical things should the QA team start doing to start thinking like an attacker?

A couple of examples that I can immediately think of are:

  1. use of special characters in text input fields, e.g. '%$<>|" etc.
  2. attempting to overflow text fields, e.g. aaaaaaaaaaaaaaaaaaaaaaaaaaaa...aaa
  3. edge cases, boundary conditions

6 Answers 6


I'd recommend to hire someone (or some developer could do that) to educate the QA team using OWASP Top 10 or WASC TC. If you want step-by-step guide how security testing should look like, you can use OWASP Testing Guide, which will give you pretty good picture.


To add to ewanm89's answer, a general approach to penetration testing is done by dividing the test up in different phases:

  • Planning
  • Discovery / Information Gathering
  • Attack
  • Reporting


During the planning phase, you typically set the scope of attack (What systems and what parts of it to test)

Discovery / Information Gathering

Host discovery, service discovery, network topology mapping, finding http/html form fields that can tested further. What information you need to gather is depending on what kind of security test you are going to perform.


Probing for vulnerabilities on the services you dicovered in the previous phase. As you most likely will find new and more relevant information during the attack phase, you will move between the discovery and attack phase. I.e. backend sql server behind the web server.


In this section you report your findings. The final report typically have the following sections:

  • Executive Summary
  • Detailed Findings
  • Risk levels of vulnerabilities found
  • Business Impact
  • Recommendations
  • Conclusion

The following link describe this approach with details: Pentest phases

  • 1
    +1. Keeping securtiy a top priority throughout the entire development process (and getting the business unit's buy-in in a cporporate environment) is critical. Commented Apr 13, 2012 at 13:25

You could do a lot worse than starting with the Open Source Security Testing Manual (it's the manual which is open source not the target).

Looking at your current list, code (particularly, but not exclusively SQL) injection should be way up on your list.

If it's a web-based application then you should be looking at session fixation / hijacking, XSS. Do check out arachni.

If you're going to be addressing DDOS, then have a look at sloloris and throttled response strangling.

Getting people to think like an attacker is tricky (and questionable for its benefits - an attacker only needs one weakness, a defender has to cover them all). Maybe give them some honeypots to hone their skills on?


Ultimately it depends on what is being tested. The first thing a professional attacker does is research into what is running, what weaknesses might already be well known what sorts of weaknesses might have been added.

If it's something with a database back-end I'm going to try SQL injection tests. For web services I'll be looking for XSS and CSRF attacks. Buffer overflows are likely only against the underlying Web Server/Virtual Machine unless we are talking native code here (some home rolled client).

There is no one answer, it depends on what one is looking at.


I have found the book "Metasploit: the Penetration Tester's Guide" useful in a similar situation; while being primarily a guide to Metasploit, it also discusses the basics of penetration testing.

Slightly off-topic, but you may want to look at Backtrack, a disk-bootable OS for penetration testing. Backtrack has Metasploit built in. Since you can boot it from a disk or memory stick, your team can experiment with it without having to install anything.


The types of examples you gave are a great start. In general, you want your testing to mimic the attacker mindset of "how can I misuse this asset." Yes, practice deliberately performing tests (and giving inputs) that are outside of the requirements and designed, checking for bad or dangerous responses.

Bretik also references a good resource, in the OWASP Testing Guide. Many of these may be more advanced, however, and better used for specifically-aligned security testers.

You may also consider having your security specialists work to create tools & tests that your QA can run to test applications. Some dynamic and static security analysis tools now provide hooks or methods for QA to do testing. For example, a security SME could use W3AF (http://w3af.sourceforge.net/) to make a python script that your QA tester can execute against an application

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .