Simple Talk is now part of the Redgate Community hub - find out why

Tying Down the Source Code

Database source code analysis can flush out weakly-authenticated database users, over-privileged users and roles, or stored procedure code that concatenates a parameter directly into the dynamic SQL string that is to be executed, and so is vulnerable SQL injection. This is great for the development team, but it is also wonderful for the hacker.

Getting hold of the results of static code analysis for a database could save the attacker a lot of time. To know even just the names of tables can save hours of work in a SQL injection attack. If you know the columns too, then it all becomes easy. Getting the code for views and routines is a gift. Knowledge of where the vulnerable areas of the databases lie, makes the hacker’s task much easier.

Does this mean that database source code analysis is a bad thing? Not at all: it just illustrates how important it is to get database source control security and access control right. It also emphasizes how misleading it is to assume that database source control as just the same as application source control. It isn’t. In many organizations, the finance and medical professions in particular, the live database will be subject to rigid security procedures, enforced by legislation; users will only be able to see those parts of the database to which they have the appropriate access rights. To comply with current security standards, even database developers will only be able to view or change database objects that are within their remit. To make the source accessible would be to subvert all this security!

No, the source will need to be ‘tied down’ too, so that it reflects the access control regime in place within the database itself. It doesn’t mean more security: just consistent security. It’s likely that application developers, for example, will have access only to the published interface, rather than the underlying base tables and routines. Likewise, the reports from source code analysis that expose this metadata will have to be restricted.

We can all agree on the many advantages of database version control, but as always for certain organizations the way it has to be implemented is more nuanced, and requires a lot more careful planning than one might first anticipate.

Commentary Competition

Enjoyed the topic? Have a relevant anecdote? Disagree with the author? Leave your two cents on this post in the comments below, and our favourite response will win a $50 Amazon gift card. The competition closes two weeks from the date of publication, and the winner will be announced in the next Simple Talk newsletter.

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue

Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue