How to Prevent Xss With Html/PHP

Preventing XSS from within HTML elements

Inside the content of an element, the only character that can be harmful is the start-tag delimiter < as it may denote the start of some markup declaration, whether it’s a start tag, an end tag, or a comment. So that character should always be escaped.

The other characters do not necessarily need to be escaped inside the content of an element.

The quotes do only need to be escaped inside tags, especially when used for attribute values that are either wrapped within the same quotes or not quoted at all. Similarly, the markup declaration close delimiter > does only need to be escaped inside the tags, here only when used in a unquoted attribute value. However, escaping plain ampersands as well is recommended to avoid them being interpreted as start of a character reference by mistake.

Now as for the the reason to replace / as well, it may either be due to a feature in SGML, the markup language HTML is adapted from, which allowed so called null end-tag:

To see how null end-tags work in practice consider its use in conjunction with an element which can be defined as:

<!ELEMENT ISBN  - -  CDATA --ISBN number-- >

Instead of entering an ISBN number as:

<ISBN>0 201 17535 5</ISBN>

we can use the null end-tag option to enter the element in the shortened form:

<ISBN/0 201 17535 5/

However, I’ve never seen this feature ever been implemented by any browser. HTML’s syntax rules has always been more strict than SGML syntax rules.

Another, more probable reason is the content model of so called raw text elements (script and style), which is plain text with the following restriction:

The text in raw text and RCDATA elements must not contain any occurrences of the string "</" (U+003C LESS-THAN SIGN, U+002F SOLIDUS) followed by characters that case-insensitively match the tag name of the element followed by one of "tab" (U+0009), "LF" (U+000A), "FF" (U+000C), "CR" (U+000D), U+0020 SPACE, ">" (U+003E), or "/" (U+002F).

Here it says that inside raw text elements such as script an occurrence of </script/ would denote the end tag:

<script>
alert(0</script/.exec("script").index)
</script>

Although perfectly valid JavaScript code, the end tag would be denoted by </script/. But besides that, the / does not prone any harm. And if you would allow arbitrary input being used in a JavaScript context only with escaping HTML, you’d be already doomed.

By the way, it doesn’t matter with what kind of character reference these characters are escaped, whether it’s named character references (i.e. entity references), or numeric character references, either in decimal or hexadecimal notation. They all reference the same characters.

Prevent XSS attacks when echoing HTML using PHP

Once the document reaches a user's browser it is theirs to manipulate how they like. This in itself isn't XSS. An XSS exploit exists when a bad actor can inject a script in other people's document. In your example, so long as this.name doesn't come from user input you don't have a problem.

How to fix php XSS issues

XSS stands for Cross-Site Scripting these are attacks. A type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

We want to prevent this from happening. Since you are using PHP this won't be resolved using http://htmlpurifier.org/. You'll have to use another method. What you can try are the following options:

• Encrypt your values inside the echo statement.
• Your application code should never output data received as input directly to the browser without checking it for malicious code.

These are simple steps to prevent an XSS attack from happening:

1. Train and maintain awareness.

• To keep your web application safe, everyone involved in building the web application must be aware of the risks associated with XSS vulnerabilities. You should provide suitable security training to all your developers, QA staff, DevOps, and SysAdmins. You can start by referring them to this page.

2. Don’t trust any user input.

• Treat all user input as untrusted. Any user input that is used as part of HTML output introduces a risk of an XSS. Treat input from authenticated and/or internal users the same way that you treat public input.

3. Use escaping/encoding.

• Use an appropriate escaping/encoding technique depending on where user input is to be used: HTML escape, JavaScript escape, CSS escape, URL escape, etc. Use existing libraries for escaping, don’t write your own unless absolutely necessary.

4. Sanitize HTML.

• If the user input needs to contain HTML, you can’t escape/encode it because it would break valid tags. In such cases, use a trusted and verified library to parse and clean HTML. Choose the library depending on your development language, for example, HtmlSanitizer for .NET or SanitizeHelper for Ruby on Rails.

5. Set the HttpOnly flag.

• To mitigate the consequences of a possible XSS vulnerability, set the HttpOnly flag for cookies. If you do, such cookies will not be accessible via client-side JavaScript.

6. Use a Content Security Policy.

• To mitigate the consequences of a possible XSS vulnerability, also use a Content Security Policy (CSP). CSP is an HTTP response header that lets you declare the dynamic resources that are allowed to load depending on the request source.

7. Scan regularly (with Acunetix).

• XSS vulnerabilities may be introduced by your developers or through external libraries/modules/software. You should regularly scan your web applications using a web vulnerability scanner such as Acunetix. If you use Jenkins, you should install the Acunetix plugin to automatically scan every build.

I'll include two short examples of encoding in PHP here:
You could try the htmlspecialchars I suggested to you earlier.
I'll give an example with the line of code you gave is on your question.

echo '<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">'

Would be changed to:

echo htmlspecialchars('<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">', ENT_QUOTES, 'UTF-8');

You could also use a html encoder and place this inside an echo for example:

echo "<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">"

These all give the output:
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">.

Here is a short explantion about what XSS does.
In a Cross-site Scripting attack (XSS), the attacker uses your vulnerable web page to deliver malicious JavaScript to your user. The user’s browser executes this malicious JavaScript on the user’s computer. Note that about one in three websites is vulnerable to Cross-site scripting.

Google Code University also has these very educational videos on Web Security:

• How To Break Web Software - A look at security vulnerabilities in web software

• What Every Engineer Needs to Know About Security and Where to Learn It

EDIT: This website may also help you. http://htmlpurifier.org/ <- this rewrites your code. As said in a review by IRIS: "I'd just like to say we use HTML Purifier in IRIS for filtering emails against XSS attacks and we've been more than impressed.". Take a look into it, it might help you out.

---

Related Topics