PL/SQL:SQL Injection - Revision history

Imifos at 10:48, 21 January 2016

2016-01-21T10:48:06Z

Imifos at 09:09, 4 December 2015

2015-12-04T09:09:06Z

Mjk303 at 21:42, 21 November 2008

2008-11-21T21:42:40Z

Mjk303 at 16:39, 13 November 2008

2008-11-13T16:39:00Z

Mjk303 at 16:38, 13 November 2008

2008-11-13T16:38:10Z

Mjk303 at 16:35, 13 November 2008

2008-11-13T16:35:01Z

Mjk303 at 16:31, 13 November 2008

2008-11-13T16:31:45Z

Mjk303 at 16:22, 13 November 2008

2008-11-13T16:22:43Z

Mjk303 at 16:14, 13 November 2008

2008-11-13T16:14:10Z

Mjk303 at 16:02, 13 November 2008

2008-11-13T16:02:42Z

← Older revision		Revision as of 10:48, 21 January 2016
Line 53:		Line 53:

	[[Category:OWASP Oracle Project]]		[[Category:OWASP Oracle Project]]
−	[[Category:~~OWASP~~ SQL ~~Project~~]]	+	[[Category:SQL]]

@@ Line 51: / Line 51: @@
 * [2] [http://www.blackhat.com/presentations/bh-europe-04/bh-eu-04-litchfield.pdf David Litchfield's presentation on SQL injection at Black Hat, May 2004]
 * [4] [http://en.wikipedia.org/wiki/Codd's_12_rules Codd's 12 rules (0..12)]
 [[Category:OWASP Oracle Project]]
-[[Category:Development]]
+[[Category:OWASP SQL Project]]

@@ Line 20: / Line 20: @@
 ===DDL===
 Alter ..  in case of a dynamic query.
 ===Database links===
 Query other databases with @database link

@@ Line 29: / Line 29: @@
 ===Stored Procedures===
-We allready creating stored procedures since we are working with PL/SQL and as you can see it is still possible to write vunerable code. Plus there is an extra vunerabilty when running on the database, [PL/SQL:Privilege escalation]
+We allready creating stored procedures since we are working with PL/SQL and as you can see it is still possible to write vunerable code. Plus there is an extra vunerabilty when running on the database, [[PL/SQL:Privilege escalation]]
 ===Obfuscation===

@@ Line 28: / Line 28: @@
 The reason that SQL injection is possible, is that the SQL statement is being generated from a language or enviroment that isn't working with SQL natively. So it does not know the consequences. The same goes for the database itself. As long as the SQL statement is syntactally correct and user that performs it has the rights, the database will execute it. There is no way for both side to determine what the impact would be. When trying to figure that out your essentially blacklisting and any new variant will be bypass your predetermined.
-==Stored Procedures==
+===Stored Procedures===
-==Obfuscation==
+===Obfuscation===
 Another solution often found is to obfuscate the table and columns. So instead of using APPUSERS we call it CWO2HIF. Now this is not going to work as one of the 13 rules that describe an Relational Database[4] is that the metadata or catalog describing the database is stored in the database. For instance a query on ALL_TAB_COLUMNS would return me all the available tables, it columns and the types.

@@ Line 23: / Line 23: @@
 Query other databases with @database link
@@ Line 30: / Line 28: @@
 The reason that SQL injection is possible, is that the SQL statement is being generated from a language or enviroment that isn't working with SQL natively. So it does not know the consequences. The same goes for the database itself. As long as the SQL statement is syntactally correct and user that performs it has the rights, the database will execute it. There is no way for both side to determine what the impact would be. When trying to figure that out your essentially blacklisting and any new variant will be bypass your predetermined.
-Another solution often found is to obfuscate the table and columns. Now this is not going to work as one of the 13 rules that describe an Relational Database[4] is that the metadata or catalog describing the database is stored in the database. For instance a query on ALL_TAB_COLUMNS would return me all the availeble tables, it columns and the types. So we need to make the understand eachother better. We can do this by seperating the data from the logic.
+==Stored Procedures==
-==Bind variables==
+===Bind variables===
 As with all languages and databases, the seperation of the SQL logic and the SQL data is the only way to prevent SQL injection. These are placeholders we can use to tell the database these parts of the query are dynamic and the rest is hardcoded. The communication is split up into multiple packages

← Older revision		Revision as of 16:31, 13 November 2008
Line 6:		Line 6:


−	==~~Lateral SQL injection~~==	+	==Attack==

		+	==Vunerabilities==
		+
		+	===UNIONS===
		+	Append the output of one or more other statements
		+	===SUBSELECTS===
		+	Blind SQL injection
		+	===PACKAGES===
		+	functions
		+	===DML===
		+	Insert, update and delete
		+	===DDL===
		+	Alter .. in case of a dynamic query.
		+	===Database links===
		+	Query other databases with @database link

@@ Line 9: / Line 9: @@
 ==Stored Procedures==
@@ Line 20: / Line 19: @@
 ==Bind variables==
-These are placeholders we can use to tell the database these parts of the query are dynamic and the rest is hardcoded. The communication is split up into multiple packages
+As with all languages and databases, the seperation of the SQL logic and the SQL data is the only way to prevent SQL injection. These are placeholders we can use to tell the database these parts of the query are dynamic and the rest is hardcoded. The communication is split up into multiple packages
-But this is how a database wants you to communicate with it. Whenever a query passed to an Oracle database for execution, the first thing the RDMS will do is make a hashvalue of the query. Next it will to find the best way to collect the data that is needed and stores that in it's memory. After he is done with that it will selects the data and pass it on to the requester.
+But this is how a database wants you to communicate with it. Whenever a query passed to an Oracle database for execution, the first thing the RDMS will do is make a hashvalue of the query. Next it will to find the best way to collect the data that is needed and stores that in it's memory. After he is done with that it will selects the data and pass it on to the requester. A general rule is that if a query is responds within several seconds it was probaly spending more time in optimisation than the actual fetching.
 This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)

← Older revision		Revision as of 16:02, 13 November 2008
Line 1:		Line 1:
−	http://www.~~securityfocus~~.com/~~infocus~~/~~1644~~	+	==Status==
		+	WIP 13/11/2008
		+
		+	==Overview==
		+	As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].
		+
		+
		+	==Lateral SQL injection==
		+
		+
		+	As with all languages and databases, the seperation of the SQL logic and the SQL data is the only way to prevent SQL injection.
		+
		+	==Stored Procedures==
		+
		+
		+	==Solution==
		+	The reason that SQL injection is possible, is that the SQL statement is being generated from a language or enviroment that isn't working with SQL natively. So it does not know the consequences. The same goes for the database itself. As long as the SQL statement is syntactally correct and user that performs it has the rights, the database will execute it. There is no way for both side to determine what the impact would be. When trying to figure that out your essentially blacklisting and any new variant will be bypass your predetermined.
		+
		+	Another solution often found is to obfuscate the table and columns. Now this is not going to work as one of the rules described by CoddSo we need to make the understand eachother better. We can do this by seperating the data from the logic.
		+
		+	==Bind variables==
		+	These are placeholders we can use to tell the database these parts of the query are dynamic and the rest is hardcoded. The communication is split up into multiple packages
		+
		+	But this is how a database wants you to communicate with it. Whenever a query passed to an Oracle database for execution, the first thing the RDMS will do is make a hashvalue of the query. Next it will to find the best way to collect the data that is needed and stores that in it's memory. After he is done with that it will selects the data and pass it on to the requester.
		+
		+	This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)
		+
		+	==Resources==
		+	* [1] [http://www.oracle.com/technology/tech/pl_sql/pdf/how_to_write_injection_proof_plsql.pdf Oracle's own paper on how to prevent SQL injection in PL/SQL, October 2008]
		+
		+	[[Category:OWASP Oracle Project]]
		+	[[Category:Development]]
		+	[[Category:PL/SQL]]