Misuse of Privileged Database Accounts

Privileged database accounts should generally not be used by web applications. It is a very common problem but verifying this often requires access to the servers or a copy of the web site's configuration information or database. However, sometimes you are given a big clue—like this order acknowledgement email I received on Tuesday.

Now that's interesting. This makes me wonder if sales orders placed manually, say by telesales staff, have staff names appearing here. But via the e-commerce site "Database Administrator" (DBA) is entered. This could indicate the account name being used by the online system to connect to the database.

It may not be a vulnerability, but it is un-necessary information to give to customers. Even if it is a vulnerability, it may not be exploitable. There may be no technical and business impacts. But let's imagine there is a problem.

There is almost certainly no need for this function, or the rest of the web site, to use what is probably a highly privileged database account. The account may have access to many more fields, tables, views, procedures, schemas, etc than are necessary for the business process. Whilst it would be impossible for most web sites to use different accounts (connection strings) for every use, it is often possible to have a small number of accounts, such as:

• unauthenticated public user
• registration/log-on/log out/password reset
• authenticated users
• content editors
• content publishers
• site administrators
• logging (e.g. usage trends, audit trail, security log)
• scheduled application tasks.

Any people who need direct access to the database (e.g. to extract other data, or alter the schema) should have their own personal account, and mustn't use the above or DBA accounts.

These should then only have access to the appropriate methods and database assets necessary for their role. This would mean for example, a dangerous function could not be used in the database. Or, that even if a public page could be exploited by SQL injection, it would be difficult to obtain access to the database schema or extract data limited to authenticated users (this does NOT prevent SQL injection, but may partly mitigate the effects). Similarly, if the account used by logging only has INSERT permissions to a subset of tables and no other application account has access, it's going to be much harder to modify or delete log entries accidentally or maliciously.

Therefore, build database roles into your web site's design, and enforce permissions appropriately through the code. When combined with server and database hardening, it will help protect the application and your business.