Question

We have a web page on internet that calls a web service located on our intranet.

The web service talks to Database A to get some data.

Database A has a DBLink to Database B. This link is used to select data from Database B, but it is not used by the service anyway.

However, my boss requested that I remove DBLink and use an alternative because DBLink might be vulnerable.

What do you think of that? And what should I do to avoid that vulnerability?

Was it helpful?

Solution

The web service talks to Database A to get some data.

So the application should connect to the Oracle database using credentials that allow it to access [only] the data that it needs to do its job.

Database A has a DBLink ... used to select data from Database B, but it is not used by the service anyway.

So the account used by the web service should have no permissions on this DBLink or the tables/objects made accessible (in Database B) through that DBLink.

... requested that I remove ... because DBLink might be vulnerable.

It is no more vulnerable than any other object in a [properly secured] Oracle database.

Of course, if your application is connecting with massively overpowered credentials, giving it far more access than it actually requires, then yes; you might have a problem.

Of in doubt, test it. Log into the database manually using those credentials and see what you can see.

OTHER TIPS

A DBLINK in Oracle is usually scoped to a user, unless you have specifically created it PUBLIC. If your app connects to A as user X but the DBLINK to B is owned by user Y and X has no permission on Y’s schema then there is no additional vulnerability introduced here.

In other words, it might be secure, it might not, depending on how it’s set up. You need to talk to your friendly local DBA. Neither we nor your boss apparently have sufficient details to make a judgement.

Is Oracle DBLink Vulnerable?

Likely so

[...]
What do you think of that? and what should i do to avoid vulnerability?

Not a big deal? Just make sure it rests behind TLS. Alternatively, behind firewalls, behind VPN software if necessary.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top