Testing for Oracle - Revision history

Andrew Muller at 15:56, 31 July 2014

2014-07-31T15:56:03Z

Jane O'Connor: Final edit

2014-05-18T10:41:20Z

Final edit

Show changes

David Fern: Updates Hackproofing URL, Update orascan URL

2012-11-06T16:50:15Z

Updates Hackproofing URL, Update orascan URL

Mmeucci at 15:00, 9 October 2012

2012-10-09T15:00:27Z

Shady at 13:33, 29 April 2012

2012-04-29T13:33:12Z

KirstenS: /* Understanding how the PL/SQL Gateway works */

2009-02-08T00:29:17Z

‎Understanding how the PL/SQL Gateway works

KirstenS: Testing for Oracle (OWASP-DV-006) moved to Testing for Oracle over redirect

2008-12-15T00:01:45Z

Testing for Oracle (OWASP-DV-006) moved to Testing for Oracle over redirect

KirstenS: Testing for Oracle moved to Testing for Oracle (OWASP-DV-006)

2008-12-14T22:48:53Z

Testing for Oracle moved to Testing for Oracle (OWASP-DV-006)

KirstenS: /* Assessing Custom PL/SQL Web Applications */

2008-12-13T23:42:43Z

‎Assessing Custom PL/SQL Web Applications

KirstenS: /* Understanding how the PL/SQL Gateway works */

2008-12-13T23:39:57Z

‎Understanding how the PL/SQL Gateway works

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== Summary ==
 Web based PL/SQL applications are enabled by the PL/SQL Gateway, which is is the component that translates web requests into database queries. Oracle has developed a number of software implementations, ranging from the early web listener product to the Apache mod_plsql module to the XML Database (XDB) web server. All have their own quirks and issues, each of which will be thoroughly investigated in this chapter. Products that use the PL/SQL Gateway include, but are not limited to, the Oracle HTTP Server, eBusiness Suite, Portal, HTMLDB, WebDB and Oracle Application Server.
 <br>
-== Black Box testing and example ==
+== How to Test ==
-===Understanding how the PL/SQL Gateway works===
+===How the PL/SQL Gateway works===
 Essentially the PL/SQL Gateway simply acts as a proxy server taking the user's web request and passes it on to the database server where it is executed.
@@ Line 350: / Line 345: @@
 If this request returns books by Charles Dickens, you've confirmed the presence of the SQL injection vulnerability.
@@ Line 356: / Line 356: @@
 * Hackproofing Oracle Application Server (A Guide to Securing Oracle 9) - http://www.itsec.gov.cn/docs/20090507151158287612.pdf<BR>
 * Oracle PL/SQL Injection - http://www.databasesecurity.com/oracle/oracle-plsql-2.pdf<BR>
 <br>

@@ Line 312: / Line 312: @@
 == References ==
 '''Whitepapers'''<br>
-* Hackproofing Oracle Application Server - http://www.ngssoftware.com/papers/hpoas.pdf<BR>
+* Hackproofing Oracle Application Server (A Guide to Securing Oracle 9) - http://www.itsec.gov.cn/docs/20090507151158287612.pdf<BR>
 * Oracle PL/SQL Injection - http://www.databasesecurity.com/oracle/oracle-plsql-2.pdf<BR>
 <br>
 '''Tools'''<br>
 * SQLInjector - http://www.databasesecurity.com/sql-injector.htm<BR>
-* Orascan (Oracle Web Application VA scanner), NGS SQuirreL (Oracle RDBMS VA Scanner) - http://www.ngssecure.com/services/information-security-software.aspx<BR>
+* Orascan (Oracle Web Application VA scanner), NGS SQuirreL (Oracle RDBMS VA Scanner) - http://www.nccgroup.com/en/our-services/security-testing-audit-compliance/information-security-software/ngs-orascan/
 <br>

← Older revision		Revision as of 15:00, 9 October 2012
Line 1:		Line 1:
−	{{Template:OWASP Testing Guide v3}}	+	{{Template:OWASP Testing Guide v4}}

	== Brief Summary ==		== Brief Summary ==

@@ Line 317: / Line 317: @@
 '''Tools'''<br>
 * SQLInjector - http://www.databasesecurity.com/sql-injector.htm<BR>
-* Orascan (Oracle Web Application VA scanner) - http://www.ngssoftware.com/products/internet-security/orascan.php<BR>
+* Orascan (Oracle Web Application VA scanner), NGS SQuirreL (Oracle RDBMS VA Scanner) - http://www.ngssecure.com/services/information-security-software.aspx<BR>
 <br>

@@ Line 16: / Line 16: @@
 Essentially the PL/SQL Gateway simply acts as a proxy server taking the user's web request and passes it on to the database server where it is executed.
-# The web server accepts request from a web client and determines if it should be processed by the PL/SQL Gateway
+# The web server accepts a request from a web client and determines if it should be processed by the PL/SQL Gateway.
-# The PL/SQL Gateway processes the request by extracting the requested package name, procedure, and variables
+# The PL/SQL Gateway processes the request by extracting the requested package name, procedure, and variables.
 # The requested package and procedure are wrapped in a block of anonymous PL/SQL, and sent to the database server.
-# The database server executes the procedure and sends the results back to the Gateway as HTML
+# The database server executes the procedure and sends the results back to the Gateway as HTML.
-# The gateway sends the response, via the web server, back to the client
+# The gateway sends the response, via the web server, back to the client.
 Understanding this point is important - the PL/SQL code does not exist on the web server but, rather, in the database server. This means that any weaknesses in the PL/SQL Gateway or any weaknesses in the PL/SQL application, when exploited, give an attacker direct access to the database server; no amount of firewalls will prevent this.

← Older revision	Revision as of 00:01, 15 December 2008
(No difference)

← Older revision	Revision as of 22:48, 14 December 2008
(No difference)

@@ Line 291: / Line 291: @@
 ===Assessing Custom PL/SQL Web Applications===
-During blackbox security assessments, the code of the custom PL/SQL application is not available but it still needs to be assessed for security vulnerabilities.
+During black box security assessments, the code of the custom PL/SQL application is not available, but it still needs to be assessed for security vulnerabilities.
 '''Testing for SQL Injection'''<br>

@@ Line 14: / Line 14: @@
 ===Understanding how the PL/SQL Gateway works===
-Essentially the PL/SQL Gateway simply acts as a proxy server taking the user's web request and passing it on to the database server where it is executed.
+Essentially the PL/SQL Gateway simply acts as a proxy server taking the user's web request and passes it on to the database server where it is executed.
 # The web server accepts request from a web client and determines if it should be processed by the PL/SQL Gateway
-# The PL/SQL Gateway processes the request by extracting the requested package name and procedure and variables
+# The PL/SQL Gateway processes the request by extracting the requested package name, procedure, and variables
-# The requested package and procedure are wrapped in a block of anonymous PL/SQL and sent to the database server.
+# The requested package and procedure are wrapped in a block of anonymous PL/SQL, and sent to the database server.
 # The database server executes the procedure and sends the results back to the Gateway as HTML
 # The gateway sends the response, via the web server, back to the client
-Understanding this point is important - the PL/SQL code does not exist on the web server but, rather, in the database server. This means that any weaknesses in the PL/SQL Gateway or any weaknesses in the PL/SQL application, when exploited, give an attacker direct access to the database server - no amount of firewalls will prevent this.
+Understanding this point is important - the PL/SQL code does not exist on the web server but, rather, in the database server. This means that any weaknesses in the PL/SQL Gateway or any weaknesses in the PL/SQL application, when exploited, give an attacker direct access to the database server; no amount of firewalls will prevent this.
 URLs for PL/SQL web applications are normally easily recognizable and generally start with the following (xyz can be any string and represents a Database Access Descriptor, which you will learn more about later):
@@ Line 56: / Line 56: @@
 '''Determining if the PL/SQL Gateway is running'''<br>
-When performing an assessment against a server, it's important first to know what technology you're actually dealing with. If you don't already know, for example, in a black box assessment scenario, then the first thing you need to do is work this out. Recognizing a web based PL/SQL application is pretty easy. Firstly there is the format of the URL and what it looks like, discussed above. Beyond that there are a set of simple tests that can be performed to test for the existence of the PL/SQL Gateway.
+When performing an assessment against a server, it's important first to know what technology you're actually dealing with. If you don't already know, for example, in a black box assessment scenario, then the first thing you need to do is work this out. Recognizing a web based PL/SQL application is pretty easy. First, there is the format of the URL and what it looks like, discussed above. Beyond that there are a set of simple tests that can be performed to test for the existence of the PL/SQL Gateway.
 '''Server response headers'''<br>
@@ Line 114: / Line 114: @@
 '''Accessing Arbitrary PL/SQL Packages in the Database'''<br>
-It is possible to exploit vulnerabilities in the PL/SQL packages that are installed by default in the database server. How you do this depends on the version of the PL/SQL Gateway. In earlier versions of the PL/SQL Gateway, there was nothing to stop an attacker accessing an arbitrary PL/SQL package in the database server. We mentioned the OWA_UTIL package earlier. This can be used to run arbitrary SQL queries:
+It is possible to exploit vulnerabilities in the PL/SQL packages that are installed by default in the database server. How you do this depends on the version of the PL/SQL Gateway. In earlier versions of the PL/SQL Gateway, there was nothing to stop an attacker from accessing an arbitrary PL/SQL package in the database server. We mentioned the OWA_UTIL package earlier. This can be used to run arbitrary SQL queries:
   <nowiki>http://www.example.com/pls/dad/OWA_UTIL.CELLSPRINT? P_THEQUERY=SELECT+USERNAME+FROM+ALL_USERS</nowiki>