Post reply

SQL Injection

  • February 3, 2009 at 1:05 pm

    #937481

    NotManyPoints (2/3/2009)

    GilaMonster (2/3/2009)

    NotManyPoints (2/3/2009)

    More that they have an awareness and be somewhat ‘up to speed’ as it were in their chosen profession.

    Would that go for every aspect of the database field? If so do you have an awareness and are somewhat 'up to speed' on all areas?

    Not had to post a silly (find answer on internet, in 1 second) question yet, but still time I guess.

    The key word in my statement was 'awareness', I'm not expecting they get down and dirty with code. But have an awareness of what is in this case something quite important across most aspects of working with a database, development or administration (and all the shades of grey between).

    Roy Ernest (2/3/2009)

    The problem is that DBA’s are generalized and they all fall under one category.

    What are the categories?

    DBA to turn the server on.

    DBA to make sure the light stays on.

    DBA to shout if the light goes off.

    DBA to turn it on again when the first 'DBA' said they did it last time and would be against regulation to turn it on more than twice a week for fear of RSI.

    'DBA.bak' incase any other DBA is on a tea break.

    Then you need a DBA to oversee all the other DBA's. Then you have a DBA's Union. Then they go on strike.

    May have gone a bit far with this…..

    Note to self: must work on "how many DBA's does it take to....” jokes.

    So, it begs the question, are you aware of every aspect of SQL Server yourself?

  • February 3, 2009 at 1:06 pm

    #937485

    ex__inferis (2/3/2009)

    Hmm, I guess my comment didn't come across the way I hoped. It made so much more sense in my head. Lets leave it at "you're right, I'm wrong and I humbly apologise". Okay?

    No worries. That's a standard reply when someone says that we're doing a terrible job here.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • February 3, 2009 at 1:18 pm

    #937496

    GilaMonster (2/3/2009)

    ex__inferis (2/3/2009)

    Hmm, I guess my comment didn't come across the way I hoped. It made so much more sense in my head. Lets leave it at "you're right, I'm wrong and I humbly apologise". Okay?

    No worries. That's a standard reply when someone says that we're doing a terrible job here.

    Said with the voice of the bad Karate Teacher from Karate Kid....

    "There is no mercy in this dojo do we understand Mr. Lawrence? Mercy if for the weak" 😛

    Sorry, I graduated high school in the 80's and these things stick.

    David

    @SQLTentmaker

    “He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot

  • February 3, 2009 at 1:23 pm

    #937504

    Lynn Pettis (2/3/2009)

    So, it begs the question, are you aware of every aspect of SQL Server yourself?

    No of course not: that would remove the need for this website, and the much enjoyed time I spend finding those useful nuggets of information. A look at my far from respectable question of the day score would confirm I don’t. There is normally some idea of where to go with something even if its were is the best resource for information if I don't know the exact details of something.

    But:

    Not had to post a silly (find answer on internet, in 1 second) question yet, but still time I guess.

    Also don’t get me wrong I quite often have to blag my way through some technical encounter. But I do some basic research, before just throwing my hands in the air and posting a question to the world.

  • February 3, 2009 at 1:28 pm

    #937514

    True...You can find quite a bit of details by doing some research. Maybe the person who posts question did not understand what was written in some of the articles or searches he/she read. So he comes to some place where some one can help him or her understand.

    -Roy

  • February 3, 2009 at 1:35 pm

    #937527

    NotManyPoints (2/3/2009)

    Lynn Pettis (2/3/2009)

    So, it begs the question, are you aware of every aspect of SQL Server yourself?

    No of course not: that would remove the need for this website, and the much enjoyed time I spend finding those useful nuggets of information. A look at my far from respectable question of the day score would confirm I don’t. There is normally some idea of where to go with something even if its were is the best resource for information if I don't know the exact details of something.

    But:

    Not had to post a silly (find answer on internet, in 1 second) question yet, but still time I guess.

    Also don’t get me wrong I quite often have to blag my way through some technical encounter. But I do some basic research, before just throwing my hands in the air and posting a question to the world.

    Therefore, it is possible that a DBA may have no idea what SQL Injection actually is. This leads back to my very first post in this thread. A stern warning against it (paraphrased).

  • February 3, 2009 at 2:35 pm

    #937577

    If a DBA has:

    a) no idea about the particular topic of SQL injection (particularly this topic, as its so widely written about -which is not the same as acted upon before anyone comments on)

    b) no idea where to find information (not just post run).

    c) been using this website for more than a few weeks (which has covered the topic in many ways) and still has no idea.

    I pity the company they work for or the clients they have. Do they just come to this site and their job with their DBA (specifically categorised role) blinkers fully welded into place. Until the shift whistle blows and they sigh relief that they weren't called upon to (back something up, or no, not that 🙁 .... learn something new..) :sick:

    Oh look I can see the cleaners arriving. Hence forth I shall call them DBA's as they sometimes have to poke that box in the server room with a duster, they do play their part in keeping things running. 😀 (Not completely true.. as its not a live box).

  • February 3, 2009 at 2:35 pm

    #937578

    Trying to work though the icons 😉

  • February 3, 2009 at 2:38 pm

    #937580

    NotManyPoints (2/3/2009)

    If a DBA has:

    a) no idea about the particular topic of SQL injection (particularly this topic, as its so widely written about -which is not the same as acted upon before anyone comments on)

    b) no idea where to find information (not just post run).

    c) been using this website for more than a few weeks (which has covered the topic in many ways) and still has no idea.

    I pity the company they work for or the clients they have. Do they just come to this site and their job with their DBA (specifically categorised role) blinkers fully welded into place. Until the shift whistle blows and they sigh relief that they weren't called upon to (back something up, or no, not that 🙁 .... learn something new..) :sick:

    Oh look I can see the cleaners arriving. Hence forth I shall call them DBA's as they sometimes have to poke that box in the server room with a duster, they do play their part in keeping things running. 😀 (Not completely true.. as its not a live box).

    So, we are back to having to know something about all aspects of SQL Server again....

    I'm sorry but you can't have your cake and eat it too...

  • February 3, 2009 at 3:16 pm

    #937606

    NotManyPoints (2/3/2009)

    Trying to work though the icons 😉

    By the way, Are you a dba?


    * Noel

  • February 3, 2009 at 7:59 pm

    #937684

    I'm willing to cut the 'dba' some slack because frankly if there's one thing I've learned over time is that with there being SO much to learn we tend to focus on the things neeed to do our jobs right now. NOW if someone were working entirely on internal db's accessed completely by internal apps, and for that matter deep into aspects of the db architecture and other things where security of the server, and hardening of the system vs attacks were not concerns for their job, I can see how they might not know about SQL Injection or many other types of security vulnerabilities.

    but I'm also not going to throw stones because I'm NOT a DBA.. I'm a tester who often interacts with databases and finds it very useful to have 'decent' SQL skills. DBA's probably lump me into the 'knows enough to be dangerous' group.

    OTOH Security testing is part of my job, and a bit of a passion for me, so I DO know about SQL Injection, as should anyone who's testing any kind fo web based application that interfaces with SQL.

    For those who want more info BTW on how to TEST a system for vunerabilites to things like SQL injection I recommend my wife's book

    and yes while using parameterized stored procs is a good defense, I'm a strong believer in defense in depth.. so under the principle of 'all trust is misplaced' you should be passing all user input past 'whitelists' of allowed characters for the particular fields.. e.g. no reason for a zipcode to have a ' in it is there? or phone numbers to have semicolons etc.

    all input should be treated as evil until proven otherwise.

  • February 3, 2009 at 8:16 pm

    #937688

    Lynn Pettis (2/3/2009)

    So, we are back to having to know something about all aspects of SQL Server again....

    I'm sorry but you can't have your cake and eat it too...

    Exactly. I don't see any issue with someone not knowing about this topic any more than I would expect most people to be able to talk to me intelligibly about how SQLCLR actually works in SQL Server, why only part of the BCL is available in SQL Server, and then discuss the details of memory utilization and management inside CLR and where it allocates in the SQLOS.

    Ok...a quick pause so that everyone reading this post can go try to google what I just wrote and figure out if I am spouting real information or BS...........

    I only know a small group of people outside of Microsoft who can talk intelligently about any of the above topics, and that is because to date it really doesn't fit into a lot of DBA's or Developers for that matter job descriptions or relevant work. It doesn't fit into either of mine, but as a forum junky, I spent the better part of last year learning more about SQL Server CLR and memory internals than I ever cared to learn or really want to know now, simply because the SQLCLR forums online were some of the most unanswered areas in SQL Server.

    A year later, I can answer most questions on SQLCLR implemenations that get asked online these days, even though, I don't have a single piece of SQLCLR in any of my production SQL Servers.

    Unless you can tell me one thing about the list that I made above, you are no different than the person who asked the question about SQL Injection. You are missing a very important piece of knowledge about SQL Server, and you can't offer complete solutions to your company because you don't know about all that SQL Server can offer. Think you will get the above information in a little bit of web searching? Good luck, though you might start with my first and last name, followed by SQLCLR, I have explained alot of the above in forums posts both here and on MSDN, and in a few newsgroups threads as well. (At least you have an advantage, I gave you how to find the information.)

    I don't have to be a pro at all things SQL. That is why I participate in the community. I know that if I need help with Replication, I can contact specific people from the communities and ask them to look at a post that I have made, even if it is 100 level, sometimes even I just need a quick answer because I am in a jam, or maybe I'll post the stupid question, while I am searching because someone will offer a answer that will help tailor my searches towards better information.

    Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
    My Blog | Twitter | MVP Profile
    Training | Consulting | Become a SQLskills Insider
    Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]

  • February 4, 2009 at 1:12 am

    #937744

    Examples of SQL Injection

    http://cwe.mitre.org/data/definitions/89.html

  • February 4, 2009 at 5:19 am

    #937836

    SQL Injection is the number one exploit used by the hackers to Steal Information and Deface Website.

    Using SQL Injection attackers can:

    Change or delete Website Content.

    Steal user information such as email addresses, username & password , credit card details.

    Access Database connected to website

    Attackers commonly insert single quotes into a URL’s query string, or into forms input field to test for SQL Injection.

    SQL Injection is a technique that exploit a security vulnerability occurring in the database layer of application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in the SQL

    When user enter the following url:

    http://www.mydomain.com/products/products.asp?productid=123

    The corresponding SQL query executed.

    SELECT ProductName, ProductDescription FROM Products WHERE ProductNumber = 123

  • February 4, 2009 at 9:20 am

    #938089

    Another thing related to SQL injection is the display of SQL information in errors seen by the end user.

    it's ok to enable stuff like that on your test environments, and perhaps even for users on the local network. Very useful for debugging problems and getting to the bottom of bugs.

    But make sure it's NOT going out to regular users of your production site. That kind of info gives FAR too much information away in terms of your database, and if a system for some reason (such as a code change by an inexperienced developer) becomes vulnerable then a malicious user can literally explore the entire db, discovering names of tables and columns, and then use that info to craft a specific attack, ALL from what's given out when the SQL error shows up in the website error message. Without that info there might still be a vulnerablilty, but the attacker is 'flying blind' and will have a harder time doing serious damage unless they can make some lucky guesses as to the names of things.

    It doesn't prevent a vulnerability, but it can mitigate how much damage is done before you've detected the problem and fixed it.

    Likewise it's a good idea unless they are absolutely necessary to do things like disable the command shell stored proc, which would let someone execute commands at the 'dos/os' level if they are able to accomplish injection against your db

Viewing 15 posts - 31 through 45 (of 121 total)

You must be logged in to reply to this topic. Login to reply