After analyzing the SQL Connect tool data which calls the BIP  stub - I see that anything passed to it internally gets wrapped by:

select * from (:sql);

so I believe there's very minimal risk to SQL injection, although you never know internally how Oracle handles select * from (); constructs, so there still is a possibility.

I have heard that Oracle is developing its own web service based connector for their own tools, possibly SQL Developer - so this is something they may have changed for their code.

Hi Eric & David,

I'm speculating there, which is why I was asking if anyone has seen and could post an official pronouncement from Oracle on this.  But my guess is that just because this one SQL Connect tool wraps the :sql bind variable doesn't preclude some type of injection - or that other tools (or regular BI data models) wouldn't be more at risk if REF CURSORs are left open.  And if the user account has update privileges, there could be the potential that a series of statements get passed in.

Again, that's conjecture on my part but I'd assume the vulnerability's there first and try to prove otherwise.  I'm with you (and others) in that some form of SQL Developer-type direct access would be a welcome addition, I just don't find the current process of manual ad hoc data models that onerous.  If you're going to give people access to a REF CURSOR tool, why would you need sysadmin involvement for migrations as a workaround?  What's the concern with having these analysts/support team members create their queries in their own 'My Folders' area?  And better still, doing that in a recent clone that's part of your overall instance management strategy?

Glen

This will have a severe impact on running SQL's without new Data models.

Webservice accepting SQL as a parameter should be launched to overcome this.

We are looking at the BIP web services and so far it looks feasible to have an application to accept the SQL, create a data model from the SQL. You can have a generic report that produces CSV output from the data model which you can kick off via web services as well. 

Essentially, build a tool that takes your SQL, creates a dm on the fly, and executes and returns the result. As far as 20D is concerned, it is NOT dynamic SQL. But it is for your purposes!!

No need for admin. Integration Specialist should work.