In the day before SQLSaturday my work sent me to a lead-in event that was a SQL training called "Murder They Wrote" hosted by a Jason Brimhall and a Wayne Sheffield. This day long training was fantastic and honestly much better than SQLSaturday itself. I suspect I could have skipped SQLSaturday if not for the session I found there on PowerShell. Anyways, I will try to start putting my Murder They Wrote notes to my blog. I was have to break this up into a few posts as there is a lot to cover. SQL is set-based and declarative and in SQL's situation this means that you as a user tell SQL what to do and it tries to find the best way to do it. If you try to tell SQL what to do every step of the way it will oblige you and you will have performance problems. If you're running as sysadmin and an attacker successfully attacks through a SQL injection attack, the hacker can do anything he/she wishes to your database. If the same account is also an administrator at the machine at hand the attacker may highjack the machine and perhaps move outside that boundary even to wreak havoc at the greater LAN beyond. The speakers told a story of a company that was hacked through SQL injection attacks wherein the attacker(s) got usernames/emails/passwords for accounts. The company in question wasn't Yahoo, but Yahoo was also hacked and it was another example of a scenario in which the party keeping plain-text passwords was exposed for its sloppiness. If usernames/emails/passwords may be "recovered" in an attack, the attacker may then go fishing at gmail and PayPal and the like with the same credentials as people have a habit of using the same password everywhere. A common SQL injection attack is to push in as in input value Whatever' OR 1=1;- which is going to expose too much when injected inside of SELECT Username, Password FROM dbo.Users WHERE Username='Minnie' AND Password='????'; Imagine Whatever' OR 1=1;- in place of the four question marks and I think you'll see the problem. You'll get back all of the Minnies when you should only see one. If you see an application blow up when you enter a last name with a hyphen like O'Mally in a form field that is a good sign that the form may be used for SQL injection attacks. There are two varieties of SQL injection attacks:
- immediate
- delayed
The many Minnies example, a stereotypical SQL injection attack, is an example of an immediate attack. In a delayed attack, in contrast, one just does an insert, perhaps shoving in the 1=1 hack, and a dirty record sits within the database waiting to be used. If values out of the database are ever used in conditional SQL then problems will occur. There is no way to deal with a delayed SQL injection attack other than to never, never, never use queried data in predicates (where clauses).
No comments:
Post a Comment