Contact us for your penetration testing needs 1-866-PLYNT-24    |   Contact Us   Plynt UK Website  
Click to get Security Testing Quote

Penetration Testing

  1. How much does a penetration test cost?
  2. How is scanning different from an application pen test?
  3. I use stored procedures. Any chance I'm vulnerable to SQL Injection?
  4. How much time does an application penetration test take?
  5. I suspect our tester just ran a scan instead of doing a proper application pen test. How can I find out?
  6. Where can I practice security testing? Are there sample unsafe apps?
  7. How do I check if there's a backdoor in my application?
  8. What tools do you use to test applications?
  9. I asked my penetration tester to prove the vulnerabilities with an exploit. But he says that isn't always necessary. Huh?
  10. What are some good books for security testers?
  11. Why are buffer overflows unlikely in web applications?
How much does a penetration test cost?

The cost of a pen test depends on the skill of the testers you engage and the size of the application.

Having said that, we have seen wide variation in pricing – from $5,000 to $50,000. And the higher prices don’t always mean higher quality.

At Plynt, we constantly strive to reduce our costs and pass on part of those benefits to you. Drop us a mail or contact us to get a quote for a security test.

How is scanning different from an application pen test?

They discover different kinds of holes.

A scanner is good to find web server holes, ugly error messages and old source code lying around on your web server. At times, it can even find SQL Injection and Cross Site Scripting holes. A scanner has a large database of known vulnerabilities in web servers, and it checks if your site is safe against those.

An application pen tester dons the hat of an attacker. He discovers logical holes real adversaries are interested in that allow them to steal credit cards, manipulate prices, siphon off funds etc. That requires a study of the application - its business context, the motives of the adversary, the workflows, the privilege levels. He then crafts exploits and tests the application. The threats discovered by a pen tester have much greater impact than those discovered by a scanner.

There are other smaller differences too:

  • A scanner takes less time to run after it is setup – usually a day or two.

  • An application pen test can take between a week to three weeks, depending on the size of the app and experience of the tester.

  • Scan reports tend to have many false positives, and even more false negatives. [False positives are false alarms. A false negative is when a hole is missed.] Pen test reports are free from false positives. The number of false negatives depends on the skill of the tester.

  • Most pen testers use a scanner to discover web server holes, error messages, comments in code etc. during the pen test.

I use stored procedures. Any chance I'm vulnerable to SQL Injection?

The short answer is "yes".

SQL Injection is the result of using dynamic SQL statements, those that are created at run time from user inputs. Stored procedures are pre-compiled pieces of code, so one wouldn't expect them to be vulnerable to SQL Injection.

To quote Chris Anley's classic "Advanced SQL Injection" paper (page 17):
Traditional wisdom holds that if an ASP application uses stored procedures in the database, that SQL injection is not possible. This is a half-truth, and it depends on the manner in which the stored procedure is called from the ASP script.
Essentially, if a parameterised query is run, and the user-supplied parameters are passed safely to the query, then SQL injection is typically impossible. However, if the attacker can exert any influence over the non - data parts of the query string that is run, it is likely that they will be able to control the database.
Good general rules are:

  • If the ASP script creates a SQL query string that is submitted to the server, it is vulnerable to SQL injection, *even if* it uses stored procedures
  • If the ASP script uses a procedure object that wraps the assignment of parameters to a stored procedure (such as the ADO command object, used with the Parameters collection) then it is generally safe, though this depends on the object's implementation.
  • Santosh explained this in detail in the article Are stored procedures safe against SQL injection?

How much time does an application penetration test take?

The time taken for an app pen test varies depending on the size of the application and the skill of the testers. For the same app, we have seen some firms quote a week, whereas others have quoted 2 - 3 weeks.

For a given team, the longer they get to test an app, the more thorough the test is likely to be. But while comparing two different vendors, the quality of test is not always proportional to the time invested. Teams with greater experience are likely to have streamlined their testing methodologies – they should be able to do good tests faster.

If a pen tester quotes just 2-3 days, be suspicious. It’s not unheard of for a pen tester to run his favorite scanning tool and generate a report. When evaluating a vendor, grill them on their methodology. If you hear too much about tools, and too little about thinking, then you know what to expect.

Another interesting estimate is how long it takes to do a confirmatory re-test. We explained our thinking in this blog post.

I suspect our tester just ran a scan instead of doing a proper application pen test. How can I find out?

The simplest is to ask him for sample test cases he used in the pen test.

If you can't do that, check your web server logs for heavy activity from a single IP address - that's probably the scanner. Assuming the pen tester would have come from a near-by block, filter your logs for that /16 block. You will most likely be able to zoom in on what the pen tester did. If you have an IDS, locating the pen tester's IP is easier - the IDS would have triggered alerts during the scan.

If your app maintains detailed logs, then check the audit trail for the user logins you gave the pen tester before the test.

Again, the simplest is to ask the tester for sample test cases if you aren't satisfied with the results.

Where can I practice security testing? Are there sample unsafe apps?

There are lots of sample applications available which are freely downloadable.

Foundstone released a series of them that you can download from their tools page.

WebMaven is another sample application for trying out attacks.

OWASP also provides a sample application called WebGoat. There are lessons on most of the common vulnerabilities and it can be downloaded from WebGoat sample application.

How do I check if there's a backdoor in my application?

The best way to know if you've a back door in your app is to do a code audit. A remote pen test might find it, but the chances are low.

Companies check for back doors when a security critical software is purchased from a 3rd party. The fear is that developers might have inserted code that lets them get back into the app on a later date.

During the audit, here're a few things the auditor will do to check for back doors:

  • Look for undocumented ports being opened
  • Monitor registry access for anything suspicious
  • Track the files being opened
  • Monitor if other execuatbles are launched
  • Watch for network connections going out
  • Check for hard-coded special passwords in the code
  • Look for "special" users in the user database

Sysinternals has several tools that help the auditor: Regmon, Filemon, Process Explorer, PSTools, Strings, Rootkit Revealer, etc.

What tools do you use to test applications?

There are various tools that are used for different purposes.

For capturing the traffic, Ethereal is used. Ethereal is a tool for network protocol analyzer. It captures the packets on the network. It is available for download at Ethereal.

Web server scanners are used for scanning web servers for vulnerabilities.

Examples of such tools are:

- Nikto - is an Open Source web server scanner which performs comprehensive tests against web servers for multiple vulnerabilities.

- Nessus - It can be used as a remote vulnerability scanner and also for fingerprinting the OS.

For manipulating any information like form fields, hidden variables and cookies, attackers use tools known as HTTP proxy tools. The browser's proxy settings are configured to go through the HTTP proxy. The proxy tool can see all information flowing between the client and the server; it even allows the attacker to modify any part of the request/response before sending it. Examples of such tools are:
- Paros

- WebScarab

For viewing the contents of the memory, Winhex is used.

I asked my penetration tester to prove the vulnerabilities with an exploit. But he says that isn't always necessary. Huh?

The penetration tester is probably right. There are several cases when it's enough to find evidence of a hole, and not go all the way to construct an exploit.

A penetration tester works against time. The more time he has to find holes, the deeper he can go. In many cases, when he finds a hole, it takes just a few more minutes to construct an exploit. But sometimes, constructing the exploit could take hours, as he has to make several guesses and refine the inputs. That's when the pen tester might chose to skip the exploit, when he's certain that the vulnerability exists.

Here's an example. When an application throws an ODBC error message for a single quote, it means the app is vulnerable to SQL Injection. Usually, it's easy to construct the exploit. At times, the pen tester will have to enumerate the database to construct a meaningful exploit. [See David Litchfield's paper "Web Application Disassembly with ODBC Error Messages" for details.] It might take a few hours. But that ODBC error message is evidence that the app is vulnerable to SQL Injection, that the code needs to be fixed.

Since most penetration tests have a fixed deadline, the time taken to construct an exploit is time taken away from finding holes. It's best for the customer to let the pen tester move on and find more holes, instead of investing more time in refining the attack.

If you suspect that the hole is really not exploitable, it's best to ask the penetration tester how he would construct an exploit. Can he point you to a good reference paper that shows how the exploit can be constructed if there's enough time? Most good penetration testers will oblige you happily.

What are some good books for security testers?

Here're some of the good books on security testing:

Gary Mc Graw has a reading list on Software Security at Amazon.

Why are buffer overflows unlikely in web applications?

There are two reasons why we don't see buffer overflows in web applications.

First, to discover a buffer overflow, an attacker has to either get access to the source code, or get local access to the system on which the application is running. It's by checking the app's response to long inputs and tracing the execution that an attacker learns if it's vulnerable. Web apps are usually attacked remotely and the adversaries rarely see the source code. It then becomes very difficult to discover a buffer overflow in a web app.

Secondly, to perform a buffer overflow, the compiler should let data be stored into memory that has not been properly allocated. Languages like Java do not support that (unlike C, C++). So it's impossible to do buffer overflows in Java apps anyway. explains this well here.

On a cautionary note, there have been instances of PHP library functions (written in C themselves) being vulnerable to buffer overflows. Here're two examples [1, 2]. So open source PHP web apps need to take special care against buffer overflows when they call unsafe functions.

Jeremiah Grossman wrote a lucid article de-bunking buffer overflows in web applications: Myth-Busting Web Application Buffer Overflows Do check that out.

Request a proposal

Our quote contains the best price, the time estimate, and our methodology; and we'll mail you the quote in 24 hrs.

Movable Type Appliance - Powered by TurnKey Linux