I am not sure that you will be able to see Robs post on his Facebook; I am connected to him so I see it but its unclear if its findable without a connection but connect to Rob if you want to see it. The list is what i have said above anyway. Rob also has his site Oracle Wizard.
It is a good point; should SQL Injection in Oracle demos be made in SQLCl or SQL*Plus or from a webpage? - I have been at both ends of this spectrum for many years. I wrote what i think were the some of the first Oracle SQL Injection papers 15 years ago in 2002 for Security Focus (Now Symantec). These are:
SQL Injection and Oracle Part 1
Sql Injection and Oracle Part 2
Detecting SQL Injection in Oracle
These papers were written a long time ago - 14 - 15 years ago in fact but they are still mostly relevant in the principles. The formatting on the Symantec website is not good for some of the content but they are readable.
I also wrote the first big paper by anyone on Oracle Security in 2001 - which is available on the Pentest Website to read still. This is old but some of the thought patterns are still good and I mention SQL Injection against Oracle in that paper as well.
Whats the point of these references; well back in 2001 not many people were doing SQL Injection or most likely had even heard of it. Certainly the Oracle community (DBA, Devs, etc) most likely did not consider the risk of SQL Injection in Oracle databases. The DBMS_ASSERT package did not exist until 2004 but probably not in wide use until 2005/2006. The large slew of PL/SQL injections in built in packages had not started in 2001 / 2002. The alerts program was only just getting going in 2001 and these were the only security patches released on an "as-when" basis. The CPU security patch regime did not start until 2005 (If i remember correctly). The large onslaught of built in packages with Sql injection or PL/SQL injection came in the middle of this period.
At the time in 2001 I wanted to write my papers and make a point to the reader that this is a code problem not a web problem. Hence I used SQL*Plus as the vehicle to deliver the injection examples to the database and to show how SQL Injection works. I wanted people to realise that they still have a problem if some code is vulnerable to injection even if there is no website to access the code from.
I teach about SQL Injection still in my OracleSecurity classes ; in fact I cover SQL Injection in depth in the secure coding in PL/SQL class and also in the secure and lock down Oracle class and its covered also in the Audit trail design class and also the 2 days class on how to perform a security audit of an Oracle database. SQL Injection has not gone away.
Nowadays I do what Rob is talking about; I have two web applications; one is Worpress 2.0 ported to use Oracle as its database and not MySQL and the other is my own web based application written in PHP (actually its written in PL/SQL as the PL/SQL packages I have written generate PHP for me). This application I call BOF - "Back OfFice" and it was described in a blog post called BOF: A Sample Application For Testing Oracle Security about a year ago. I demonstrate quite a lot of hacking against the PHP websites and show SQL injection, injecting PL/SQL into SQL and also DDL injection. In fact I cover all sorts of stuff from adding users, showing code, adding back-doors, changing passwords, removing audit settings and much more. This is always great for the participants, they love it, they get mesmerised, sit on the edges off their seats and get really excited - Its fun to do BUT does it get across the message that this is a scripting language issue (PL/SQL in this case) in the database and not a website issue. In fact in some of my demos I go 5 layers deep; I inject DDL into dynamic PL/SQL that is itself injected into dynamic PL/SQL that is injected into a SQL in a PL/SQL function that was injected into the SQL statement in the PHP layer. Why so many layers well this was necessary to inject DDL into this particular application (Wordpress). Also i injected IDS evasion techniques to get around the security protections in the PHP in Wordpress as well. This is exciting and fun BUT people don't get this complexity to achieve something. Also the statements I inject are pre-designed. If i walked up to this Wordpress application blind (which I actually did when i wrote the samples) then it takes literally thousands of requests to get something that works - you cannot demonstrate that part and some people question - How did you know how to send such a complex attack string? - then i have to explain and the magic wears off a little.
This is why I also demonstrate attacks using SQL*Plus and this fits nicely. I show four levels of attack;
1) Attacking the website logon form and also search form as a non-authenticated user (no logon on the site, no logon on the database)
2) Attacking the website as an authenticated (website authenticated) user by exploiting the wordpress post, page, comment,...etc pages (no database password)
3) Attacking the database via SQL*Plus as a low level user - CREATE SESSION only
4) Attacking the database via SQL*Plus as a powerful user - CREATE SESSION and DBA roles.
This covers both worlds, it shows the excitement of hacking a website and shows how to avoid security layers in the application and also how to do various injections, SQL into SQL, PL/SQL into SQL, PL/SQL into PL/SQL and DDL into PL/SQL into SQL BUT it also shows the problem at the most simplistic layer; i.e. as close to the problem as possible; executing a PL/SQL procedure and exploiting it.
My view, do both but focus on the SQL*Plus examples as its easier to see whats happening and it illustrates that its not a web problem but a code problem.