Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility

Using Burp to Detect SQL Injection Flaws

Injection attacks occur when an attacker is able to supply crafted input that breaks out of the data context of an application. The result is that part of this input gets interpreted as program instructions, which are executed in the same way as if they had been written by the original programmer. Often, therefore, a successful attack fully compromises the component of the application that is being targeted.

In this example we will demonstrate how to detect SQL injection flaws using Burp Suite. This tutorial uses exercises from the "DVWA", “WebGoat” and "Mutillidae" training tools taken from OWASP’s Broken Web Application Project. Find out how to download, install and use this project.

Scanning for SQL injection flaws

First, ensure that Burp is correctly configured with your browser.

Ensure "Intercept is off" in the Proxy "Intercept" tab.



Visit the web page of the application that you are testing.

Return to Burp and ensure "Intercept is on" in the Proxy "Intercept" tab.

Now send a request to the server. In this example by clicking the "Submit" button.


The request will be captured in the Proxy "Intercept" tab.

One way to test an application for SQL injection vulnerabilities is to send the request to Burp Scanner.

Right click anywhere on the request to bring up the context menu.

Click "Do an active scan".

Note: You can also send requests to the Scanner via the context menu in any location where HTTP requests are shown, such as the site map or Proxy history.



Once the scan is complete, go to the Target "Site map" tab.

In this example the Scanner has found a number of SQL injection issues.

Click on an individual issue to view the "Advisory" tab, which provides details about each specific vulnerability.

You can also view the requests and responses on the basis of which Burp has reported the issue.


Manual testing for SQL injection flaws

Alternatively, you can use Burp to manually test the application for injection vulnerabilities.

With intercept turned off in the Proxy "Intercept" tab, visit the web application you are testing in your browser.


Visit the web page you are testing.

You can often detect SQL injection by inputting certain characters in to the application's parameters.

In this example, submitting a ' (single quote) produces a custom error message.


However, inputting '' (two single quotes) does not.

The reason for this difference is that SQL strings are contained within single quote delimiters. Submitting one quote breaks the representation of the string, and therefore the wider SQL statement. Two single quotes are an escape sequence representing a literal single quote. So submitting two quotes inside the string just modifies the value of the string and does not break the SQL statement,

If you are not already familiar with SQL and SQL Injection, you can learn more about it here and here.


Now that you have detected a potential SQL vulnerability you can use Burp to investigate the vulnerability further.

Return to Burp and turn Proxy "Intercept" on.

Now send a request to the server, in this example by clicking the "Go" button.


The request will be captured in the Proxy "Intercept" tab.

Right click anywhere on the request to bring up the context menu and click "Send to Repeater".

Note: You can also send requests to the Repeater via the context menu in any location where HTTP requests are shown, such as the site map or Proxy history.


Go to the "Repeater" tab.

Here we can input various payloads in to the input field of a web application.

We can test various inputs by editing the values of appropriate parameters in the "Raw" or "Params" tabs.

In this example we are attempting to reveal the credit card details held by the application.

Smith' OR '1' = '1 is an attempt to alter the query logic and reveal all the user information held in the table.


The response can be viewed in the "Response" panel of the Repeater tool.

Responses that warrant further investigation or confirmation can be viewed in your browser.

Click "Show response in browser".


Paste the URL in to the browser to view the response there.

In this example the attack has yielded the credit card details of all users.


Injection Attack: Bypassing Authentication

In this example we will demonstrate a technique to bypass the authentication of a vulnerable login page using SQL injection.

To check for potential SQL injection vulnerabilities we have entered a single quote in to the "Name" field and submitted the request using the "Login" button.


The application provides us with an SQL error message.

The error message includes the SQL query used by the login function.

We can use this information to construct an injection attack to bypass authentication.

The first account in a database is often an administrative user, we can exploit this behavior to log in as the first user in the database.


Enter some appropriate syntax to modify the SQL query into the "Name" input.

In this example we used ' or 1=1 -- .

This causes the application to perform the query:

SELECT * FROM users WHERE username = '' OR 1=1-- ' AND password = 'foo'

Because the comment sequence (--) causes the remainder of the query to be ignored, this is equivalent to:

SELECT * FROM users WHERE username = ' ' OR 1=1


In this example the SQL injection attack has resulted in a bypass of the login, and we are now authenticated as "admin".

You can learn more about this type of detection in our article; Using Burp to Detect Blind SQL Injection Bugs.