How can releasing the text of an SQL query compromise security?

Question

I have asked a government agency, under Freedom of Information legislation, to release two SQL queries they ran to produce a table which they published in a report.

That is, the agency published these two tables of figures showing, for each year, the number of cases completed under various categories and some aggregated statistics for each category. I want to see the query used to generate each table, in order to see how the data was filtered and precisely how the agency defined each category.

The agency has refused my request on the basis that releasing any SQL queries will prejudice their information security.

Under the relevant legislation, I now have the opportunity to apply for a review of this decision, in which I would have to explain why the agency's reasoning is flawed.

To my mind, the only way this could possibly be a security risk is where an attacker uses the information about table and column names to launch an SQL injection attack. However, the database in question is an internal data warehouse with no publicly-accessible web applications accessing it and, in any case, the agency has strict coding standards and penetration testing, etc, for preventing things like SQL injection vulnerabilities.

I can also imagine that if the agency was, say, the US National Security Agency, and the database was called 'overseas_phone_taps_by_country', then the table/column names would themselves be sensitive information. In this case, however, we are talking about an accounting database held by a pretty boring regulatory agency.

Again if the query was one used to generate lists of cases, then I could see the issue, since the query would contain things like the threhold at which a case will be considered for enforcement action, etc. However, that is not the case here.

How could releasing the text of an SQL query be a security risk?

EDIT: The agency provided the following explanation in their refusal letter:

SQL queries contain information about the agency's information systems (information related to the content, location and storage of sensitive information), which, if released, could reasonably be expected to increase the risk of compromise to the agency's information systems.

As such, I consider that disclosure of the SQL queries represents a potential security risk to the agency.

The advice from the agency's security expert reads:

I am of the opinion that the release of the SQL queries, even in a redacted form, would provide information about the programmable interfaces and logic flow within our systems, and give information about identifiers, pointers and references that would compromise the security and safety of the agency's systems.

Answer 1

They probably have a DBA who has been told that you shouldn't let people know the structure of the database due to SQL injection risks. As you mention though that doesn't make a ton of sense for an internal database.

There's no obvious risks to releasing a query from a security standpoint. What was their exact wording of the reason they refused it?

Answer 2

Generally when you are trying to secure an application you want to make sure that you aren't disclosing any information that could potentially be used as part of an attack. This is the same reason that it is more secure to display a generic error page instead of a stack trace. Even though seeing the stack trace probably isn't a vulnerability itself - it makes life easier for an attacker gathering information about the system.

This should not be confused with "security through obscurity" in which you rely on something being secret to maintain security. The assumption is that every effort has been made to secure the application in question.

It doesn't really matter whether the application is internal or not in my opinion. You routinely hear stories about hackers breaching government networks (sometimes hiding in there for years), so the fact that it's on an internal network doesn't mean it is safe from external threats.

Also having strict security guidelines and performing penetration tests doesn't guarantee 100% security either. If you talk to anyone who does pentests for a living they won't guarantee that they find 100% of security issues (and if they do they are probably blowing smoke).

Answer 3

Maybe would be better to just ask the agency "How the data was filtered and precisely how the agency defined each category?"

While I agree that hiding SQL to add security is just "security by obscurity", I also fail to see why providing the SQL queries would be the best way to provide the information you need or claim to need.

Answer 4

They could easily substitute the actual table and column names with aliases. However, from a security perspective, even a completely unredacted SQL query is unlikely to release any information that would be useful to an attacker. Once an attacker gains dba level access to the database, querying the schema is trivial. The reverse is not true.