This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Testing for Oracle"
(→Gray Box testing and example) |
|||
Line 4: | Line 4: | ||
== Brief Summary == | == Brief Summary == | ||
<br> | <br> | ||
− | + | This section describes how to test an Oracle DB from the web. | |
<br> | <br> | ||
== Description of the Issue == | == Description of the Issue == | ||
<br> | <br> | ||
− | ... | + | Web based PL/SQL applications are enabled by the PL/SQL Gateway - it is the component that translates web requests into database queries. Oracle has developed a number of different software implementations however 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 paper. 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> | <br> | ||
== Black Box testing and example == | == Black Box testing and example == | ||
− | ''' | + | |
− | .. | + | '''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. | |
− | ...< | + | |
− | + | 1) Web server accepts request from a web client and determines it should be processed by the PL/SQL Gateway | |
− | ...< | + | 2) PL/SQL Gateway processes request by extracting the requested package name and procedure and variables |
+ | 3) Requested package and procedure is wrapped in a block on anonymous PL/SQL and sent to the database server. | ||
+ | 4) Database server executes the procedure and sends the results back to the Gateway as HTML | ||
+ | 5) Gateway via the web server sends response back to the client | ||
+ | |||
+ | Understaning this 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): | ||
+ | |||
+ | <nowiki>http://www.example.com/pls/xyz</nowiki> | ||
+ | <nowiki>http://www.example.com/xyz/owa</nowiki> | ||
+ | <nowiki>http://www.example.com/xyz/plsql</nowiki> | ||
+ | |||
+ | While the second and third of these examples represent URLs from older versions of the PL/SQL Gateway, the first is from more recent versions running on Apache. In the plsql.conf Apache configuration file, /pls is the default, specified as a Location with the PLS module as the handler. The location need not be /pls, however. The absence of a file extension in a URL could indicate the presence of the Oracle PL/SQL Gateway. Consider the following URL: | ||
+ | |||
+ | <nowiki>http://www.server.com/aaa/bbb/xxxxx.yyyyy</nowiki> | ||
+ | |||
+ | If xxxxx.yyyyy were replaced with something along the lines of “ebank.home,” “store.welcome,” “auth.login,” or “books.search,” then there’s a fairly strong chance that the PL/SQL Gateway is being used. It is also possible to precede tha requested package and procedure with the name of the user that owns it - i.e. the schema - in this case the user is "webuser": | ||
+ | |||
+ | <nowiki>http://www.server.com/pls/xyz/webuser.pkg.proc</nowiki> | ||
+ | |||
+ | In this URL, xyz is the Database Access Descriptor, or DAD. A DAD specifies information about the database server so that the PL/SQL Gateway can connect. It contains information such as the TNS connect string, the user ID and password, authentication methods, and so on. These DADs are specified in the dads.conf Apache configuration file in more recent versions or the wdbsvr.app file in older versions. Some default DADs include the following: | ||
+ | |||
+ | SIMPLEDAD | ||
+ | HTMLDB | ||
+ | ORASSO | ||
+ | SSODAD | ||
+ | PORTAL | ||
+ | PORTAL2 | ||
+ | PORTAL30 | ||
+ | PORTAL30_SSO | ||
+ | TEST | ||
+ | DAD | ||
+ | APP | ||
+ | ONLINE | ||
+ | DB | ||
+ | OWA | ||
+ | |||
+ | |||
+ | |||
'''Result Expected:'''<br> | '''Result Expected:'''<br> | ||
...<br><br> | ...<br><br> |
Revision as of 15:49, 1 December 2006
[Up]
OWASP Testing Guide v2 Table of Contents
Brief Summary
This section describes how to test an Oracle DB from the web.
Description of the Issue
Web based PL/SQL applications are enabled by the PL/SQL Gateway - it is the component that translates web requests into database queries. Oracle has developed a number of different software implementations however 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 paper. 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.
Black Box testing and example
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.
1) Web server accepts request from a web client and determines it should be processed by the PL/SQL Gateway 2) PL/SQL Gateway processes request by extracting the requested package name and procedure and variables 3) Requested package and procedure is wrapped in a block on anonymous PL/SQL and sent to the database server. 4) Database server executes the procedure and sends the results back to the Gateway as HTML 5) Gateway via the web server sends response back to the client
Understaning this 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):
http://www.example.com/pls/xyz http://www.example.com/xyz/owa http://www.example.com/xyz/plsql
While the second and third of these examples represent URLs from older versions of the PL/SQL Gateway, the first is from more recent versions running on Apache. In the plsql.conf Apache configuration file, /pls is the default, specified as a Location with the PLS module as the handler. The location need not be /pls, however. The absence of a file extension in a URL could indicate the presence of the Oracle PL/SQL Gateway. Consider the following URL:
http://www.server.com/aaa/bbb/xxxxx.yyyyy
If xxxxx.yyyyy were replaced with something along the lines of “ebank.home,” “store.welcome,” “auth.login,” or “books.search,” then there’s a fairly strong chance that the PL/SQL Gateway is being used. It is also possible to precede tha requested package and procedure with the name of the user that owns it - i.e. the schema - in this case the user is "webuser":
http://www.server.com/pls/xyz/webuser.pkg.proc
In this URL, xyz is the Database Access Descriptor, or DAD. A DAD specifies information about the database server so that the PL/SQL Gateway can connect. It contains information such as the TNS connect string, the user ID and password, authentication methods, and so on. These DADs are specified in the dads.conf Apache configuration file in more recent versions or the wdbsvr.app file in older versions. Some default DADs include the following:
SIMPLEDAD HTMLDB ORASSO SSODAD PORTAL PORTAL2 PORTAL30 PORTAL30_SSO TEST DAD APP ONLINE DB OWA
Result Expected:
...
Gray Box testing and example
Testing for Authentication credential management:
- Unlimited failed login attempts
Check the FAILED_LOGIN_ATTEMPTS parameter:
This can be achieved by ht e following SQL:
List security related profile information
conn / as sysdba col profile format a20 col limit format a20 select profile, resource_name, limit from dba_profiles where resource_name like '%PASSWORD%' or resource_name like '%LOGIN%'/
The FAILED_LOGIN_ATTEMPTS parameter is used to limit to the number of failed login attempts allowed before a user account is locked by the data base.
FAILED_LOGIN_ATTEMPTS can be set to a specific number of attempts; to UNLIMITED (never lock an account), to DEFAULT, which refers to the value indicated in the DEFAULT profile.
Setting this value reduces the potential success of a brute force attack and alerts. Once an account is locked it can not be logged into for a defined number of days or until the administrator unlocks the account.
- Password Expiry
- Password reuse
- Unencrypted Database Link Password
- Default Roles
- PUBLIC Object Permissions
- UTL Package Permissions
- Default Tablespace
Result Expected:
...
References
Whitepapers
...
Tools
...
OWASP Testing Guide v2
Here is the OWASP Testing Guide v2 Table of Contents