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.


  • Rate
    [Total: 1    Average: 5/5]
  • Venkataraman Ramasubramanian

    We have used HP Fortify Static Code analyzer to look for code issues. http://www8.hp.com/us/en/software-solutions/static-code-analysis-sast/ . It has pointed out some issues with the database code also. It is very comprehensive and lists the issues in .NET and other source code also.

  • Peter Schott

    Haven’t had to deal with this much security yet where the developers can’t know the DB schema. I agree that the source shouldn’t be available to more than those who need it, but most of my shops have been ones where the developers stage a local DB with dummy data that they can use to test/code against. When they’re done, they blow it away to reset it or just leave it for their starting point.

    I could see this for some shops where it could be a concern, but if there are any parts that depend upon each other, it’s helpful to have those present or at least subsets of them. If it’s a major concern, then the work needs to be separate and developers need to hit a controlled development DB server, but that’s definitely more than we’ve had to concern ourselves with to date.

  • Keith Rowley

    I wonder how we do performance tuning for databases that need this level of security. Do we give maintenance DBAs more security than database developers to allow this? Do we really want a hard and fast line between people who are writing code for data access and those who have to optimize the database to make that code run fast?

  • rogerthat

    I don’t buy it. It is required to eliminate unauthorized, unlogged access; to limit exposure to those personnel that require access to perform their function; it is not required to hide details of the schema. It would be impossible to make the best use of the database without access to the schema.
    The vulnerabilities you are mentioning have more to do with a failure to either implement or follow proper security protocols.
    You might as well talk about writing down accounts and passwords on sticky notes.
    I fully support developers not having access to production servers and accounts, using either test or scrubbed data in dev and test, utilizing VDIs to further lock down access to production servers; but “hiding the schema” is not something I could ever back or want to be a part of.
    There is a world of difference between knowing a database schema and being subject to SQL injection. Even junior programmers are aware of SQL injection and there are built-in defenses in such tools as Visual Studio, and numerous web frameworks. In this era, if your application allows SQL injection, you are probably in the wrong field.

    • Keith Rowley

      Amen to this.