SQL Injection attacks?

RosyCross

Is it possible to attack the databases that OBIEE is connected to via sql injection attacks?

Robert Angel

Yes, things like evaluate expose the databases, which is why your connection pool connections should be users with very restricted rights against the database.

RosyCross

Ok - thanks!

Gianni Ceresa

RosyCross wrote:Is it possible to attack the databases that OBIEE is connected to via sql injection attacks?

Not by default ...

EVALUTE functions are disabled by default and need to be enabled explicitly in your OBIEE BI Server config file. Add this on top of the fact that your user need the required privileges to use it (a consumer will not be able to do it), and if you really need security you also have filters setup in the RPD which can't really be bypassed easily.

So out of the box the answer is NO, and if you then do things right the answer is still NO. If you have no idea of what you are doing in your OBIEE and enable things and randomly setup security ... then YES.

Sorry @Robert Angel to disagree with your "yes", it's a PEBCAK generated "yes".

Robert Angel

Hi Gianni,

happy to be wrong but I would defend my 'yes' by saying that evaluate is very widely used and the question was around 'possible', so 'yes', it is possible, but only if both the connection pool user has sufficient rights and as you rightly state that evaluate is configured to be useable.

I would also mention writeback where I suspect, but have not tested, that the creative could easily exploit it - provided the rights on the DB were sufficient, yes - perhaps this is more an Id10t issue as you say....

RosyCross

The clarification is useful - we use evaluate - so I will seek assurance from the DBAs that the connection pool users are squibs.

many thanks!!!

[Deleted User]

Sorry to also disagree with you, @Gianni Ceresa  :-P

It is only PEBKAC if EVALUATE is activated in the NQSConfig.ini to begin with.

Just to be a pain...

Gianni Ceresa

Yes, on this one you are just a pain ...

EVALUTE functions are disabled by default and need to be enabled explicitly in your OBIEE BI Server config file

I wrote the same in the end

And still didn't find a single OBIEE where the NQSconfig.ini edited itself enabling EVALUATE without a human interaction, therefor PEBCAK is the only possible way for EVALUATE

Robert Angel

Sincere apologies for my part in sowing discord amongst the Superheroes on the board, and sorry to re-raise the subject which you probably both consider closed, but I still feel the answer here should be to prevent it in the database layer, as an erstwhile plsql developer I know that is what I would do as a DBA if asked for a user for OBIEE, I would make sure it had read only rights on DB tables. And if the requirement was later altered to have update rights for writeback purposes then I would grant update rights for the table(s) involved only.

Putting my BI Architect hat back on I would see evaluate as too valuable to turn off; though personally I rarely resort to using it; and in any case would prefer the assurance of DB security being sufficient to prevent injection as what follows my OBIEE project may not be as well thought out as I would hope.

Writeback - well that is a different kettle of poorly cooked fish which I would all too gladly lose.

Gianni Ceresa

I'm totally with you on this Robert!

Security being made by humans I would anyway adopt a multi-layer approach: protect everything at the best. DB accounts used by OBIEE are without content (so just the accounts) and are granted read only access to the required objects (ideally table/view level, worst case schema level if small well compartmentalised schema).

And all the things along that line ...

Robert Angel

Lines of defense - so only on the failure of all layers is the data exposed to risk?

Yes, that is superior to my database-centric - stance I agree!