Results 1 to 9 of 9

Thread: Validating Input [ PHP ]

  1. #1

    Validating Input [ PHP ]

    Ok I am writing a set of functions for validating form input and also cleaning input supplied by the user to a php script.

    The forms are validated client side first - but all validation is repeated server side as you should never rely on client side validation as it can be disabled or worked around.

    The actual validation itself is fairly simple and I have it figured....what I really have questions about is the text cleaning.

    Input is going to be used to query a mySQL database so one of the obvious things I want to protect against is SQL injection. Also some input might be stored in the database and then outputted to a HTML page at a later stage so I want to ensure that a person can not insert additional code (HTML / PHP / Javascript) along with their input.

    So far I have it :

    1. Checking if magic quotes is off if it is it adds slashes
    2. strip_tags
    3. htmlspecialchars

    is there anything else I should be doing to ensure no unwanted nasties get added into my DB? Anyone think of anything else?

    ta

    v_Ln

  2. #2
    Now, RFC Compliant! Noia's Avatar
    Join Date
    Jan 2002
    Posts
    1,210
    preg_match and preg_replace are the two functions you truly need. A good way of securing certain types of data is to just base64 encode it.
    With all the subtlety of an artillery barrage / Follow blindly, for the true path is sketchy at best. .:Bring OS X to x86!:.
    Og ingen kan minnast dei linne drag i dronningas andlet den fagre dag Då landet her kvilte i heilag fred og alle hadde kjærleik å elske med.

  3. #3
    Shrekkie Reloaded Raiden's Avatar
    Join Date
    Oct 2005
    Posts
    1,115
    Dunno if this can help you, but i thought its worth mentioning here ...
    Use escapeshellcmd() to avoid tricking shell commands if use with exec() or system().

    For input-validation I too use often preg_replace ...

  4. #4
    Kwiep
    Join Date
    Aug 2001
    Posts
    924
    I usually use this for example: $**** = preg_replace('/[^0-9a-zA-Z_]/',NULL,$_GET['****']);
    It filters all characters I didn't specificly allow. I can stop pretty much all script injections that way, but it depends if you wanne allow some special characters anyway. Using preg_replace to filter out a series of characters is tricky and I'd recommend finding another way to do that. I dunno if the example applies here but if you enter ".../...//" and you filter "../", what remains is "../". Also be for damn sure you use the quotes right in the sql queries.
    Double Dutch

  5. #5
    Senior Member Opus00's Avatar
    Join Date
    May 2005
    Posts
    143
    To plan for the unexpected is far more difficult than planning for what is expected.

    Example: about 7 years ago I wrote some IRC channel services, when you registered your channel one of the last things you did was included your email and I used the sendmail command to send you an email stating your registration was received.

    One person brought to my attention that he could make my server telnet to his server his server, because I was not doing input validation. Since sendmail would drop to the command line to do it's deed, he could add a space/tab or what ever after his email address, sendmail would do what it was suppose to then also continue to do what ever was placed after the email address.

    So it became a game, I'd fix my code to not allow what character he used to delimit the commands and he'd come up with another character. Therefore I spent more time recoding to disallow new characters for days. That is until I realized what was happening, why continue to try and figure out what may break it, rather than only allowing what was expect.

    What you do expect is a definite known, checking for what is known is more secure than checking for what you think some one may inject( the unknown)

    Of course, not knowing what your form is for, may make my statements unfounded, just sharing one of those life's experiences.
    There are two rules for success in life:
    Rule 1: Don't tell people everything you know.

  6. #6
    yeah I know where you are coming from Opus and in fields where I know it can only be alphabetic or numeric characters are easy to validate and clean. But some of the fields pretty much need to be free text so I cant strip out the characters I just need to ensure that the ways in which the characters are entered can not cause problems (such as making sure all quotes are escaped all html characters are replaced with < etc

    it is a fairly paranoid interface as it is - with multiple checks/balances in place for login and a heavy audit trail on all actions performed - and I dont see anyone setting out with the intent of breaching my security. But I want to avoid accidental mistakes and prepare for future tasks where the forms may not be in such a locked down enviroment.

  7. #7
    Junior Member
    Join Date
    Mar 2006
    Posts
    9
    Hi

    mysql_real_escape_string()

    This may or may not concern you but is good practice

    Cheers
    \"Those are my principles, and if you don\'t like them....well, I have others\"

    - Groucho Marx -

  8. #8
    Originally posted here by dan_in_au
    Hi

    mysql_real_escape_string()

    This may or may not concern you but is good practice

    Cheers
    This thread is 5 months 1 day old.

    Please do not reply to posts with flashing dates as the original poster should have found his solution by this time.

  9. #9
    This thread is 5 months 1 day old.

    Please do not reply to posts with flashing dates as the original poster should have found his solution by this time.
    Thank you for telling us YoungNobody... dumbass.

Posting Permissions

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