XSS Vulnerbility fix

[djr33]

John, the biggest problem with that would be anyone trying to send a message in a language that uses a different character set, or perhaps special punctuation characters (also names from other languages) even in English. It would be secure but overkill.

Mat, if you are the only recipient of the emails and you are using gmail, then I honestly don't see any potential problems, at all, even using raw data. Gmail protects you well enough and if you're not using HTML anyway, it should be fine. Gmail probably strips malicious JS (most of it anyway) even if you ARE using HTML. They scan every attachment for viruses before allowing you to download it, so I'd expect they'd be just as careful with the text of the message.

One warning: don't click any links in the email unless you feel that you can trust the sender; or open them on a secured computer (for example, don't use windows [which is the target of most viruses] and use a new browser session so that your cookies won't have any important information).

But realistically you're worrying way too much about this if you are not planning to automatically post the information publicly.

htmlentities() will be enough to stop any type of XSS, for any situation in which it may be relevant. No complex Regex is needed.

But again, XSS is just one type of malicious code that can be injected, but it is the only* kind of malicious code that is a problem related to HTML-- the rest is when you are using databases or doing something else-- you're not, so don't worry about it (for now).

(*Malicious HTML in general, not just XSS, but XSS is more or less the only dangerous kind-- the rest is just annoying such as something that would change the content of your page, perhaps inserting an advertisement or breaking the code so the page doesn't display properly, but not something that is truly "dangerous" like XSS that's a possible security threat. Regardless ALL HTML problems will be solved by htmlentities()-- that entirely disables the operator characters that make HTML do anything-- < > and " &. In fact, you only really need to disable < > for security. " and & just create code-instability problems and errors, but can't in themselves generate XSS or other dangerous code.)


In summary, use htmlentities() if you want to be extra careful and account for all situations including those where you would actually be using this text WITHIN HTML. If you never use it within HTML (including email, unless you're specifically sending it as HTML) then you don't even need to do that.


Getting back to the big picture, ask yourself this question: what characters make HTML work? The answer is < and >, and nothing else. You cannot write HTML (and thereby JS/CSS) without < and >, so those are the ONLY characters you need to disable. htmlentities() is one way to do that. There are other ways if you prefer.

(The only exception to that would be a very unusual case where you have incorrectly mixed character encodings so that multibyte characters, such as Chinese characters [typically 4 bytes each], are read individually, in which case one byte of the multi-byte character MIGHT be interpreted as < or >, but the circumstances for this occuring are so bizarre that you can basically ignore it. You would need to have mixed character encodings, a problem in itself, setup in exactly such a way that your checking for < and > would recognize the full multibyte characters then the final output would be displaying them separately and recognize individual bytes as < and >, but more importantly for someone to actually exploit this, they would need to predict all of this-- almost impossible and certainly not worth the effort. But if you want to protect yourself specifically from this, ALWAYS use unicode [UTF8] for everything. That's a good idea anyway in almost all cases. To be clear, though, worrying about this is a waste of time, in my opinion.)

[mat420]

so long story short, im completely fine and dont need to worry about any attacks that can be avoided? as long as im as safe as most of the popular sites out there, im content.

after all of this tho i might as well go the extra mile and block < >
this didnt work, how would i enter it to block <, > please? feel free to add any other newly thought of characters I may want blocked.

$new_string = ereg_replace("[^<>]", "", $body);

thanks SO much everyone. not sure what id do without this forum, esp since..the others seem to suck (sshh. P) THANKS AGAIN!

[jscheuer1]

Use preg, ereg has been deprecated. But the main problem is that you're still using the not token - ^. Do:

$new_string = preg_replace("/[<>]/", "", $body); 

instead. Notice also that preg requires the addition of the / tokens.

If you have PHP < 4 (very unlikely), you might actually need to use ereg:

$new_string = ereg_replace("[<>]", "", $body); 

[mat420]

aawesome thanks a lot
to make things simple i first just tried using

$new_string = ereg_replace("[<>]", "", $body); 
        mail($myaddress, 'Contact Form Submission', $new_string ); 

and i sent myself a test form, and everything appears fine, no /div or anything, i assume that puts me in the clear now? thanks a million

[jscheuer1]

to make things simple i first just tried using (ereg)

Not good, not even simple, really. To use mail(), you must have PHP 4 or greater, which supports preg. If you ever migrate to PHP 5.3 or greater (either by upgrading the host, or if it's not your own server, if the host upgrades, or if you switch to a more modern host), all code that you have that uses ereg will break.

In other words, if you don't use preg now, and use it everywhere that you may currently be using ereg, it could get real complicated finding and fixing things later. The syntax is generally the same, it just requires the extra delimiters for the regex. There may be minor exceptions, check the docs for any specific implementation. But for this, all that's required are the extra delimiters as already mentioned in my previous post.



As to what you do have:

Unless /div wasn't in the raw data, or something you're not showing is stripping it out, or mail() itself is stripping out /div, it should come through.

I looked through the documentation on php.net for mail() (that's where I discovered it requires PHP 4 or greater). It doesn't come right out and say it strips anything, but does say to (for HTML emails):

 . . .

// To send HTML mail, the Content-type header must be set
$headers  = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";

// Additional headers
$headers .= 'To: Mary <mary@example.com>, Kelly <kelly@example.com>' . "\r\n";
$headers .= 'From: Birthday Reminder <birthday@example.com>' . "\r\n";
$headers .= 'Cc: birthdayarchive@example.com' . "\r\n";
$headers .= 'Bcc: birthdaycheck@example.com' . "\r\n";

// Mail it
mail($to, $subject, $message, $headers);

and:

Note:

If intending to send HTML or otherwise Complex mails, it is recommended to use the PEAR package » PEAR::Mail_Mime.

It's possible that without employing one or the other of those two approaches, mail() is stripping the tags. But I'm really not sure. And, since you strip out <> before that, they wouldn't really be tags any more, so would be difficult (but not impossible) for mail() to identify them as tags at that point.

[djr33]

Your site is secure, since this content doesn't appear on the site (by default). Your personal email is the only possible problem, but as we've discussed it's probably fine and definitely fine if you remove < and >.

CORRECTION: We've been mentioning the function htmlentities(). This is actually not required-- it converts extra characters than required. (It would still be secure, but it's more than you need.)

The simple function I was thinking of is htmlspecialchars().
(Note: this also converts single quotes, so that might help sometimes.)

(Sorry for the confusion-- the names of these functions are similar and they do similar things, but htmlentities() just does more than is required here.)


So you don't need to make your own function for this. Just use htmlspecialchars() and it will all be fine.


To clarify and summarize everything:
1. You are not posting user input on your website. That in itself makes your website secure.
2. You probably are secure with your email already.
3. To completely disable HTML, the characters < and > need to be disabled.
4. The easiest (default) way of doing this is htmlspecialchars().