Tying Down the Source Code

Comments 0

Share to social media

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.

About the author

Tony Davis

See Profile

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the Simple-talk.com and SQLServerCentral.com websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his Simple-Talk.com blog or his SQLServerCentral.com author page.

As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management.

In his spare time, he enjoys running, football, contemporary fiction and real ale.