[Previous entry: "A hint of Oracle's coding standards"] [Next entry: "Speaking events, SQL Hashes and clever password crackers"]
02/14/2008: "Oracle Defending Against SQL Injection Tutorial"
Post to del.icio.us
Post to Furl
I posted yesterday about Mary Ann's post that mentioned the internal Oracle Security coding standards and Kris made a post to my blog about a very nice Oracle Corp tutorial (really a CBT) called Defending Against SQL Injection Attacks. This was posted to Lutz's blog first.
This tutoral is on Oracle's website and can be run from there. The page is titled "Tutorial on Defending Against SQL Injection Attacks!". Ther is also a link on the same page to download the tutoral so that you can run it locally. I would recommend grabbing it to ensure that you have a copy.
This is a superb tutoral, well written and positioned just right. The tutorial starts with a note that the three worst issues reported in a 2006 report by Fortify are Cross Site scripting (21.5%), SQL Injection (14%) and PHP includes (9.5%). The tutorial starts by explaining what SQL Injection is with some good flash examples and how to avoid SQL Injection. It includes first order and second order attacks and also discusses reducing the attack surface, removing API's, use of invoker rights, reducing arbitary inputs and more. The tutorial goes on to talk about avoiding dynamic SQL, how to use static SQL and what to do if you must use use dynamic SQL.
A good section discusses the use of bind variables and also covers what to do if its not possible to use binds. A detailed lesson also covers the use of DBMS_ASSERT and this is one of the most detailed I have seen. It also includes for the first time an explanation of the DBMS_ASSERT.NOOP function. This, we can now clarify is used to mark a piece of code that is not to be tested by automated test tools (presumably Fortify) as this function does nothing except return the string passed unchanged.
There is also a discussion on identifiers and writing your own filters and also a section on designing code so that its not vulnerable in the first place. The testing section is excellent as it discusses the need to have code reviews, static analysis and also fuzzing for dynamic analysis. The best parts are an insight into the 300 page document as there is a code checklist and a nice names test case list for testing.
Each section also includes a nice quiz. This is a good document and one of the best security documents I have seen from Oracle.
