Jump to content
xisto Community
cybertron

Php Code Getting \ When Typing ' Or " How to use the Stripslashes Command

Recommended Posts

Hello,

I'm very new to PHP but I find it very interesting. My form works just fine, but when I receive an email from a client there are / characters in front of apostrophes.

Example:

When a user types: I'm interested in a new design idea for one of our client's.

It comes to my email with this: I/m interested in a new design idea for one of our client/s.

Does anyone know where I would put in the Stripslashes command so I can see apostrophes instead of slashes?


Here is my php code:

<?php $to = $_REQUEST['sendto']; $from = $_REQUEST['Email']; $name = $_REQUEST['Name']; $headers = "From: $from"; $subject = "Web Contact Data"; $fields = array(); $fields{"Name"} = "Name"; $fields{"Company"} = "Company"; $fields{"Email"} = "Email"; $fields{"Phone"} = "Phone"; $fields{"Message"} = "Message"; $body = "We have received the following information:\n\n"; foreach($fields as $a => $b){ $body .= sprintf("%20s: %s\n",$b,$_REQUEST[$a]); } $headers2 = "From: [url="http://forums.xisto.com/no_longer_exists/;'>http://forums.xisto.com/no_longer_exists/;;'>http://forums.xisto.com/no_longer_exists/;'>http://forums.xisto.com/no_longer_exists/;; $subject2 = "Thank you for contacting us"; $autoreply = "Thank you for contacting us. Somebody will get back to you as soon as possible. If you have any more questions, please consult our website at [url="http://forums.xisto.com/no_longer_exists/&'>http://forums.xisto.com/no_longer_exists/& == '') {print "You have not entered an email, please go back and try again";} else { if($name == '') {print "You have not entered a name, please go back and try again";} else { $send = mail($to, $subject, $body, $headers); $send2 = mail($from, $subject2, $autoreply, $headers2); if($send) {header( "Location: [url="http://forums.xisto.com/no_longer_exists/;'>http://forums.xisto.com/no_longer_exists/; );} else {print "We encountered an error sending your mail, please notify [email=webmaster@YourCompany.com]webmaster@YourCompany.com[/email]"; } }}?>
Many Thanks!

Notice from rvalkass:

Code tags added around the PHP code.

Share this post


Link to post
Share on other sites

Does anyone know where I would put in the Stripslashes command so I can see apostrophes instead of slashes?

It would go here:
$name = $_REQUEST['Name'];
and here (which is not found anywhere explicitly in your code; that is, only found in the foreach loop):
$_REQUEST['Message'];
Also, this part contains a security flaw:
$from = $_REQUEST['Email']; $headers = "From: $from";
You aren't filtering the _REQUEST['Email'] variable. This allows for header injection, which would allow anyone to use your script to spam random people.
Also, i've never seen curly brackets for accessing arrays before:
$fields{"Name"} = "Name"; $fields{"Company"} = "Company"; $fields{"Email"} = "Email"; $fields{"Phone"} = "Phone"; $fields{"Message"} = "Message";
This doesn't give you a syntax error?

Share this post


Link to post
Share on other sites

No, when people contact me it comes through fine. I pretty much just watched a tutorial on youtube for setting up a php form for email. Should I remove those curly brackes and place some other character to close those arrays?In regards to that security flaw you're talking about. How do I enhance that code so clients will not get spammed? I definitely don't want crackers or hackers spaming clients.One more thing truefusion, do I put the Stripslashes command before the $name = $_REQUEST['Name'];?Could you give me an example of how the Stripslash command would be written with this code?$name = $_REQUEST['Name'];?Thanks again for warning me about the security flaw. I'm in Information Security at school right now but php is alien to me. Man, I sure do appreciate the help though!Regards.

Share this post


Link to post
Share on other sites

Should I remove those curly brackes and place some other character to close those arrays?

I guess if it works, then it's okay. I've just never seen that syntax in PHP before.

In regards to that security flaw you're talking about. How do I enhance that code so clients will not get spammed? I definitely don't want crackers or hackers spaming clients.

Header injection normally deals with the hacker or user inserting new lines in areas where they are not supposed to. Basically you are supposed to look out for the following characters: %0A, %0D, \n, and \r. If you find these, you should tell the script to exit. You can look for these characters using preg_match.

One more thing truefusion, do I put the Stripslashes command before the $name = $_REQUEST['Name'];?
Could you give me an example of how the Stripslash command would be written with this code?

$name = $_REQUEST['Name'];?

The quickest way would be to do:
$_REQUEST = array_map("stripslashes", $_REQUEST);
Otherwise you'd have to do
$name = stripslashes($_REQUEST['Name']);
for each relative field.

Share this post


Link to post
Share on other sites

No, when people contact me it comes through fine. I pretty much just watched a tutorial on youtube for setting up a php form for email. Should I remove those curly brackes and place some other character to close those arrays?
In regards to that security flaw you're talking about. How do I enhance that code so clients will not get spammed? I definitely don't want crackers or hackers spaming clients.

One more thing truefusion, do I put the Stripslashes command before the $name = $_REQUEST['Name'];?

Could you give me an example of how the Stripslash command would be written with this code?

$name = $_REQUEST['Name'];?

Thanks again for warning me about the security flaw. I'm in Information Security at school right now but php is alien to me. Man, I sure do appreciate the help though!

Regards,

Chad


To add the stripslashes, you should do the following with the variable:
$name = stripslashes($_REQUEST['Name']); And as truefusion states, your script needs security in the $from variable, unless it has been escaped already.

EDIT: ups sorry truefusion, didn't get early for your answer
Edited by Pankyy (see edit history)

Share this post


Link to post
Share on other sites

another thing about the script which could (should) be changed is the use of the REQUEST super-global.The Form used to supply the information is using one of either then POST or GET method. This page should therefore be dealing with the GET or POST array instead of the REQUEST array. Security would be best if you used the POST method. Harder to spoof.

Share this post


Link to post
Share on other sites

What I'm having a little hard of a time to understand is why you're stripping slashes when there isn't a moment where you put them on the variables. Because, when you use addslashes on a variable then it would be :"I/'m interested in a new design idea for one of our client/'s." and not "I/m interested in a new design idea for one of our client/s.".

Anyway, as jhaslip said, you could try changing this:

$to = stripslashes($_REQUEST['sendto']);$name = stripslashes($_REQUEST['Name']);$from = stripslashes($_REQUEST['Email']);

to this
$to = $_POST['sendto'];$name = $_POST['Name'];$from = $_POST['Email');

and then, if the slashes thing works that way, you can then concentrate on other security problems.
Edited by Pankyy (see edit history)

Share this post


Link to post
Share on other sites

I added stripslashes to the mentioned code and I'm still getting the / after apostrophes. Does my code look wrong still?

You didn't strip the slashes from the message, you only stripped some of the other fields; but place the following at the beginning of the script:
ini_set("magic_quotes_gpc", 0);

What I'm having a little hard of a time to understand is why you're stripping slashes when there isn't a moment where you put them on the variables.

It's called magic quotes. Really annoying to work with especially when working with MySQL. Thankfully they'll be completely gone by PHP 6. They're already marked as deprecated in PHP 5.3.

Share this post


Link to post
Share on other sites

Or this should work:

$body = "We have received the following information:\n\n"; foreach($fields as $a => $b){ $body .= sprintf("%20s: %s\n",$b,stripslashes($_REQUEST[$a])); }

Share this post


Link to post
Share on other sites

The best way to get rid of magic quotes is by using this code somewhere at the beginning of your script:

// If stupid Magic Quotes are Enabled		if (get_magic_quotes_gpc()) {			// Create a reference Array to Superglobals			$fullArray = array(&$_GET, &$_POST, &$_COOKIE);			// Stripslashes for every Array..			while (list($k,$v) = each($fullArray)) {				foreach ($v as $arrayKey => $Value) {					// If it isn't an Array					if (!is_array($Value)) {						$fullArray[$k][$arrayKey] = stripslashes($Value);						continue;					}					$fullArray[] =& $fullArray[$k][$arrayKey];				}			}			// Clear the used Array			$fullArray = null;			// Remove it			unset($fullArray);		}

It will check if magic quotes are enabled and will continue to remove them when needed. Of course it's even better to turn them off in php.ini or by a htaccess file on an apache server.

But remember, when you have magic quotes set to off, keep in mind that you need to use htmlspecialchars() to show $_POST and other superglobals in your HTML and when putting $_POST data to your database or file, you also need to escape it with something like addslashes() or mysql_real_escape_string(); or your scripts will be vulnerable.

Share this post


Link to post
Share on other sites

That worked! :D You guys rule and thanks for all of the help! Really! What really concerns me is the security flaws now. How can hackers modify the php code if they do not have access to my host provider or server?

 

Where do you guys think I should harden the flaws at from where the code is at now?

 

Also, I'm going to pick up a php book. I see there is a new thread about that above this one.

 

Thanks again!

 

- Chad

Share this post


Link to post
Share on other sites

What really concerns me is the security flaws now. How can hackers modify the php code if they do not have access to my host provider or server?

They don't need access to the server, you made their work easier by using _REQUEST instead of _POST. Why? Because all they need to do is look at the form's source code, look at the name of all the required fields and then just modify the URL of the script. _REQUEST covers both _POST and _GET. If you used only _POST instead of _REQUEST, that means they'd have to work harder by making their own HTML form. This is known as cross site scripting. This allows them to use TEXTAREA where INPUT fields are supposed to be, therefore allowing them to submit new lines—the very thing i said your script should look out for.

Where do you guys think I should harden the flaws at from where the code is at now?

Technically, you'll only need to filter out the fields that you eventually place in the header. In your case it would be the $from variable. I've already mentioned in a previous post what to look for and how to take care of it. However, the preg_match function uses regular expressions, so i'll provide the code on how it should look like:
if (preg_match("/(%0A|%0D|\n+|\r+)/i", $from)){	exit("Header injection detected.");}
I'ma assume you know where to place this.

Share this post


Link to post
Share on other sites

I have no idea man, I just started to learn php and basically have no idea of what I'm doing. I'm going to rework the whole script I guess. I have no experience with php and from hearing what you guys are saying, this script seems very week. I'm going to change it to the _POST command instead of _REQUEST.Thanks for the heads up on the crappy coding. I'm just going to find a better approach.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.