Consequences of not using server side validation?_问答_开发者

What are the consequences of not validating a simple email form on the server.

Keep in mind that:

javascript validation is being carried out
there is no database in question, this is a simple email form

The PHP code I would like to use is this:

<?php
    $post_data = filter_input_array( INPUT_POST, FILTER_SANITIZE_SPECIAL_CHARS );

    $full_name = $post_data["full_name"];
    $email_address = $post_data["email_address"];
    $gender = $post_data["gender"];
    $message = $post_data["message"];

    $formcontent = "Full Name: $full_name \nEmail Address: $email_address \nGender: $gender \nMessage: $message \n";
    $formcontent = wordwrap($formcontent, 70, "\n", true);

    $recipient = "myemail@address.com"; $subject = "Contact Form"; $mailheader = "From: $email_address \r\n";

    mail($recipient, $subject, $formcontent, $mailheader);

    echo 'Thank You! - <a href="#"> Return Home</a>'; 
?>

Would a simple captcha solve the issue of security?

UPDATE:

A few questions I would really like answered: If I am not worried about invalid data being sent, what is the absolute minimum I can do to improve security. Basically 开发者_JAVA百科avoid disasters.

I should probably mention that this code is being generated in a form generator and I would like to avoid my users getting attacked. Spamming might be sorted by adding Captcha.

UPDATE: What is the worst case scenario?

UPDATE: Really appreciate all the answers!

A couple of things I plan to do:

add this as Alex mentioned: filter_var("$post_data['email_address']", FILTER_VALIDATE_EMAIL);
add simple captcha

If I did add simple server side validation, what should I validate for? Cant the user still send invalid data even if I am validating it?

Also, will the above stop spam?

No validation occurs when there is no javascript present, might as well not have it...

Do you think spam bots have javascript enabled?

Extra note on would be attackers

If I were attacking your form, I would first see your javascript validation.. Next I would turn javascript off and try again...

The Consequences of only using client side validation are the same as not using validation at all...

Would a simple captcha solve the issue of security?

Not unless it's server side...

In general if you are just playing around and don't care, you don't need validation at all. Having client-side validation is pointless and you will just be wasting your time. The client-side only approach will get you in trouble. You can't trust your users that much.

If you plan to actually release this or really use it on a live environment, you must have a server side validation. It is well worth the time since this is a simple form now, but it may grow to be much more than that. In addition, if you take care of your validation now, you can reuse it later with other components of your application/site. If you try thinking if terms of reusability you will save your self countless of hours of development.

There are also obvious issues such as injections and javaScript issues, as mentioned by other users. In addition, a simple CAPTCHA does not cut it anymore. There are some nice resource regarding CAPTCHA.

Take a look at those.

Coding Horror

Decapther

So the simple answer of your questions is that you are certainly vulnerable in your current situation. I know that more development takes more time, but if you follow good development practices such as reusability and orthogonal/modular design you can save yourself a lot of time and still produce robust applications.

Good luck!

UPDATE: You can add FILTER_VALIDATE_EMAIL to take care of the email validation and you can read more about the email injection and how to take care of it here: damonkohler. As for the CAPTCHA, it could solve the problem, but it really depends on how valuable of a target your form/site is. I would recommend using non-linear transforms or something that is widely used and proven. If you are writing your own you may get yourself in trouble.

Summary:

Validate Email
Still make sure you are save from injections
Make sure the CAPTCHA is strong enough
Really Consider server-side validation

UPDATE: @kht Did you get your questions answered? Let us know if something was unclear. Good Luck!

UPDATE: OK, I think we have made you a bit confused here with this whole client-side/server-side fiasco. I will try to break it down now so it makes more sense. The first part explains some basic concepts, and the second answers your questions.

First, PHP is a server-side language. It runs on the server and when a page request is sent, the server will "run" the PHP script, make any changes to the requested page, and then send it to the user who is requesting the page. The user has no access/control over that PHP script. On the contrary, as discussed earlier, the client-side scripts, such as JavaScript can be manipulated. However, just because you have some PHP script running and checking something on a form, that does not mean that the form is secure. It only means that you are doing some server-side processing of the form. Having it there, and making it secure are two different things as I am sure you have already figured out.

Now when we say that you need server-side validation we mean that you need a good one. Also, in this hectic Q&A format nobody really mentioned that there is a difference between validating data and sanitizing data.

sanitizing - making the data meet some criteria

validating - checking if the data meets a criteria

Take a look at phpnightly for a better explanation and examples. There are also some nice simple tutorials describing how to create basic validation of a form.

nettuts

Very basic, but you should get the idea.

So how do you approach your current problem?

To begin with, you should keep what you have in terms or client-side validation and add the CAPTCHA as you mentioned(check my post or you can research some good ones).
What should you validate?

a. you should validate the data: all fields such as email, name, subject...
- check if the data matches what you expected: is the filed empty?; is it an email?; does it contain numbers?; etc. You can validate the data on the server side for the same things you are validating it on the user side. The only difference is that the client cannot manipulate that validation.
b. you could sanitize the data as well
- make it lower case and compare it, trim it, or even cast it into a type if you need to. If you have time to check it out, the article from phpnighty has a decent explanation of the two and when not to use both.
Can the users still send invalid data?
- sure they can, but now they have no access to the validation algorithm, they can't just disable it or go around it.(strictly speaking)
- when the data is invalid or malicious, just inform the user that there has been an error and make them do it again. That is the point of the server-side validation, you can prevent the user from circumventing the rules, and you can alert them that their input is not valid
- be very careful with the error messages too; don't reveal too much of the rules you are using for validation to your user, just inform them what you are expecting
Also, will the above stop spam? If you make sure the form is not vulnerable to email injections, you have client-side validation, CAPTCHA, and server-side validation of some form(it does not have to be super complex) it will stop spam.(keep in my that today's great solution is not so great tomorrow)
Why the hell do I need that server-side bull* when my client-side validation works just fine?* Think of it as having a safety net. If a spammer goes around the client-side security, the server-side security will still be there.

This validation thing sounds like a lot of work, but it is actually pretty simple. Take a look at the tutorial I included and I am sure the code will make things click. If you make sure no unwanted information is being sent through the form, and the clients cannot manipulate the form to send to more than one email, then you are pretty much safe.

I just wrote this one out the top of my head, so if it is confusing just put some more questions or shoot me a message. Good Luck!

Without validation they could use injection to add in values such as CC: and BCC: to send emails to multiple other people via your form. So I would recommend the least you do is add in:

filter_var("$post_data['email_address']", FILTER_VALIDATE_EMAIL);

If you check the email is valid, the worst they could do is send you invalid data.

JS validation is excellent, as long as the browser supports JS. Unfortunately there are still browsers that lack on JS support.

But, when you do not perform serverside validation, you expose your mail() to injectors. I can create my own nastyFile.html within which I place a formular wich action="http://yousite.com/yourEmailHandler.php" and by doing that I might am able to omit your JS validation

Anyone can spoof their HTTP GET/POST requests:

netcat is enough to build a simple GET request
simple python/perl scripts are enough to craft modified POST submissions
Firefox (and likely many others) have plugins that do just that from the browser (e.g. TamperData)
javascript can be readily enabled/disabled/altered aat will using convenient plugins like
- IE developer toolbar
- Chrome dev toolbar
- FireBug
- Opera DragonFly

It's just making things too easy. There could be all kinds of motives. You risk getting tampered (inconsistent/unclean) data in your database. You risk getting DoS-ed (e.g. by receiving crafted responses that bring down the server, or just hold a request handler (thread) for a long time resulting connection timeouts)

This is scratching the surface only, because once your site isn't secure, there is no telling what that can be leveraged for.

By using filter_input_array(), you are doing some server-side validation (or sanitization, which amounts to the same thing in this case). Also, by hardcoding the recipient e-mail address, you've plugged the worst and most common hole in typical e-mail forms. Whether by luck or by design, it looks like those might actually be enough in this case.

In general, vulnerabilities in e-mail forms can be divided into two broad categories:

tricking the script into doing something other than sending e-mail, or
tricking it into sending e-mail to the wrong address (spam).

In your case, all you're doing with the user-provided data (as far as the code you've showed us goes, anyway) is passing it to mail(), which is hopefully free of major security holes. (But then again, this is PHP, so...) As for tricking your script into spamming the wrong recipient, there are (again) basically two ways to do that:

if the client can supply the recipient address, a spammer can just pass in whatever they want;
otherwise, they can use e-mail header injection to insert bogus recipients (and other content), generally by injecting line breaks into the data.

Fortunately, you've hardcoded your e-mail address into the script, and the sanitization method you've chosen (FILTER_SANITIZE_SPECIAL_CHARS) replaces line breaks with HTML character entities. So it looks like you might be safe from both of these attacks. Of course, someone could still use the form to send (more or less) arbitrary e-mails to you, but presumably that's a risk you're willing to take.

All that said, though....

I'm hardly infallible, and there might be potential security issues that I've missed in my analysis above. In general, the stricter you are in checking your input, the less likely you are to be vulnerable to unexpected attacks. For example, I'd very much second the suggestion given by others here to apply an extra validation step to the user-supplied e-mail address (and, more generally, to any data that might end up in the e-mail headers).

One consequence may be if the browsers javascript is off or some expert user using firebug or some other tools change the behavior of the javascript validation than you may get a useless information

Javascript might be disabled
A person could put anything in the mail header in your code.

That is a security risk

EDIT: $post_data contains the items from the form - $email_address being one that makes up the $mail_header. You can use that to inject stuff into the mail header.