Slashdot Mirror
Oklahoma Leaks 10,000 Social Security Numbers
DrJokepu writes "Apparently the folks at the Department of Corrections of Oklahoma just forgot to use common sense when they created the state's Sexual and Violent Offender Registry. By putting SQL queries in the URLs, they not only leaked the personal data of tens of thousands of people, but enabled literally anyone with basic SQL knowledge to put his neighbor/boss/enemies on the sexual offender list. Fortunately, after the author of the blog The Daily WTF notified the department about the issue, the site went down for 'routine maintenance' on April 13 2008."
Actually, for something on this scale, I'd like to see jail time for criminally negligent programming. The cost of being on a sex offender list by mistake is mindboggling - I'm on a "have a long chat with a customs officer every time I enter the US" because some data entry monkey made a mistake with my passport, and it's not pretty. I can only imagine what being on a sex offender list can do to you...
Those who can, do. Those who can't, sue.
I'm not that surprised. This is after all the state where students don't even have to know the age of the earth to pass earth science! In a state with those sorts of values, honestly, I really don't expect the greatest in technical expertise to flock there. And even the lowest bidder should have known better. I would bet the work was done internally (only the government itself could hose something this bad).
Prediction: The real iPhone killer is going to be sex robots from Japan. Think about it.
Going to jail is a bit over the top. Losing their job is what is called for.
However, if Oklahoma has problems similar to California, then they're faced with a Hobson's choice. They can fire the guy/gal but given the low pay scales, they could well end up with someone just as bad.
Stored procedures are almost always a good idea, since you can also limit the permissions to SELECT and EXECUTE. Depending on the DB, using stored procedures also forces the use of bind variables so there's a CPU utilization optimization as well ( from the lowered parse rate ).
Not only did they put SQL in the query string, they granted more permissions to the DB user for the web app than it needed. If you're just looking up data, not changing it, why does the app need anything other than SELECT ( or EXECUTE if you're using stored procedures )?
A great example of why "just give the app admin rights so it can work" is one of the dumbest statements a developer can make.
A Human Right
READ THE ARTICLE. The same database had all criminal offenders listed - and all employees of the state corrections system. They were using an SQL query in a GET query string! You could pull up anything you wanted from the DB because they didn't lock the permissions correctly. They did a half-assed fix the first time, and only took real action when the whistle-blower pointed out that their own SS#s were accessible.
famous last words: "just Googled them".
what you're talking about seems to be an Oracle-specific thing
no, not really. in the case of sane databases, it is the norm. heck, even mysql supports them.
But like I said, since these web development frameworks generate the SQL queries for you based on your usage of their models
except that generating SQL on the fly is extremely inefficient . the database must then parse the query, measure costs and determine the best execution plan before executing the query even begins. using prepared statements and bind variables obviate the need for this, thus allowing the database to optimize the queries and choose the best execution plan.
not doing this is either ignorance or negligence. i would hope it was the former in the case of oklahoma, and seems to be the case all over.
Rather, this is a boon to those already on the list. Now they can simply claim that their status as a listee was simply a vengeful prank courtesy of an unnamed drinking buddy.
I do hope they have validated archives somewhere.
"Operating systems suck: you're better off using only the BIOS" --trainsaw.com
They knew it was 10,000 SSNs because the web site allowed them to do a COMPLETE DUMP OF THE ENTIRE DATABASE. Lock, stock and barrel.
No, not criminal, just the "data death penalty".
Require the database be erased, all backups etc.
If they can't keep it secure they can't keep it.
As a side effect (if this was their only database
they are out of a job...).
If this supported tax collections, sorry, no
collections...
How about instead of using your own name, you gather a list of the politicians who are the most hard-line with regard to the registry (e.g. once accused, always registered), and select a few of them at random. Much less risk to you, and it will certainly create a ruckus over it.
"The use-mention distinction" is not "enforced here."
An anonymous coward down towards the bottom posted this link to something similar. This one Tennessee apparently. It's no joke :(
http://www.ticic.state.tn.us/sorsql?sql=sp_SOR_IMAGE+'SO001290'&contenttype=image/jpeg
Life is rarely fair. Cherish the moments when there is a right answer.
I used to work (3 years ago) at a background checking company that would pull/harvest databases off the internet if the county or state wouldn't sell it to us in bulk. You'd be suprised how many county websites have stuff like this.
There is one county in Florida that will return more results by walking thru their ID numbers than by searching for everyone in thier site. That means people who for whatever reason aren't supposed to show up on the website get harvested by companies like the one I worked at.
A county in Texas tried to stop the harvesting by making people sign in and limiting searches but managed to introduce a sql injection hole that lets you do whatever you'd like to the Users tables. I didn't try messing w/ the offenders tables but wouldn't be suprised if it was possible.
These are just two examples that I recalls. There were quite a few more.
PHP has got to be one of the worst things that ever happened to web development.
This particular site was coded in java, so PHP was not at fault here. I don't know what got you onto the topic of PHP.
The problem is that when these projects come up, rather than contracting out to someone who knows what they're doing, or at least hiring or training somebody who can code, they go to Bob the IT guy
Software development has always been rife with contracts that go to the lowest bidder based on a spec that mentions only features and deadlines (not security, quality, or other metrics). This is because most IT projects are managed by people who don't understand IT, and who do the IT equivalent of asking their neighborhood carpenter to build the golden gate bridge. You get what you pay for.
I know I sound elitist here, but goddamn it, PHP and all those lovely little scripting languages have unleashed a disaster on the web.
If PHP didn't exist, someone would invent it. PHP fills the niche of an environment that lets you get up and running quickly with web applications, just like visual basic did it for windows apps, and access did it for databases. Yes, it's a bit elitist to say that all programming environments should be so difficult to program in that they weed out all but the most dedicated (and knowledgeable), but it's also unrealistic, because people would invent easier environments if there weren't any. PHP is actually quite good at blending the capability for quality coding with a low barrier to access.
And besides, the problems with web app security have nothing to do with PHP or any other scripting language, they have to do with visibility. Think about how many two-tier desktop apps there are that let anyone with a bit of knowledge bypass the app and do whatever they want in the database. Nobody makes a fuss about this, because the visibility of those apps is lower.
I would say the primary problem with web app development is not any of the tools, but the perception among IT managers that web app development is simpler, and requires less skill, than desktop development, while the inverse is true. I do both desktop and web development, and it is much more difficult to build good web apps, because you have to pay more attention to architecture, security, performance envelopes, and gui design. That management (even my management) still doesn't understand that is disappointing, but understandable given how the web started out as a toy and still hasn't quite shaken that perception.
Unfortunately, pretty much every intro to SQL book I have looked at encourages the use of command strings. People get used to them, and then interacting with a SQL database becomes equivalent to string parsing, which they all learned how to do in the last book.
:-)
You would be surprised what you can find grepping for cmd_str, command_string, cmdStr, etc. Please developers, parametrize your variables. This won't prevent all attacks, but there is NEVER an excuse to use command strings, especially when you are doing any sort of string manipulation on it.
http://en.wikipedia.org/wiki/SQL_injection#Preventing_SQL_Injection
I work in product security, so I am often the first security pass for code as it comes from the developers. It still shocks me that senior level database engineers express scepticism that an attacker would go to all the trouble to manipulate POST data, and tell me that they have never heard of SQL injection.
As a fun side note, it has given me multiple chances to email out links to xkcd 327
"Real action" is a joke.
They removed the link to the page and blocked off a page.
Google cache reveals the truth, and a link from there even allows searches. I can't be bothered to go SQL-injection hunting today, but I'm betting they're there from one look at the old problems at TheDailyWTF.
http://docapp8.doc.state.ok.us/servlet/page?_dad=portal30&_schema=PORTAL30&_pageid=426