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 "PL/SQL Security Cheat Sheet"

From OWASP
Jump to: navigation, search
(REGEXP_LIKE + DBMS_ASSERT)
(Migration to GitHub of the project)
 
Line 1: Line 1:
PL/SQL is a powerful procedural language built on top of Oracle SQL syntax. Extensive library of business-related and data-processing functions it incorporates makes it an attractive environment for building business-critical applications operating fully within the Oracle database. Introduction of PL/SQL Web Toolkit enabled Oracle developers to generate HTML straight from the PL/SQL code and build web applications fully residing from within the Oracle database.
+
__NOTOC__
 +
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
  
Just as any other web stack, PL/SQL web applications require careful input validation and other standard safeguards to prevent exploitable [[OWASP Top 10]] vulnerabilities.  Oracle <code>htp</code> (hypertext procedures) and <code>htf</code> (hypertext functions) packages contain the primary functions for generating output in PL/SQL web applications as well as output escaping functions. See [https://docs.oracle.com/cd/B14099_19/web.1012/b15896/pshtp.htm Oracle: The htp and htf Packages]
+
The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!
  
==Escaping output data to prevent Cross-Site Scripting==
+
An [https://github.com/OWASP/CheatSheetSeries/issues/13 open discussion] is pending about to exclude or not this cheat sheet of the V2 of the project.
Applications running on newer Oracle versions where APEX packages are available should use <code>apex_escape</code> for contextual escaping of output data in a manner similar to [[ESAPI]] validators. See [https://docs.oracle.com/database/121/AEAPI/apex_escape.htm Oracle: apex_escape]
 
 
 
* APEX_ESCAPE.HTML
 
* APEX_ESCAPE.HTML_ATTRIBUTE
 
* APEX_ESCAPE.HTML_TRUNC
 
* APEX_ESCAPE.HTML_WHITELIST
 
* APEX_ESCAPE.JS_LITERAL
 
* APEX_ESCAPE.LDAP_DN
 
* APEX_ESCAPE.LDAP_SEARCH_FILTER
 
* APEX_ESCAPE.NOOP
 
 
 
Applications should use <code>htp.prints</code> to output text blocks rather than <code>htp.print</code> as the former escapes potentially dangerous characters (<code><>"'</code>). Note that the <code>htp.prints</code> cannot be used as a simple drop-in replacement for <code>htp.print</code> because it will also escape legitimate HTML but by <code>htp</code> usage model raw HTML shouldn't be generally entered in strings but rather generated with appropriate HTML functions (e.g. <code>htp.header(1, 'Hello');</code> will output <code>&lt;H1&gt;Hello&lt;/H1&gt;</code>).
 
 
 
Sample usage in typical PL/SQL code:
 
 
 
    htp.header(1, 'Details for user ' || apex_escape.html(username)); -- outputs &lt;H1&gt;...&lt;/H1&gt;
 
    htp.print('Username: '); -- just a string literal, no need to escape
 
    htp.italic(apex_escape.html(username), 'class=' || apex_escape.html_attribute(userclass) );
 
    htp.para();
 
    htp.prints(address); -- escapes dangerous chars in address string
 
    htp.script ('var username="' || apex_escape.js_literal(username) || '";');
 
 
 
On older Oracle platforms <code>htf.escape_sc</code> for output in HTML context can be used and the <code>utl_url.escape</code> function is available to escape URL characters (<code>&"<>%</code>). URL escaping functionality is also provided by legacy <code>htf.escape_url</code> function. These functions are generally less robust than their <code>apex_escape</code> equivalents and not context-aware.
 
 
 
==Input validation and sanitization==
 
===Regular expression functions===
 
    IF REGEXP_LIKE('untrusted input', '^[0-9a-zA-z]{2,6}$') THEN /* Match */ ELSE /* No match */ END IF;
 
    select REGEXP_REPLACE('subject<<>>', '[<>]') from dual; -- returns: "subject"
 
 
 
 
 
===DBMS_ASSERT===
 
* ENQUOTE_LITERAL — Enquotes a string literal
 
* ENQUOTE_NAME — Encloses a name in double quotes
 
* NOOP — Returns the unmodified value
 
* QUALIFIED_SQL_NAME — Verifies that the input string is a qualified SQL name
 
* SCHEMA_NAME — Verifies that the input string is an existing schema name
 
* SIMPLE_SQL_NAME — Verifies that the input string is a simple SQL name
 
* SQL_OBJECT_NAME — Verifies that the input parameter string is a qualified SQL identifier of an existing SQL object
 
 
 
Example:
 
 
 
    SELECT SYS.DBMS_ASSERT.SIMPLE_SQL_NAME  ('Data with <invalid> characters') FROM dual;
 
    ORA-44003: invalid SQL name
 
 
 
See [https://docs.oracle.com/database/121/ARPLS/d_assert.htm#ARPLS231 Oracle: DBMS_ASSERT]
 
 
 
==References==
 
* [http://www.oracle.com/technetwork/database/features/plsql/overview/how-to-write-injection-proof-plsql-1-129572.pdf Oracle "How to write SQL injection proof PL/SQL"]
 
* [http://www.oracle.com/technetwork/developer-tools/adf/adfowasptop10-final-2348304.pdf Security in Oracle ADF: Addressing the OWASP Top 10 Security Vulnerabilities]
 
 
 
==Authors==
 
* Pawel Krawczyk
 
 
 
== Other Cheatsheets ==
 
 
 
{{Cheatsheet_Navigation_Body}}
 
 
 
[[Category:Cheatsheets]]
 

Latest revision as of 10:15, 16 February 2019

Cheatsheets-header.jpg

The Cheat Sheet Series project has been moved to GitHub!

An open discussion is pending about to exclude or not this cheat sheet of the V2 of the project.