SQL Injection - Revision history

Unknown user: /* Blind SQL Injection */

2023-05-21T17:01:23Z

Blind SQL Injection

← Older revision		Revision as of 17:01, 21 May 2023
Line 115:		Line 115:
	* <code>…xyz' AND '1'='2</code>		* <code>…xyz' AND '1'='2</code>

			This can be further exploited, by combining with knowledge of other tables. Example: a table called Users with columns Username and password. Then the following SQL queries will allow determining a password one character at a time:

			<pre>
			xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'm

			xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 't

			xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 's
			</pre>

Unknown user: /* Retrieving data from other tables */

2023-05-21T16:58:55Z

Retrieving data from other tables

← Older revision		Revision as of 16:58, 21 May 2023
Line 100:		Line 100:

	This type of attack is called a UNION attack. See [[SQL Injection/UNION Attack]]		This type of attack is called a UNION attack. See [[SQL Injection/UNION Attack]]

			==Blind SQL Injection==

			Blind SQL injection arises when an application is vulnerable to SQL injection, but its HTTP responses do not contain the results of the relevant SQL query or the details of any database errors.

			Example: tracking cookies to gather analytics. Cookie tracking ID may get fed to an SQL query, but results of query are not returned to the user.

			Application behavior will be different though, depending on whether the query returns data or not - if a cookie tracking id is valid, will show "Welcome back"

			Utilize that behavior to to exploit SQL injection vulnerabilities

			Can check for these types of vulnerabilities by submitting a pair of requests, and seeing different behavior:
			* <code>…xyz' AND '1'='1</code>
			* <code>…xyz' AND '1'='2</code>

Unknown user: /* Subverting application logic */

2023-05-21T16:50:19Z

Subverting application logic

← Older revision		Revision as of 16:50, 21 May 2023
Line 72:		Line 72:

	which would terminate the SQL query before the "AND" check, bypassing the password check and making any password valid.		which would terminate the SQL query before the "AND" check, bypassing the password check and making any password valid.

			It may also take a few attempts - admin, administrator, or specific usernames - don't give up easily

			Check for SQL injection vulnerabilities by using single quotes in fields and looking for internal server errors.

	==Retrieving data from other tables==		==Retrieving data from other tables==

Unknown user at 20:27, 13 April 2022

2022-04-13T20:27:46Z

← Older revision		Revision as of 20:27, 13 April 2022
Line 8:		Line 8:

	https://portswigger.net/web-security/sql-injection/cheat-sheet		https://portswigger.net/web-security/sql-injection/cheat-sheet

	~~=Notes=~~

	==Types of SQL injection attacks==		==Types of SQL injection attacks==
Line 20:		Line 18:
	* Examining the database		* Examining the database
	* Blind SQL injection		* Blind SQL injection

			=Notes=

	==Basic SQL injection attack==		==Basic SQL injection attack==

Unknown user: /* Basic SQL injection attack */

2022-03-17T00:21:08Z

Basic SQL injection attack

← Older revision		Revision as of 00:21, 17 March 2022
Line 22:		Line 22:

	==Basic SQL injection attack==		==Basic SQL injection attack==

	~~===Hypothetical Web Application===~~

	Start with a hypothetical web application. When you browse to this URL:		Start with a hypothetical web application. When you browse to this URL:
Line 40:		Line 38:

	If the category name specified by the user is not sanitized, then this web app is vulnerable to SQL injection.		If the category name specified by the user is not sanitized, then this web app is vulnerable to SQL injection.

	~~===Attacking===~~

	The value we provide for category should start with a single quote, to end the category string variable, followed by a custom SQL query for the server to run.		The value we provide for category should start with a single quote, to end the category string variable, followed by a custom SQL query for the server to run.

Unknown user: /* Basic SQL injection attack */

2022-03-17T00:20:40Z

Basic SQL injection attack

← Older revision		Revision as of 00:20, 17 March 2022
Line 22:		Line 22:

	==Basic SQL injection attack==		==Basic SQL injection attack==

			===Hypothetical Web Application===

	Start with a hypothetical web application. When you browse to this URL:		Start with a hypothetical web application. When you browse to this URL:
Line 39:		Line 41:
	If the category name specified by the user is not sanitized, then this web app is vulnerable to SQL injection.		If the category name specified by the user is not sanitized, then this web app is vulnerable to SQL injection.

	We start with a single quote to end the category string, ~~then write our own~~ SQL for the server to run.		===Attacking===

			The value we provide for category should start with a single quote, to end the category string variable, followed by a custom SQL query for the server to run.

	Here, we add the SQL symbol -- (which makes everything that follows a comment, ignoring the "AND" portion and bypassing the "released=1" condition check.)		Here, we add the SQL symbol -- (which makes everything that follows a comment, ignoring the "AND" portion and bypassing the "released=1" condition check.)

Unknown user: /* Overview */

2022-03-15T01:10:04Z

Overview

← Older revision		Revision as of 01:10, 15 March 2022
Line 4:		Line 4:

	SQL injections can have a high impact and are easy to carry out, making them one of the most common exploited vulnerabilities.		SQL injections can have a high impact and are easy to carry out, making them one of the most common exploited vulnerabilities.

			==Cheat Sheet==

			https://portswigger.net/web-security/sql-injection/cheat-sheet

	=Notes=		=Notes=

Unknown user: /* Retrieving data from other tables */

2022-03-10T23:18:52Z

Retrieving data from other tables

← Older revision		Revision as of 23:18, 10 March 2022
Line 88:		Line 88:

	it would cause all usernames and passwords to be returned, in addition to product listings.		it would cause all usernames and passwords to be returned, in addition to product listings.

			(Note, this example is oversimplified - it may take some extra work to craft the right UNION query.)

	This type of attack is called a UNION attack. See [[SQL Injection/UNION Attack]]		This type of attack is called a UNION attack. See [[SQL Injection/UNION Attack]]

Unknown user: /* Subverting application logic */

2022-03-09T21:18:03Z

Subverting application logic

← Older revision		Revision as of 21:18, 9 March 2022
Line 69:		Line 69:
	which would terminate the SQL query before the "AND" check, bypassing the password check and making any password valid.		which would terminate the SQL query before the "AND" check, bypassing the password check and making any password valid.

			==Retrieving data from other tables==

			{{Main\|SQL Injection/UNION Attack}}

			Also known as a UNION attack, this type of attack uses an SQL injection vulnerability to retrieve data about other tables in the SQL database.

			Suppose a web application runs an SQL query using a user-specified category like so:

			<pre>
			SELECT name, description FROM products WHERE category = 'Gifts'
			</pre>

			In this case, if we run with the category

			<pre>
			' UNION SELECT username, password FROM users--
			</pre>

			it would cause all usernames and passwords to be returned, in addition to product listings.

			This type of attack is called a UNION attack. See [[SQL Injection/UNION Attack]]

Unknown user: /* Basic SQL injection attack */

2022-03-09T21:08:37Z

Basic SQL injection attack

← Older revision		Revision as of 21:08, 9 March 2022
Line 50:		Line 50:
	https://insecure-website.com/products?category=Gifts'+OR+1=1--		https://insecure-website.com/products?category=Gifts'+OR+1=1--
	</pre>		</pre>

			==Subverting application logic==

			If a login page of a web application is checking for a username and password, it might use the username/password in a query like this:

			<pre>
			SELECT * FROM users WHERE username = 'user' AND password = 'nopass'
			</pre>

			If user inputs are not sanitized, SQL injection attack is possible.

			An SQL injection attack could use the username

			<pre>
			administrator'--
			</pre>

			which would terminate the SQL query before the "AND" check, bypassing the password check and making any password valid.