PHP Form Security
Results 1 to 10 of 10

Thread: PHP Form Security

  1. #1
    Junior Member
    Join Date
    Feb 2006

    Question PHP Form Security

    Hello all,

    I have a simple question concerning the security of my form.

    I have a very basic PHP script that interacts with a series of checkboxes.

    This form only consists of:

    1. several checkboxes

    2. textarea field to output echoed data, which does not process any inputed data

    When a checkbox is selected it echoes back some text to the textarea field when the form is processed.

    As I said before this script is very basic.

    So - my questions are as follows:

    a. Given that it doesn't interact with any databases or display/save anything viewable by the public, does this form still need to be secured/validated?

    b. If so, any ideas on how i can secure it?

    An article that i was reading said:

    Regardless of its mode of execution, the PHP interpreter has the potential to access virtually every part of the host -- the file system, network interfaces, IPC, etc.
    Does this apply to ALL PHP scripts? Or only scripts that interact with a database?


  2. #2
    Developer Extraordinar
    Join Date
    Jul 2002
    Well, it depends on a number of things. First of all, if Apache, or the Apache vhost is in a jail, the attacker would have to break out of the jail in order to do any damage to the rest of the filesystem (although your document root would be at risk)

    As for actually making it more secure, regexp (Regular Expressions) are your friend. Check the forum input, and make sure it's what you want.

    Also, register_globals should be off, unless you absolutly need them.

    Come to

  3. #3
    Senior Member Syini666's Avatar
    Join Date
    Aug 2001
    Also add in a check on the referer so that someone doesnt try to mangle the form and pass the new information to the script, which can be a fun way to make things go all sideways. Better to be safe than sorry in terms of security...
    You're not your post count, You're not your avatar or sig, You're not how fast your internet connection is, You are not your processor, hard drive, or graphics card. You're the all-singing, all-dancing crap of AO
    09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

  4. #4
    Yes of course it has to be validated! A simple attack is to save the page with the form on the computer then alter the characteristics of the textarea box to allow about million or billion characters then to actually put those characters in and press send. Coldfusion is particularly susceptible to this attack. ALWAYS, ALWAYS,ALWAYS validate input!

  5. #5
    Elite Hacker
    Join Date
    Mar 2003
    They can still change the referrer anyway. Better to just focus on the stuff that they can try on you no matter where the form is submitted from.

  6. #6
    Junior Member
    Join Date
    Feb 2006
    Thank you all for your help...


    Would you mind showing me an example of how I can implement regex? I'm confused as to how I would use regex to validate the checkboxes. Maybe I'm missing something.

    I checked using phpinfo(), and register_globals is ON. I'm on a shared hosting account, how can I convince my administrator to turn register_globals off?

    I also noticed that allow_url_fopen & magic_quotes_gpc are on as well...


    I would love to use HTTP_REFERRER, but as h3r3tic pointed out, that info can be easily spoofed anyways. Plus I know that some browsers and security software strip the referrer info - which would prevent some innocent users from using my form...


    The textarea box doesn't receive input. It's just used as a container to hold echoed data from the script. Should it still be validated?

    h3r3tic> Exactly my thoughts as well.

    I have an array that checks each checkbox value to make sure that the value has not been modified. Would this properly secure everything?

    I can post my script, if you guys want me to.

    Thanks again.

  7. #7
    Elite Hacker
    Join Date
    Mar 2003
    Basically you want to make sure the data is what you want it to be, which sounds like what you're doing. The only time this is bad is if what you want the data to be can actually contain input that is harmful. So make sure what you are checking to make sure their input matches won't do any harm. I wouldn't worry about register_globals. Just because it's on doesn't mean you have to use it. They could break some peoples' sites if they turn it off, and register_globals being on is fine if you don't do something stupid.

  8. #8
    Hi Time_Stopper,

    Any script which processes input from something else, whether that's data submitted through a webpage, or data pulled from a database. In either case, you can't trust user input.

    Attacks aren't just about compromising the server, either. One of the things we have to occasionally clean off here is where someone tries to embed <iframe> tags in a post (so that a post basically consists of their web page). At best, that can easily break the page formatting. At worst, it's a nice delivery vector for web browser exploits, which people would then blame us for. That sort of thing is why my <iframe> is being explicitly rendered as <iframe> rather than just being blindly put into the page.

    The basic question to ask is how your page behaves when people feed it bad data. And the fundamental thing to realise is that bad data does not have to follow the constraints on your web page. They can potentially send you more or less checkboxes than the ones you have on your form, with different names. They can send you text fields which have the names of your checkboxes. They can send more text than the textarea field allows. They can change the value of hidden fields.

    For every input your script receives, you need to know in advance (at design time) what input is valid. Then you need to check that the all the input you get is valid before processing it. Don't do it the other way around (look for and reject invalid input); if you miss something that way then you have a potential security problem. If you miss something when checking for valid input then you just have an annoying bug.

    All that said, your page is fairly low-risk -- no system calls to be hijacked, and no deliberate replaying of one user's input to other users (eg a forum / shoutbox / etc). You should still do it properly though, if only to get into the habit with the simple stuff before it really counts. Plus you never know when someone is going to put a button on their web site which sends data to your form.

  9. #9
    Well, I'm not to sure if PHP is client or server side. If the processing was server side then even for a simple cho box, validate input. If its client side, like javascript, then no worries.
    here I'll walk you through a garbled form attack.

    Let's go to this example won't work but you'll get what i mean). Go to file-->save page as. Then save the page. Then open up the page via a text editor and find the part where it says: <input maxlength="2048"... and change the 2048 to 10000000. Then save the page and open it up via IE/FF. Then put in as many letters as you can. Thats all someone has to do to manipulate a page. Anything processed server side MUST be validated before being used. Validation means checking the type of the input, the size of the data, etc, before using it.

    *This example will not actually connect to google's servers so its safe to do. And even if you could submit that many letters to them, they'd simply throw an erro. Trust me, i;ve tried

  10. #10
    Junior Member
    Join Date
    Feb 2006
    Thank you all for your help.

    As I mentioned earlier, I created an array that consists of acceptable values. It checks each checkbox value to make sure that nothing has been modified.

    With my other form that recevies user input, I created another array combined with strtr() that strips unacceptable characters from the user's input, such as ! ? < > # ...etc.

    As for guarding against bots, I was thinking of using CAPTCHA image verification...


Posting Permissions

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

 Security News


       Security Trends


           Buying Guides