April 28, 2008 at 10:16 pm
Comments posted to this topic are about the item All Data Readers Are Evil
April 28, 2008 at 10:49 pm
might as well just say "all clients are evil"
---------------------------------------
elsasoft.org
April 29, 2008 at 4:23 am
Steve,
Wow! Thanks for the highlight and I hope I am successful in bringing your October trip to Indy a reality. IndyTechFest was an awesome event last year and this year it looks like we have raised the bar even further.
I am often surprised about the treatment of sensitive data in databases as well as outside of databases (How many have seen SSN data copied/exported from a database to Excel). Recent Legislative efforts throughout the country have brought this subject (finally) to the forefront. The challenge to our profession is how to protect our client's data while not making our DBA's/Developer's life impossible.
This past weekend I presented on the subject of Dynamic SQL at a local code camp and while I did not have enough time in my session to explore SQL Injection as deeply as I would have liked, the demonstration that I provided (I inserted a truncate table statement) did appear to grab the attention of those in attendance. Let's not forget that SQL Injection can also be used to expose sensitive information.
April 29, 2008 at 5:55 am
I have to agree, not sure I like data readers are evil. I like to think I get the hazards that are out there, but businesses have to do business. Rather than such a general statement, I think we need to build some standard rules that we can give to developers, rather than appearing to fight them at every statement (and I realize this probably isn't what John does!).
- Dynamic SQL ONLY for user built searches, has to be validated for sql injection and called only via sp_executesql, and must be run under a read only account
- Stored procs or sp_executesql for all other data access
- Stop using one account/login/role fits all for data access. Separate roles can sharply reduce attack surface
- Return only the rows and columns you need, no select *
Thats a start anyway.
FYI, I'll be at the IndyTechFest. If I can travel all the way from Florida, sure Steve Jones can travel from Denver?
April 29, 2008 at 6:16 am
A lot of people in my family are in either military or law enforcement. So,some years ago it became my turn to learn how to use a firearm. I remember well the words of my instructor: "ALL guns are ALWAYS loaded". The only exception to this is when you have personally inspected the firearm and found it to be empty. Even then you're discouraged from pointing the gun at anything. The point of course is that when you're dealing with something dangerous, it's better to err on the side of safety.
If data is important enough to store, it's probably important enough to be stolen or attacked. Thinking of appropriate levels of security from the foundations of system design is a wise practice. Erring on the side of safety is better than otherwise.
Thanks for the good reminder.
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
April 29, 2008 at 9:00 am
I thought it was humourous that the editorial started with "all data readers are evil" to grousing about the increase in binary large data, whose extraction can cripple a database: "all writers are evil," so to speak. So, to DBAs, does that mean all customers are "evil," whether they are designers or clients? (insert standard rant about DBA vs. client warfare here).
-- Base Jumper
April 29, 2008 at 9:06 am
I don't know that I would say "evil", but dangerous would be a good term. I mean how can it be evil when the whole point of storing data is so that it can be accessed later?
I agree with the thought behind the motto, though. Be sure you know who is accessing your data and how. I also agree with Andy's idea of presenting standard rules for data access.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 29, 2008 at 9:14 am
Because of the ease of SQL injection, data corruption, user-error (whether that user is a dev or an end-user), et al, ad naseum, ad infinitum, I operate on the principle that all input must be validated, all data must be tested, all code must be proven, and all output should be validated as well.
Trust the honesty of your neighbors, but lock the door on your car. (To paraphrase)
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
April 29, 2008 at 11:12 am
The word "evil" is definitely a strong word and one that I am very careful to not over use.
Just to clarify the intent in which I was using it was not to represent the moral aptitude of the user themselves but the potential danger of disclosing data. The "evil" in this case is the potential harm, misfortune and injury to the customer and the client who houses the data if it is carelessly disclosed... intentional or otherwise.
The disclosure of a seemingly insignificant data (for example: birthdate) can be the missing puzzle piece for the Identity Thief to complete their twisted research and wield their wrath upon the unsuspecting customer.
April 29, 2008 at 11:26 am
Data reader is an important part of the data collection process. If data has no customer, it means that it should be removed from the storage. The lack of knowledge is evil. The lack of knowledge about own limits is twice evil. Like most of starting developers pretend to be a great hacker, every data reader pretends they know how to get data. SQL standard has made it possible. The problem is not in the data readers but in the way they are trying to get data. To those who don’t believe me – just open any data request query. I'll be surprised if DISTINCT or * wouldn't be there :-)))))
Alex Prusakov
April 29, 2008 at 8:08 pm
As a result, we need to be sure we work closely with them to get proper validation built into all applications.
Ok... I know I'll get a lot of flack from a lot of folks for this... but that's why I don't allow "embedded SQL" in any of the apps I oversee... properly wirtten stored procedures are also the first line of defense against SQL Injection.
So far as data access goes, if it has anything to do with customer or company data, I treat it just like when I was in the service... having high clearance is not enough... you must also have the need to know. Data readers should be written with that in mind.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply