One of most common and potentially most painful task you will have to perform as a penetration tester is retesting.
If you are lucky, retesting can be quick and painless!
However, in most cases, you will have the same problems you can have during an initial test: waiting for the environment, waiting for credentials, waiting for valid credentials… Sometimes you will just be given a report (sometimes from a competitor) with a list of issues and you will realise that it is a pretty good way to rate the quality of someone else’s report!
Always write your report as if the person who ends up retesting your findings is a violent psychopath who knows where you live.
How long does it takes you to retest an issue from a report you have never seen before?
By retesting, you will quickly learn the difference between:
- “The application is vulnerable to XSS”
- “The parameter named msg in the page /login.jsp is echoed back, without encoding, leading to XSS”
In the second sentence, you have almost everything you need to retest the issue; in the first sentence, not so much.
Being prepared is the best way to avoid wasting time!
The simplest way is to have a script to retest each issue. I know of at least one company who uses browser automation (i.e.: driving a browser with tools like Watir, Selenium or Chrome headless) to perform most of their retesting. This allows testers to easily retest an issue in a fully working browser and have a quick feedback on whether or not things have been changed.
Other companies save Burp requests to ensure they have, at least, the bare minimum on a given vulnerability. It’s probably better to keep each vulnerability test cases in a separate file instead of having a big file (default option for Burp Suite) with all the details of your testing (remember retesting may happen up to a few years later). Along with these files, it’s common to keep a step by step explanation on how to get there.
For example, for a Cross-Site Scripting vulnerability:
Log in as user1 or any users with the privilege “Standard User”
- Click the link named “My profile”
- Click “edit”
- Click “save” with Burp in “Intercept” mode.
- Put your payload (standard <script>alert(1);</script>) in the parameter “firstname” using Burp
- Log out and Log in with the same username and visit the page “My profile”, an alert box should appear
This looks like a lot of work but you can see all the pitfalls you will avoid…and all the time you will save:
- You know what user/privilege you need to use to test this issue.
- You know where to go to put the payload.
- You know that there must be some JavaScript checks preventing you from directly using the payload in your browser (“using Burp”).
- You know what payload works.
- You know that the response does not contain the payload directly and that you need to log out (probably to avoid some session/caching mechanism).
- You know where to look to find where the payload is triggered.
Now Imagine how much time you could have wasted if you didn’t have this information. Furthermore, you will probably have miss the bug since you need to log out and log in again to trigger it.
You will save a huge amount of time (or save someone else a huge amount of time) if you spend a bit more time to write all the details you need.
You can provide all this information as part of the report (in Appendix) or in a folder with all the information you had/use during the testing along with all the logs and output of your tools. Keeping this information out of the main report will help keep things clear in the write-up and will ensure a reasonable size report…
Another point is how to retest, having test cases that pass or don’t pass allow you to perform a quick check to ensure something has changed. It doesn’t ensure that something has been fixed. You can probably find another payload that will allow you to bypass the fix provided by developers/system administrators.
You also need to be ready for the fact that sometimes you will get asked to retest an application where none of your recommendations have been applied and the application is as vulnerable as when you initially tested it. That’s quite a frustrating (and recurring) thing especially if you work for big companies, but you need to understand that your clients don’t necessarily have the visibility to ensure fixes get implemented. And sometimes, you even get people telling the security team that everything as been remediated even if nothing was changed, just to get rid of them and go back to their daily work.
Hopefully, this article convinced you that retesting can be made easier by spending a little bit more time writing things down during your testing.
