30 October 2009

Don't Publish Your SQL

Strange as it might seem, some people publish, usually unwittingly, detailed information about the structure of their databases by revealing SQL (Structured Query Language) code.

I don't mean in error messages (which should of course never be displayed to web site users):

Partial screen capture showing obfuscated details of a MySQL database query appearing as an error message from a web page script

Nor in the generated web page source code (you wouldn't do that would you?):

Partial screen capture showing obfuscated HTML source code from a web page with a DIV element of class 'debug' with the full database SQL string including all the parameters

Nor even when it's in a URL (I won't ask):

Partial screen capture showing obfuscated browser address bar with the full database SQL string as a URL parameter

No, what I mean is when the code is simply indexed and appears on the site's own web pages (often as search result listings), and which then sometimes subsequently picked up by Google, Bing and so on:

Partial screen capture from a web site's search results page - the first result shows a large block of SQL, the second many XML output assignment statements and the third JavaScript code comments Partial screen capture from another web site's search results page - the last two results on the first page display database SQL code Partial screen capture showing obfuscated Google search result with the page summary containing SQL code using to generate the content of the dynamic web page

So what's going on here? Without more information, I can only surmise, but I think these web sites are using catalogues (pre-built registers or collections) to index the web pages. However some of the pages have static content and others are dynamically built using database queries. So the indexing tool is recording the text from the scripting language rather than what is generated "at run time" to the web site user. These scripts should not be indexed, and thus leaked, in this way; instead the static results need to be merged and ranked with appropriate links to dynamically-created pages. If I search a dictionary web site for "query", I don't want a link to a page that has this in the code, I want the actual pages that define or reference the word "query".

The danger of automated indexing, is that it can include all types of unforeseen files in its catalogue, including backup and old copies of files, unless the indexing strategy is considered carefully:

Partial screen capture of a search results page with five identical results to an 'Edit submission' script, with different filenames such as appended with 'old' and '_bck'

Having the SQL displayed in this manner makes it much easier for someone to compromise the data, damage the site or its users.

Posted on: 30 October 2009 at 08:36 hrs

Comments Comments (2) | Permalink | Send Send | Post to Twitter

Comments

Comments are filtered automatically and should appear shortly after they been checked.

Yikes. That might be a lesson for anyone installing a well known application like WordPress, to use different table names than the default like wp-whatever.
1 Added by BWI Posted on 10 December 2009 at 20:07 hrs
I am seeing more and more business using wordpress as a website and not just a blog. its a smart move to use different table names other than the default like wp-whatever.....
2 Added by neil gunn Posted on 26 March 2010 at 13:30 hrs
Post a comment
Confirm acceptance and understanding of the terms of use
New posts to this thread will be sent to your email address
Don't Publish Your SQL
http://www.clerkendweller.com/2009/10/30/Dont-Publish-Your-SQL
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Page http://www.clerkendweller.com/2009/10/30/Dont-Publish-Your-SQL
Requested by 38.107.191.109 on Friday, 3 September 2010 at 04:21 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2009-2010 clerkendweller.com