Menu
Community /Pin to ProfileBookmark
@NogDogNov 17.2007 — #Where do those variables get set? Is it possible that your script is depending on register_globals being turned on, but that it is not on your new host? (The current "best practice" is to no longer have register_globals enabled due to the possibility of security holes in poorly written scripts.) @NogDogNov 17.2007 — #You could try turning on register_globals to see if that makes a difference. If it does, you could then consider editing the script so that it does not depend on it, basically by initializing all your variables from the form values via the $_POST array (assuming your form used the post method), e.g.:
Also for your consideration: do the form values get "sanitized" in any way before you use them in the mail() function? If not, then your form is wide open to hijacking by spammers.@NogDogNov 17.2007 — #The code setting each of the variables from the $_POST values would come first, then you would do the mail() command as you had in your original code (with the same variables as before). @NogDogNov 18.2007 — #Any values that will be used in the mail headers can be used to "hijack" your mailer if someone is allowed to post whatever values they want. As an example, the value used in the subject ends up being sent as part of the mail headers. A spammer could come up with a script to send a form submission to your page that has a value for the subject that includes the header element separator, then additional headers that he wants to use followed by a message body. Suddenly instead of sending email where you expect it to go, it is sending whatever message the spammer wants to send to wherever he wants it to go. In your original example, it looks like the only parameter you use in a potentially hijackable manner is the $Email, which is used for the "From:" header.
A simple way to avoid this sort of attack is to disallow newlines or carriage returns in any value you use in the mail command other than the actual message contents (the 3rd parameter to mail). So while you are validating each field (other than the message body), you could also validate that it does not contain those characters, e.g.:
Field names are displayed – Contents are not
I had been using a sendmail.php script for several years that worked fine. I have a guest book page on my site that contains seven fields including radio buttons, text boxes and drop down menu choices. When the user clicks the submit button, a redirect displays a confirmation page that uses the php code at the end of this message to send the contents to me.
I recently moved my web site to GoDaddy. When I first uploaded the guest book page and the php sendmail file, it worked fine. The next day it did not work correctly. It now only send me the field names and not the contents. Here is the php code from the confirmation page:
<?
mail(“
“Comment: $commentnNegative: $negativenOpinion: $opinionnSkillls: $skills nName: $name nE-mail Address: $email nSite: $site”, “From: $Email”);
?>
I would appreciate any assistance.
Sign in
to post a comment7 Comments(s) ↴
0
@NogDogNov 17.2007 — #0
@NogDogNov 17.2007 — #You could try turning on register_globals to see if that makes a difference. If it does, you could then consider editing the script so that it does not depend on it, basically by initializing all your variables from the form values via the $_POST array (assuming your form used the post method), e.g.:[code=php]
$comment = $_POST['comment'];
$opinion = $_POST['opinion'];
// etc.
//
[/code]Also for your consideration: do the form values get "sanitized" in any way before you use them in the mail() function? If not, then your form is wide open to hijacking by spammers.
0
@NogDogNov 17.2007 — #0
@NogDogNov 18.2007 — #Any values that will be used in the mail headers can be used to "hijack" your mailer if someone is allowed to post whatever values they want. As an example, the value used in the subject ends up being sent as part of the mail headers. A spammer could come up with a script to send a form submission to your page that has a value for the subject that includes the header element separator, then additional headers that he wants to use followed by a message body. Suddenly instead of sending email where you expect it to go, it is sending whatever message the spammer wants to send to wherever he wants it to go. In your original example, it looks like the only parameter you use in a potentially hijackable manner is the $Email, which is used for the "From:" header.A simple way to avoid this sort of attack is to disallow newlines or carriage returns in any value you use in the mail command other than the actual message contents (the 3rd parameter to mail). So while you are validating each field (other than the message body), you could also validate that it does not contain those characters, e.g.:
[code=php]
if(preg_match('[rn]', $_POST['Email']))
{
// not allowed, so display error and do not send mail
}
// do the same thing for any values used in the additional headers
[/code]