Applying DRY Principle in Pentesting
When I manually pentest sites, I usually see some standard parameters like
"q=" and I immediately test the common vulnerabilities like open redirector or SQL injections and observe their behavior. I used to repeat the process on many pages, and I do that a lot, which wastes my time. To solve this problem, I wrote a solution to test all the basic issues without using automated scanners.
BTW, If you have Burp Suite Pro you don’t need to even read this. Burp Suite professional has all this implemented.
I wouldn’t say I like the idea of using automated scanners when I actively pentest sites for many reasons. Usually, when I hunt bugs, automated scanners like OWASP ZAP find a lot of false-positive problems + it’s too intense and might case my IP to get blocked sometimes + it takes time to configure these automated scanners, so I usually run them overnight but when I manually pentest I like to do it a little bit differently. I like to test sites manually and observe the results, and not just looking at the length of the response but by actually looking at the rendered responses. That takes a long time, browsing the site looking for problems is a repeated process. As a solution, I had an idea a month ago; the idea is to automate some portion of my repeated actions, while still manually testing them and look at the responses without using some of the large fuzz projects all the time.
The idea is to fuzz some common parameters semi-automatically without the need to entirely doing it manually and without using vulnerability scanners. The solution I implemented is a browser extension that detects these common parameters while browsing and tests them immediately and spawns up every test on a different tab to manually look at the resulting response. So far, it tests GET request parameters for common vulnerabilities like Local file inclusion, Remote File Inclusion, Endpoint SQL injection, and open redirect.
How to use:
- Enable Chrome developer mode.
- Load the extension. (After configuring the scope)
- Start browsing the site you are testing.
- It will spawn up new tabs for each basic test, which will allow you to force on more complicated tests.
An example of SQLi tests:
When browsing bWAPP and using the search bar and entering anything.
- It detects the “title” parameter.
- It then tests the “title” parameter using a couple of special characters trying to find an SQL problem.
- It spawns up different pages for each test to observe.
As results, a test was able to comment the query:
Another test was able to break the execution: