SQL Injection
Check List
Methodology
Change Table Parameters
Log in to the site and look for mechanisms such as calculators or mechanisms that allow you to enter image sizes, etc., or data
Trace the request using Burp Suite and check whether values ​​are sent to the server with the POST method and JSON data by changing the numbers and sizes
Inject a quote mark (unitWeight=10') into a parameter and submit the request, and check if you get any errors from the server side, such as 500 Internal Server Error
The next step is to check whether this error is returned by adding another single quote to the parameter (unitWeight=10'')
Then use timebase payload injection for SQL like 'XOR(if(now()=sysdate(),sleep(10),0))XOR'Z to check if the server is responding to you with a delay
If the server responds to you with a delay of 10 seconds, it means the server is vulnerable
Inspect cookies by modifying their values with SQL payloads (cookie=value' OR 1=1), checking if the server responds differently or exposes sensitive data
Intercept browser traffic with a proxy Burp Suite
Load the target page so the relevant GET/POST request appears in the proxy
Send the request to Repeater (or an editor)
Locate the Cookie: header and identify parameters ( lang=...)
Modify the suspicious cookie value to a single quote ' and send the request
Check the server response for SQL errors or 500/DB-syntax messages
To confirm, change the value to a second quote ('') or otherwise balance the quote and resend; if the error disappears, this further indicates SQLi
(Optional verification) Inject a time-based payload compatible with the backend (IF(1=1,SLEEP(5),0)) into the cookie and measure response delay
If the server responds to you with 5 seconds of delay, it means it is vulnerable
Identify input fields or parameters in the target application, such as URL query strings (id=) or form inputs, that may interact with a database, focusing on features like search, deletion, or data retrieval endpoints
Intercept HTTP requests using a proxy tool (Burp Suite) to capture parameters like id or username, analyzing how they are sent to the server for database queries
Test for SQL injection by injecting a single quote (id=187') into the parameter and sending the request, observing for server errors (500 Internal Server Error) that indicate unhandled SQL syntax
Confirm the absence of verbose error messages in the response, noting generic error pages or no data leakage, suggesting a potential blind SQL injection vulnerability
Inject a time-based payload (id=187 AND SLEEP(5)) to test for a delay in the server response, confirming time-based SQL injection if the response is delayed by the specified time (5 seconds)
Verify the delay by sending a non-sleeping payload (id=187 AND 1=1) and comparing response times to ensure the delay is due to the SLEEP command execution
Test for boolean-based conditions using payloads like id=187 AND IF(1=1,SLEEP(5),0), checking for a delay when the condition is true and no delay when false (1=2)
Extract database metadata by injecting payloads like id=187 AND IF(SUBSTRING(version(),1,1)='5',SLEEP(5),0) to determine the database version character by character, noting delays for true conditions
Determine the database name length using payloads like id=187 AND IF(LENGTH(database())=10,SLEEP(5),0), incrementing the length value until a delay confirms the correct length
Extract the database name by iterating through each character position with payloads like id=187 AND IF(SUBSTRING(database(),1,1)='a',SLEEP(5),0), testing all possible characters (a-z, 0-9) and noting delays for correct matches
Move to the next character position (SUBSTRING(database(),2,1)='a') after identifying the first character, repeating the process until the full database name is extracted
Test for additional metadata, such as table names or column names, using payloads like id=187 AND IF(EXISTS(SELECT table_name FROM information_schema.tables WHERE table_name='users'),SLEEP(5),0)to confirm the presence of specific tables
Referer is another HTTP header which can be vulnerable to SQL injection once the application is storing it in database without sanitizing it. It's an optional header field that allows the client to specify
Go to the homepage and trace the request using Burp Suite
Then send the request to the Repeater and check the Referrer header using the following payload
GET /index.php HTTP/1.1
Host: [host]
User-Agent:
Referer: http://www.yaboukir.com' or 1/*Then check if the server shows any strange behavior after injecting the payload into this header
Log in to the target site and record requests using Burp Suite
Identify the X-Forwarded-For header in logged requests
Routes that set and use the X-Forwarded-For header on sites and usually store its values ​​in the database : /login /signup /register /logout /user/profile /profile/update /checkout /purchase /cart/checkout /api/* /comments /comment/post /posts /posts/create /sessions /session
/password/reset
Send the request by going to these routes and then setting this header (or if it already exists) and then examine the server response like the following request
Now, using a simple payload like the one below, we will check this header to see if the server is giving us an unusual or strange response
If an error occurs, test a false condition payload like ' OR 1=2 -- and compare
If the attack was successful, we can extract the database version using the following payload
Navigate to pages on the target website that display database-driven results, such as search pages, product listings, or user dashboards, often found at URLs like /search, /results, /list, /products, or /dashboard. These pages typically use query parameters for sorting or filtering
Look for query parameters controlling sorting or filtering, such as sortBy, order, sort, filter, or column, in the URL or form submissions, as these are often passed directly to SQL queries
Modify the identified parameter (sortBy) with a simple time-based payload like 1 AND SLEEP(5) -- to introduce a 5-second delay if the query executes
Use a browser or Burp Suite to send the modified request and measure the response time. A ~5-second delay confirms the payload executed in the database
Send a non-delaying request with the original parameter value (sortBy=1) or a neutral payload (sortBy=1 AND 1=1 --) to ensure no delay occurs, verifying the injection
Inject a payload like 1 AND IF(SUBSTRING(DB_NAME(),1,1)='A',SLEEP(5),0) -- to test if the database name starts with 'A', noting a delay for true conditions. Iterate through characters (A-Z, 0-9) to extract the name
Apply the same payload to similar parameters (order, filter) on other database-driven pages (/products, /list) to identify additional injection points
Go to the points on the target site where you can create a list or a book or a quiz Or for example in the /archive path, And especially pages where we as a user can publish or search for something
Locate the authors parameter in the POST request body, used for filtering or querying author-related data, making it a candidate for SQL injection
Modify the authors parameter with a time-based payload like Hurlburt'XOR(if(now()=sysdate(),sleep(4),0))OR' to induce a 4-second delay if the query executes
And send this request using Burp Suite and check the server response time
If the server response time is equal to the time specified in the payload, this parameter is vulnerable
Log into the target site and intercept the requests using the Burp Suite tool
Then identify and check the file upload functionality on the site. This functionality is usually in the profiles, tickets, user settings, and ...
Then click on the Upload File option and intercept the request using intercept in Burp Suite
Now put --sleep(15).png in the payload file name and then check the server response to see if it responded to us after 15 seconds
If the server response takes 15 seconds, the SQL Injection vulnerability in the file name is confirmed and it is vulnerable
Signup Process
Enter a username and email in the Signup form and submit it, capturing the request with Burp Suite to inspect field validation and database behavior
Locate the email or username parameter in the POST request body, noting if the application allows duplicate usernames with unique emails, indicating potential truncation
Create a second account with the same username and a modified email (r3dbuck3t@bucket.com+++++hacker), intercepting the request with Burp Suite to add encoded spaces and extra characters.
Send the request and check for a 200 response, confirming the account was created despite the extra characters, suggesting truncation occurred
Log in with the original email (r3dbuck3t@bucket.com) and the same password to verify the account authenticates, proving truncation allows duplicate access
Identify an admin email (admin@book.htb) from public pages like Contact Us, then repeat the process with admin@book.htb++++++hacker to create a duplicate admin account
Attempt to log in with the original admin email (admin@book.htb) and the new password, checking if it grants user-level access or redirects to an admin portal
If user access is granted, perform directory enumeration (with Gobuster) to find an admin portal (/admin), then try logging in again to verify admin privileges
White Box
Cheat Sheet
Last updated