Is this an SQL injection attack? - Page 2
Page 2 of 2 FirstFirst 12
Results 16 to 24 of 24

Thread: Is this an SQL injection attack?

  1. #16
    Member
    Join Date
    Nov 2009
    Location
    Mid-Hudson Valley, NYS
    Posts
    54
    Quote Originally Posted by laserlight View Post
    * * *

    That is easy to do, . . .
    laserlight, thank you for your reply. Yes, I'd like to prevent both http and https from being entered in the database. You say it's 'easy' -- but how would I do it. (I've been googling like crazy but not coming up with anything.)

  2. #17
    PHP Witch laserlight's Avatar
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    13,560
    preg_match() or even just stristr() could be used to check the content before saving it into the database.
    Use Bazaar for your version control system
    Read the PHP Spellbook
    Learn How To Ask Questions The Smart Way

  3. #18
    Member
    Join Date
    Nov 2009
    Location
    Mid-Hudson Valley, NYS
    Posts
    54
    laserlight, great! Thank you so much for your help.

  4. #19
    Junior Member
    Join Date
    Apr 2013
    Posts
    6
    Laser light is right. regular expressions are a bit hard to get use to at first but can save you a lot of time in parsing content. I suggest that you use something along the lines of strip tags as well. Remember to brute your regular expressions with all types of encoding, slashes, and quotes. Every time that you are grabbing any user input you should try to make the decisions all on your side and not so much the clients side. An example of this would be a list of files with check boxes. You could have the script send the file name through the post request, or you could make an index system where the file names are only important to you. This can help ensure that the content that is going into your database is exactly what it is meant to be. If your site has a lot of traffic and has any type of money exchange you should be making sure to pen test your site with a variety for open source tools. A fairly well known sql injection tester by the name of sql map can help you out. Do remember though if sql map doesn't find anything that does not me you cannot be exploited. Look into running background scripts or packet monitoring. A great method I have picked up in the time i'v known php is to have a form builder function which checks all incoming instead of individuality checks on incoming var.

  5. #20
    PHP Witch laserlight's Avatar
    Join Date
    Apr 2003
    Location
    Singapore
    Posts
    13,560
    Quote Originally Posted by TylerDev
    I suggest that you use something along the lines of strip tags as well.
    No, I suggest that you don't attempt to strip tags, unless you are very sure that the format of the input is such that such characters that could lead to valid input looking like HTML tags are not allowed, otherwise you will end up corrupting valid input. Even then, it might be better to reject the input instead of modifying it.
    Use Bazaar for your version control system
    Read the PHP Spellbook
    Learn How To Ask Questions The Smart Way

  6. #21
    Pna lbh ernq guvf
    Join Date
    Jul 2004
    Location
    Kansas City area
    Posts
    19,414
    +1 with actually sanitizing and validating your inputs as appropriate rather than trying to find a blanket approach (because there isn't one; it's even worse than "jack of all trades, master of none" if you ask me). Simple example, say I come up with this rather secure password of " <mySuper$ecret>password", and say you fall victim of using some variant of garbage like:

    PHP Code:
    //prevent SQL injections and stuff and things
    $password trim(strip_tags($_POST['password'])); 
    Not only did you mangle user input, but you've now reduced my rather secure password to the word "password" for no apparent reason. (And I bet you didn't even admit to me in some sort of error/explanatory message, did you?!)

  7. #22
    Junior Member
    Join Date
    Nov 2011
    Posts
    18
    To avoid SQL injection attack you have to take one small step. You have to put White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack.*

  8. #23
    Settled 4 red convertible dalecosp's Avatar
    Join Date
    Jul 2002
    Location
    Accelerating Windows at 9.81 m/s....
    Posts
    7,697
    Quote Originally Posted by annaharris View Post
    To avoid SQL injection attack you have to take one small step. You have to put White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack.*
    I'm afraid that you're making this sound a tad oversimplified. A whitelisting approach works Just Fine(tm) in some situations, but you can't make the jump that to "if you will just whitelist you'll be fine ..."

    Not that you meant to say "if you just whitelist you'll be fine", but it kind of sounds that way in your post above.
    /!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade! /!!!\ ereg() is deprecated --- don't use it!

    dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket

    Getting Help at All --- Collected Solutions to Common Problems --- Debugging 101 --- Unanswered Posts --- OMBE: Office Machines, Business Equipment

  9. #24
    Senior Member
    Join Date
    Mar 2009
    Posts
    802
    Quote Originally Posted by bradgrafelman View Post
    +1 with actually sanitizing and validating your inputs as appropriate rather than trying to find a blanket approach (because there isn't one; it's even worse than "jack of all trades, master of none" if you ask me). Simple example, say I come up with this rather secure password of " <mySuper$ecret>password", and say you fall victim of using some variant of garbage like:

    PHP Code:
    //prevent SQL injections and stuff and things
    $password trim(strip_tags($_POST['password'])); 
    Not only did you mangle user input, but you've now reduced my rather secure password to the word "password" for no apparent reason. (And I bet you didn't even admit to me in some sort of error/explanatory message, did you?!)
    This actually happened to me at a critical moment at work. Story time!

    We were dealing with this website that was constantly being hacked (garbage text was being injected into their site for Googlebots to find). Our client was becoming increasingly aggravated with us since we were unable to find the source (even though we encouraged them to upgrade their years-old Joomla! installation and they refused - basically they were blaming us). Eventually we took the "scorched Earth" approach and deleted everything on their FTP and reuploaded the files. We also changed all their passwords, including their control panel password. We have a password scheme but I made the call that it wasn't sufficient in this case and used KeePass' password generator to generate 40 character passwords of random letters, numbers, and symbols. The passwords are stored securely so no one has to remember them or even type them in.

    I changed the control panel password without issue (a success message was posted after I changed it). After I recorded the password I went to log back in and my attempt failed. Tried again. Tried the old password, still couldn't get in. By this time I'm sure the hosting company had locked the account. The "critical moment" was that we were supposed to be done in about 15 minutes (the client's deadline), or the client was going to drop us. We tried contacting the hosting company but they couldn't do anything for us except send out a password retrieval email to whoever was on the account - which included the client contact we were dealing with directly (the one who gave us the deadline). So my boss had to call him and twist facts to try to keep the heat off us while getting him to forward us the password retrieval email.

    I got the email and the password looked the same but was able to log in with it. I was perplexed, but on a tight timeline so I finished up my work and the crisis with the client was averted (kind of - payment is still pending). I went back and looked at the password that was in the email and noticed it was 1 character short - only 39 characters. Lining them up in Notepad I noticed the password that was in the email had a backslash stripped from it (forward slashes were okay). I relayed this info to my boss because I wanted to make sure he knew I didn't mess up. I couldn't believe it, though. This was a major hosting company (not GoDaddy) that we had used and still do use quite a bit. I sent a strongly worded email to them explaining the poor practice this was and the situation it had put us in. Never heard from them.

    TL;DR: Popular hosting company stripped backslashes from their control panel password without notice and I couldn't get back in while in the middle of fixing our biggest client's website who was threatening to drop us.

    So yeah. Absolutely do not do this. There is no reason to strip characters or otherwise change user-supplied passwords.
    Declare variables, not war.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •