Oklahoma Finds Next Level of Stupidity

Wow. That is all that I have to say after reading this article:

Oklahoma Leaks Tens of Thousands of Social Security Numbers, Other Sensitive Data.

Technically, State information is public... But this goes beyond overshare. You just know that the application account has escalated privileges... I have to go back to my opening statement; wow. What a kick in the head...

Tags: security, sql injection

SQL Injection: Not an Issue

Denis Gobo has a post about Microsoft addressing SQL injection. Microsoft is being more proactive in preventing SQL injection by providing tools to scan sites and code. Here is a thought; stop publishing example code with inline SQL. Best practices are 'best' for a reason. Denis closes by stating that the 'problem is of course that you should never ever run as dbo or even worse sa.' And it really is almost that simple. An application account should have the minimum permissions needed for execution. If you use stored procedures, you do not even need to grant select permissions on tables (you aren’t using dynamic SQL, are you?). What is better than that?

Best practices tell you to check your inputs but really you can be rather lazy about this if you are parameterizing (it’s a word now) your stored procedure calls and are not using dynamic SQL; pretty hard to inject a string into a number field. That means that all you need to do is validate strings. Even if you do not do that, the account can only connect and run procedures. Failing this (because you really absolutely cannot see how you cannot use dynamic SQL (think harder)), use parameterized queries. Make certain that the application limits inputs—why is a name field large enough to contain an entire SQL block?

So what have we learned?

• Minimum permissions
• Use stored procedures
• Check your inputs

I do not mean to oversimplify, but I cannot make it sound complicated. If you code right, your work is done. SQL injection is an issue for half-assed developers. The end.

Tags: sql injection, security

Oracle Issues Patches for the 33% That Patch

Oracle realeases 27 patches for their product line.

In related news, a majority of Oracle DBA's don't care!

I have met Oracle DBA's that are guilty of this. Part of this, I feel, is media sensationalism. If your database server is on the inside, it may not be a huge issue; that is what network security is about. 99.98% of corporate users do not password protect their documents! But if the outside world can access your data, it is an issue. The past few years have shown us the need for more pro-active security.

Another side of that would be Oracle's patch track record. Their patches are not always what DBA's consider successful. But part our job as DBA's is to protect the data.

So are you guilty of not patching your production environments in a timely manner?

Poor Data Control

The Brits take another huge slap in the face: Britain Admits Losing Data of 3 Million Student Drivers. Last month it was 25 million citizens.

Bruce Schneier briefly covers CSO's article "The Top 10 Data Breaches of 2007."

This makes me very sad. I recognize that these instances are not necessarily the failings of DBAs, but with sensitive data comes responsibility; keep your environments locked down. It is better that these occurrences are being admitted to. It does lead us to wonder how many more incidents go unreported.

Why 'Anonymous' Data Sometimes Isn't

Bruce Schneier wrote a very interesting piece about de-anonymizing data. Linking disparate data is a fascinating topic (in my opinion) and he goes into the security concerns.

In other news, Handbook of Applied Cryptography is publicly available, legitimately. Personally, I would recommend Schneier’s Applied Cryptography which is a great read; one of those books you never think you will finish, but it goes quick thanks to interesting contents and good writing.