When you interact with a web page you're often interacting with a database of some sort. The simplest way to do this is to take text the user has submitted, put some SQL around it (standard database language), and the SQL will update the database, or get results back, etc. Some implementations even put the query string, including the SQL, in the URL.
The problem with this approach was discovered in the 1990s. You can write your own SQL in the URL, or, with a bit more work, you could type the SQL into the web field and the database would act on it.
The problem keeps returning, most recently in Oklahoma. Schneier describes the story (with an implied deep sigh), but I most appreciated one of the comments ...
Schneier on Security: Oklahoma Data Leak
... If you take the standard Google query for locating GET/sql servers (see http://www.memestreams.net/users/acidus/blogid10326823/ and further restrict it to .gov domains, several somewhat sensitive websites from the District of Columbia government show up --- including "Alcoholic Beverage Regulation Administration --- Suspended and Revoked Licenses", and "Department of Health --- Food Establishment Closures".
It's nice to know a simple Google query can expose vulnerable sites so readily. Another comment mentions a similar problem last year with Germany's security services.
The real lesson here is that all of your data will be public one day. Sooner or later it will leak by one security flaw or another. If they gather it, they will lose it.
If you really don't want data to be public, don't provide it in electronic form. Happily, most data about most of us is so boring it's only of interest to the extremely rare individual who wants to steal our identity, credit card, etc. Oh, wait ...
No comments:
Post a Comment