1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

SQL Injection scanner and protection

Discussion in 'Security' started by mrweb, Apr 16, 2015.

  1. #1
    Hello, my website has a SQL injection issue, I cannot find it.I'm replacing update ,select... etc from the URL request, but I have missed something . Is there a tool help me to find this security hole?

    Thank you
     
    mrweb, Apr 16, 2015 IP
  2. it career

    it career Notable Member

    Messages:
    3,562
    Likes Received:
    155
    Best Answers:
    0
    Trophy Points:
    270
    #2
    Better post some code snippets and what you changed so far.
     
    it career, Apr 16, 2015 IP
  3. mrweb

    mrweb Well-Known Member

    Messages:
    146
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    123
    #3
    string id = Request["id"].ToString().Replace("'", "").Replace("update", "").Replace("delete", "").Replace("insert", "").Replace("select", "");
    id = id.Replace("union", "").Replace(",", "").Replace("like", "").Replace("=", "").Replace("or", "").Replace("and", "");
    Code (markup):
     
    mrweb, Apr 16, 2015 IP
  4. billzo

    billzo Well-Known Member

    Messages:
    961
    Likes Received:
    278
    Best Answers:
    15
    Trophy Points:
    113
    #4
    Hi. A while back I read something about mysql_real_escape_string() (or the mysqli version) not protecting against certain types of code injection. So I tested it on my server and it turns out that it was correct, real_escape_string did not protect against it. The shared server I was on was using mod_security which recognized the attack and prevented it from the front-end (though I could still successfully run in on phpMyAdmin). Unfortunately, I lost my notes about that. So I do not remember exactly what it was.

    The gist of what I remember is that mysql or mysqli's real_escape_string is not sufficient protection and you should use parameterized queries to prevent SQL injection. And even then, in certain configurations of MySQL (such as PDO prepared statement emulation), that will not be enough to prevent SQL injection. As I said, I lost my notes. But I did a quick search and did find this that you should read and maybe use as a basis for further investigation:

    http://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string
     
    billzo, Apr 16, 2015 IP
  5. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #5
    Uhm, what? What in the world is that? ASP? Don't you have proper parameterized queries in ASP? There should be no need to do any of this, unless you have made the site so that the queries are generated on user-input (which is not very smart) or able to create specific queries based on what the user inputs (create the queries beforehand, and use parameterized inputs).
     
    PoPSiCLe, Apr 17, 2015 IP
  6. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #6
    If you're using PHP, and still using mysql_ as a database interpreter, then you're doing something VERY wrong. Use mysqli_ or PDO (whichever you prefer), and do, as @billzo said, utilize parameterized queries - NOTHING the user inputs should go into the database verbatim, without being run through input filtering of some sort. However, the OPs question pertains to ASP, if I read the other post he posted correctly, hence PHPs functions have no merit.
     
    PoPSiCLe, Apr 17, 2015 IP
  7. horllste

    horllste Greenhorn

    Messages:
    2
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    21
    #7
    input filtering cant protect you from sql injection
     
    horllste, Apr 18, 2015 IP
  8. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #8
    Uhm... what now? Unless you're either speaking something else than English, where "cant" means "will", I don't really think you know what you're talking about... what, exactly, EXCEPT input filtering will protect you from SQL-injection? (Yes, I know about parameterizing and using other methods). Of course you filter user inputs. Stupid, stupid comments...
     
    PoPSiCLe, Apr 18, 2015 IP
  9. horllste

    horllste Greenhorn

    Messages:
    2
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    21
    #9
    hmmmmm "Stupid, stupid comments..." if you think so......................

    With all the input filtering,
    Use of Prepared Statements (Parameterized Queries)
    Use of Stored Procedures
    Escaping all User Supplied Input
    Enforcing Least Privilege
    Perform White List Input Validation...............

    developers knew all these yet they get fu*ked all the time.
    no matter how u filter user input or use a WAF.
    believe it or not, there are still ways around.
    that's what am saying
     
    horllste, Apr 18, 2015 IP
  10. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #10
    Of course there are ways around - however, you've not provided ONE single example of a method that would succed - say to drop a complete table, or retrieve all content from one or more tables.
    Step one - input filtering - this takes care of (at least to some extent, depending on the level of filtering) malformed user-input
    Step two - prepared statements - this prevents quite a few further possible exploits, especially if something slipped by the filtering - not to mention it prevents multiple statements to run within one db-call
    Step three - stored procedures - hard to mess up with user-input - if done right
    Step four - escaping all input - why in the world...? If this is a necessary step in your security, you've done some of the above steps wrong.
    Step five - enforcing least privilege - of course - isn't that what most user-controls are for? Still, it won't prevent anything, since unforeseen errors or malformed limits can easily be exposed or elevated.
    Step six - this is actually a smart method, but it can be cumbersome for large, diverse amount of data. Typecasting might help some, and can be implemented fairly simple, but a dedicated white-list will demand maintenance and updating - not something I would work with (if you have dedicated personell to spare, sure, if not, don't bother)

    Devs SHOULD know all this (most don't), and yes, still we get fucked on a regular basis - that doesn't really mean the above steps shouldn't be used - it just means that the assholes out there are set to break through, there are more of them than it is of us, and in general nothing is safe, ever.

    But, yes, I would still like you to present some scenarios where all the steps above are implemented, and someone still got past the security - not to mention what they achieved by getting past security. If all they got was a few extra lines of info from the database (say 5 records in stead of 1), then it's a minor glitch. If they managed to drop or empty a table, that's a major glitch. If they were able to pull all db-content, that's a big ass poker up the butt - not something one wants to experience. And so forth and so on.
     
    PoPSiCLe, Apr 19, 2015 IP
  11. mrweb

    mrweb Well-Known Member

    Messages:
    146
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    123
    #11
    create the queries beforehand, and use parameterized inputs
    Code (markup):
    do you mean using stored procedure?
     
    mrweb, Apr 20, 2015 IP
  12. Wasi88

    Wasi88 Active Member

    Messages:
    56
    Likes Received:
    4
    Best Answers:
    2
    Trophy Points:
    55
    #12
    Mrweb: Instead of filtering some specific stuff out, you should allow the 'accepted' characters only. If "id" shouldn't have any other characters than numbers and letters (from a to z and A to Z), you should replace your 2 lines of code with something like this one:
    string id = Request["id"].ToString().Replace(/[^a-z0-9]/gi,"");
    Code (markup):
    If you need all the ASCII characters:
    string id = Request["id"].ToString().Replace(/[^\\x20-\\x7E]/gi,"");
    Code (markup):
    Then use a method that allows you to talk to the MySQL DB by parameterized queries and use the appropriate properties for your parameters. There is usually no need to escape/encode any user inputs as long as you use the parameterized queries properly. Encoding (like HTML encoding) should be used to prevent XSS and the like before you print data from the db into your html output. But even if you think you did it the right way: Always test your scripts (manually and/or by using tools/services).
     
    Wasi88, May 9, 2015 IP