Burp Suite for Beginners: How to Automate SQL Injection Findings (Community Edition)

Por

In the world of bug bounty hunting and Capture The Flag (CTF) competitions, Burp Suite is the undisputed king of proxies. However, there is a common misconception among beginners: “I can’t find vulnerabilities efficiently because I don’t have the Professional edition.”

While Burp Suite Professional offers the powerful “Active Scan” feature that automatically probes for security flaws, the Community Edition is far more capable than most people realize. You do not need to spend $400+ to start automating your workflow. You just need to know how to combine the tools you have.

In this guide, we are going to bridge the gap. I will show you how to use Burp Suite Community’s Intruder tab to create a semi-automated “fuzzer” for SQL Injection (SQLi) and how to seamlessly bridge Burp with SQLMap to turn manual findings into full exploitation.

The “Grey Area” of Automation

Burp Suite Community is often described as a manual testing tool. This is only half true. While it lacks the fully autonomous scanner, the Intruder tool allows for user-driven automation.

If you check every parameter on a website by hand, typing ' OR 1=1 -- into every input field, you will burn out before you find a flag. The “advanced” method we will cover today involves:

  1. Intercepting legitimate requests.
  2. Fuzzing parameters using the Intruder (Sniper mode).
  3. Analyzing response lengths and status codes to pinpoint vulnerabilities.
  4. Exporting the request to SQLMap for final verification.

Let’s dive into the setup.

Step 1: Configuring Your Proxy and Target

Before we automate, we must intercept. I assume you have Burp Suite installed and FoxyProxy configured in your browser.

  1. Open Burp Suite and navigate to the Proxy tab.
  2. Ensure “Intercept is On.”
  3. Open your target browser (the one connected to Burp).

For this tutorial, imagine we are testing a vulnerable lab machine (like DVWA or a Hack The Box instance) that has a search functionality.

Type a standard search term, like “test,” into the search bar and hit Enter.

In Burp, you will see the raw HTTP request frozen in time. It might look something like this:

GET /search.php?query=test&submit=Search HTTP/1.1
Host: 10.10.10.x
User-Agent: Mozilla/5.0...
Cookie: PHPSESSID=abc12345...

Right now, this is just a request. To start our “poor man’s automation,” we need to move this to the Intruder.

Shortcut: Press Ctrl + I (or Right-Click > Send to Intruder).

Step 2: The Intruder Setup (The Heart of Community Automation)

The Intruder tab is where the magic happens. It allows you to take that one request and replay it hundreds of times, changing small parts of it with every attempt.

1. Payload Positions

Navigate to the Intruder > Positions sub-tab. You will see your request with various parts highlighted in green (or wrapped in § symbols). These are the “payload positions”—the places where Burp will inject your SQL code.

Burp tries to be smart and highlight every cookie and header. Clear this immediately.

  1. Click the “Clear §” button on the right.
  2. Highlight only the value of the parameter you want to test. In our example, highlight the word test in query=test.
  3. Click “Add §”.

Your request line should now look like this: GET /search.php?query=§test§&submit=Search HTTP/1.1

2. Attack Type

For the Community edition, stick to Sniper. This attack type takes your list of payloads and puts them into the marked position one by one. It is precise and easier to analyze than “Cluster Bomb” when you are learning.

Step 3: Crafting the Payload List

Now go to the Payloads sub-tab.

This is where beginners often fail—they use the wrong lists. Since the Community Edition throttles the speed of Intruder (it runs slower than Pro), you cannot afford to load a list of 10,000 payloads. You need a highly curated list.

We are looking for Error-Based SQL Injection signals. We want to break the database syntax to see if the server complains.

Under Payload Options (Simple List), add these core payloads manually (or create a .txt file to load):

'
"
`
')
")
1' OR '1'='1
1" OR "1"="1
' -- -
" #

Why these specifically?

  • The single quote ' is the most common way to break a SQL query string.
  • The double quote " handles JSON-based injections or different backend logic.
  • The comment characters (-- - and #) attempt to fix the query after breaking it, which is often necessary to bypass syntax errors that hide the vulnerability.

This list is short, meaning Burp Community will finish the attack in seconds, not hours.

Step 4: Launching the Attack and Analyzing Results

Click the “Start Attack” button.

A new window will pop up. You will see requests firing off. Since this is the free version, you might notice a slight delay between requests. This is intentional by PortSwigger, but for our short list, it doesn’t matter.

The Advanced Part: How to Read the Tea Leaves

Most beginners look for a “200 OK” status and assume everything is fine. Wrong. You are looking for anomalies.

Look at these columns in the results window:

  1. Status: Did the server return a 500 Internal Server Error? (This is often a gold mine for SQLi).
  2. Length: This is the most important metric.

The Length Anomaly: Imagine the normal page size is 4,500 bytes.

  • Request 1 (') returns 3,200 bytes.
  • Request 2 (") returns 4,500 bytes.
  • Request 3 (1' OR '1'='1) returns 8,000 bytes.

Analysis:

  • The drop to 3,200 bytes suggests you broke the page (syntax error).
  • The jump to 8,000 bytes suggests you successfully injected a TRUE statement, causing the database to dump all results instead of just one.

If you see a significant difference in the Length column compared to the baseline request, you have found a potential injection point.

Step 5: Bridging to Full Automation (Burp to SQLMap)

This is the trick that separates the “script kiddies” from the professionals.

You have identified a suspicious parameter using Burp Intruder. You could try to extract the database name manually using UNION SELECT, but that is tedious and prone to syntax errors.

Instead, we will hand the job over to SQLMap, but we will do it the right way.

  1. In the Burp Intruder results window, right-click the request that looked suspicious (the one with the weird Length or 500 error).
  2. Select “Save item”.
  3. Save it as a file named request.txt on your desktop or in your CTF folder.

Now, open your terminal (Kali Linux, Parrot, or Windows Command Prompt).

We are going to use the -r flag in SQLMap. This tells SQLMap: “Don’t guess the URL. Don’t guess the headers. Use this exact HTTP request that I captured.”

Run this command:

sqlmap -r request.txt --batch --dbs

Why is this “Advanced”?

  • Cookie Handling: If the site requires a login, simply running sqlmap -u http://target.com will fail because SQLMap doesn’t have your session cookies. By saving the request from Burp, you pass your active session ID to SQLMap automatically.
  • Header Evasion: If the site checks for specific User-Agents or Referer headers, the text file preserves them perfectly.
  • Precision: SQLMap doesn’t need to crawl the whole site. It focuses 100% of its power on that single parameter you already validated.

Step 6: Grep – Match (Pro Tip for Community Users)

Let’s rewind to the Intruder settings for a second. There is one more feature in the Community edition that mimics the “Active Scan.”

In the Intruder tab, go to Options > Grep – Match.

This section allows you to flag responses that contain specific words. If you are hunting for SQL errors, check the box and add these keywords to the list:

  • “SQL syntax”
  • “mysql_fetch”
  • “ORA-01756”
  • “SQLite Error”
  • “PostgreSQL query”

Now, when you run your attack, Burp will add a new column for these words. If a checkbox appears in that column, you don’t even need to analyze the length—the server explicitly told you it is vulnerable!

Common Pitfalls to Avoid

As you start using this workflow, keep these troubleshooting tips in mind:

1. URL Encoding Issues

Sometimes, the server expects your injection to be URL encoded (e.g., space becomes %20).

  • Fix: In Burp Intruder > Payloads, ensure the box “URL-encode these characters” is checked. This is usually on by default, but verifying it saves headaches.

2. False Positives

Sometimes a “Length” change is just a dynamic advertisement loading on the page, not a vulnerability.

  • Fix: Always verify manually using the Repeater tab. Send the request to Repeater, inject your payload, and render the response in the browser to see why the length changed.

3. The WAF (Web Application Firewall)

If every request returns a “403 Forbidden,” you are likely being blocked by a WAF.

  • Fix: This is a topic for another article, but try using the “SQLMap Tamper Scripts” or changing your User-Agent in the Burp request headers before sending it to Intruder.

Conclusion

You do not need the $449/year Professional license to start finding valid bugs or solving Hard-level CTF challenges.

By mastering the workflow of Proxy Interception -> Intruder Fuzzing -> SQLMap Exploitation, you are effectively building your own automation suite. Burp Suite Community provides the precision, and SQLMap provides the brute force.

Your Next Steps:

  1. Open a lab environment like PortSwigger Web Security Academy (it’s free).
  2. Find a “SQL Injection” lab.
  3. Do not use the solution. Use this guide. Capture the request, fuzz it with Intruder, and feed it to SQLMap.

Once you see that database name pop up in your terminal, you’ll realize that the tool doesn’t make the hacker—the methodology does.

Have you used this method in a CTF before? Let me know in the comments if you prefer manual exploitation or if you lean on SQLMap for the heavy lifting!