Intrusion-PHP's ultimate solution for XSS injection Defense [Information Security] [Hack]

Update20151202: Thank you for your attention and answers. The defense methods I have learned from various methods are as follows: PHP outputs html directly, and the following methods can be used for filtering: {code ...} if PHP is output to JS Code or JsonAPI is developed, the frontend needs to be in JS...

Update20151202:
Thank you for your attention and answers. The defense methods I have learned from various methods are as follows:

1. PHP directly outputs html, which can be filtered using the following methods:

   1.htmlspecialchars00002.html entities function 3. HTMLPurifier. auto. php plug-in 4. RemoveXss function (Baidu can check)

2. PHP output to JS Code, or Json API development, requires the front-end to filter in JS:

   1. try to use innerText (IE) and textContent (Firefox), that is, jQuery's text () to output text content 2. you must use functions such as innerHTML to filter htmlspecialchars similar to php (refer to @ eechen's answer)

3. Other general supplementary defense methods

   1. when html is output, add the Http Header of Content Security Policy (Role: this can prevent web pages from being attacked by XSS and embed third-party script files) (defect: IE or earlier versions may not be supported) 2. when setting the Cookie, add the HttpOnly parameter (function: to prevent the page from being attacked by XSS, the Cookie information is stolen and compatible with IE6) (defect: the JS Code of the website itself cannot operate on cookies, and its function is limited. It can only ensure the security of cookies.) 3. when developing APIs, check the request's Referer parameters (function: to prevent CSRF attacks to a certain extent) (defects: Referer parameters can be forged in IE or earlier browsers)

This is probably the case. What other ideas do you have!

--------------------------------------------------

The original problem is as follows:

1. How can PHP defend against XSS attacks (better than htmlspecialchars) perfectly (or as perfect as possible )?
2. I'm wondering if XSS defense is best performed on the front end (after all, JavaScript parsing strings on the front end is pitfall )?
3. Do you have any solutions or ideas?

Recently, we have been studying XSS defense issues.

After all, for example, the user-registered API may be used by Hacker to forcibly submit "script" alert ('injection successful! ') User name like script.

Then, why should the WEB Front-end display the user name...
So... Boom...

Direct Entry focus:
I have seen that many defense solutions against XSS are PHP htmlentities functions or htmlspecialchars.
If you are away from Baidu, ThinkPHP3.x uses htmlspecialchars by default.
For example, $ str = htmlspecialchars ($ str, ENT_QUOTES); // replace <> & 'with the five characters
However, is it enough to replace only those characters?

Then I found this article:
Http://tieba.baidu.com/p/3003719171
Using \ u003c \ u003e In the JS string will be interpreted as the <> feature for XSS attacks...
Slot...

Then I thought of eval and other functions in JS...
Then I found this article:
Http://www.2cto.com/Article/201310/251830.html
Using various encodings and various means to execute JavaScript code is simply chilling.
For example:

Ah! CAO.
I began to doubt the whole world...
So,
My problem is:

1. How can PHP defend against XSS attacks (better than htmlspecialchars) perfectly (or as perfect as possible )?
2. I'm wondering if XSS defense is best performed on the front end (after all, JavaScript parsing strings on the front end is pitfall )?
3. Do you have any solutions or ideas?

Update20151201:
Do you want to copy and paste the answer? or do you think htmlspecialchars is invincible?
\ U003cimg src = 1 onerror = alert (/xss/) \ u003e is not processed by htmlspecialchars.
Look at the picture by yourself, right, it's you!

Reply content:

Update20151202:
Thank you for your attention and answers. The defense methods I have learned from various methods are as follows:

1. PHP directly outputs html, which can be filtered using the following methods:

   1.htmlspecialchars00002.html entities function 3. HTMLPurifier. auto. php plug-in 4. RemoveXss function (Baidu can check)

2. PHP output to JS Code, or Json API development, requires the front-end to filter in JS:

   1. try to use innerText (IE) and textContent (Firefox), that is, jQuery's text () to output text content 2. you must use functions such as innerHTML to filter htmlspecialchars similar to php (refer to @ eechen's answer)

3. Other general supplementary defense methods

   1. when html is output, add the Http Header of Content Security Policy (Role: this can prevent web pages from being attacked by XSS and embed third-party script files) (defect: IE or earlier versions may not be supported) 2. when setting the Cookie, add the HttpOnly parameter (function: to prevent the page from being attacked by XSS, the Cookie information is stolen and compatible with IE6) (defect: the JS Code of the website itself cannot operate on cookies, and its function is limited. It can only ensure the security of cookies.) 3. when developing APIs, check the request's Referer parameters (function: to prevent CSRF attacks to a certain extent) (defects: Referer parameters can be forged in IE or earlier browsers)

This is probably the case. What other ideas do you have!

--------------------------------------------------

The original problem is as follows:

1. How can PHP defend against XSS attacks (better than htmlspecialchars) perfectly (or as perfect as possible )?
2. I'm wondering if XSS defense is best performed on the front end (after all, JavaScript parsing strings on the front end is pitfall )?
3. Do you have any solutions or ideas?

Recently, we have been studying XSS defense issues.

After all, for example, the user-registered API may be used by Hacker to forcibly submit "script" alert ('injection successful! ') User name like script.

Then, why should the WEB Front-end display the user name...
So... Boom...

Direct Entry focus:
I have seen that many defense solutions against XSS are PHP htmlentities functions or htmlspecialchars.
If you are away from Baidu, ThinkPHP3.x uses htmlspecialchars by default.
For example, $ str = htmlspecialchars ($ str, ENT_QUOTES); // replace <> & 'with the five characters
However, is it enough to replace only those characters?

Then I found this article:
Http://tieba.baidu.com/p/3003719171
Using \ u003c \ u003e In the JS string will be interpreted as the <> feature for XSS attacks...
Slot...

Then I thought of eval and other functions in JS...
Then I found this article:
Http://www.2cto.com/Article/201310/251830.html
Using various encodings and various means to execute JavaScript code is simply chilling.
For example:

Ah! CAO.
I began to doubt the whole world...
So,
My problem is:

1. How can PHP defend against XSS attacks (better than htmlspecialchars) perfectly (or as perfect as possible )?
2. I'm wondering if XSS defense is best performed on the front end (after all, JavaScript parsing strings on the front end is pitfall )?
3. Do you have any solutions or ideas?

Update20151201:
Do you want to copy and paste the answer? or do you think htmlspecialchars is invincible?
\ U003cimg src = 1 onerror = alert (/xss/) \ u003e is not processed by htmlspecialchars.
Look at the picture by yourself, right, it's you!

Let's take a look at this question ......

Now, we will be connected to an off-site brick house ......

Doodle ......

Hello, what do you think of this classmate's question?

Brick House: I look at it in the window ......

...... @ # % &*!~~ (@ $ % ......

Well, it turns out that the smog has been serious recently, so he can only look at this problem on the window ......

Now let the experts explain:

Magic also has a proper path.

If you study these things specially, you can do anything more efficiently only by professionals.

UseHTMLPurifierIs the ultimate ideal.

1. Http://www.xcoder.cn/index.php/archives/971

2. Http://willko.iteye.com/blog/475493

3. Http://www.piaoyi.org/php/HTML-Purifier-PHP-xss.html

4. Http://www.edu.cn/ji_shu_ju_le_bu_1640/20080717/t20080717_310285.shtml

5. Http://www.111cn.net/phper/phpanqn/78018.htm

6. Http://security.ctocio.com.cn/securitycomment/54/8222554.shtml

In fact, I also want to say that I don't want to give XSS protection to the front-end. The template language is used for the front-end, you can adjust the variables properly. It is the responsibility and obligation of our good men to make them feel comfortable and easy to use.

First, I would like to say that you should not challenge everyone with your ignorance.

This is an amazing thing.

Encoding in html:

<Encode html in decimal format: 

Encoding in javascript:

<Encoding octal: \ 74 hexadecimal: \ x3c unicode: \ u003c

Of course, htmlspecialchars certainly won't work. It can only be simple, or we will discuss what xss will be.

The translations performed are:'&' (ampersand) becomes '&''"' (double quote) becomes '"' when ENT_NOQUOTES is not set."'" (single quote) becomes ''' (or ') only when ENT_QUOTES is set.'<' (less than) becomes '<''>' (greater than) becomes '>'

The above code can also be written like this

test
test
test
click test《script》var a="\u003cimg src=1 onerror=alert(/xss/)\u003e";var b="\74\151\155\147\40\163\162\143\75\170\40\157\156\145\162\162\157\162\75\141\154\145\162\164\50\61\51\76";var c="\u003c\u0069\u006d\u0067\u0020\u0073\u0072\u0063\u003d\u0031\u0020\u006f\u006e\u0065\u0072\u0072\u006f\u0072\u003d\u0061\u006c\u0065\u0072\u0074\u0028\u002f\u0078\u0073\u0073\u002f\u0029\u003e";document.getElementById("a").innerHTML=a;document.getElementById("b").innerHTML=a;document.getElementById("c").innerHTML=a;《script》

But the key is, are you sure your code can be submitted? You have to be sure.

For example, the simplest href is added to the following code, which is basically a stop.

If you have tested it, you can bypass htmlspecialchars In the scenarios you mentioned.

Supplement:
You are right. After all, it is often necessary to add AJAX-loaded data to the page using innerHTML.
It is worth noting that innerHTML also outputs HTML in essence,
So we can use JS before output, like htmlspecialchars of PHP.
Replace special characters (&, ", ', <,>) with HTML entities (&"'<>).
Or directly use innerText (IE) and textContent (Firefox), that is, jQuery's text () to output text content.
Two implementations found on StackOverflow:

function escapeHtml(text) { return text .replace(/&/g, "&") .replace(//g, ">") .replace(/"/g, """) .replace(/'/g, "'");}function escapeHtml(text) { var map = { '&': '&', '<': '<', '>': '>', '"': '"', "'": ''' }; return text.replace(/[&<>"']/g, function(m) { return map[m]; });}

Method 1: Use the php htmlentities Function

Php protects against XSS attacks by using the htmlspecialchars () function.

When using the htmlspecialchars () function, pay attention to the second parameter. If htmlspecialchars ($ string) is used directly, the second parameter defaults to ENT_COMPAT. By default, the function only converts double quotation marks ("). do not escape single quotes.

Therefore, the second parameter must be added to the htmlspecialchars function. You should use htmlspecialchars ($ string, ENT_QUOTES ). of course, if you do not need to convert the quotation marks, use htmlspecialchars ($ string, ENT_NOQUOTES ).

In addition, htmlentities should be used as few as possible. htmlentities and htmlspecialchars are no different in all English, so they can all be achieved. however, in Chinese, htmlentities will convert all html code, along with the unidentifiable Chinese characters in it.

The htmlentities and htmlspecialchars functions have poor support for strings like 'and cannot be converted. Therefore, strings converted using htmlentities and htmlspecialchars can only prevent XSS attacks and SQL injection attacks.

All printed statements, such as echo and print, must be filtered using htmlentities () before printing. This prevents Xss. Note that htmlentities ($ name, ENT_NOQUOTES, GB2312) must be written in Chinese ).

Method 2: Give a function

function xss_clean($data){ // Fix &entity＼n; $data=str_replace(array('&','<','>'),array('&amp;','&lt;','&gt;'),$data); $data=preg_replace('/(&#*＼w+)[＼x00-＼x20]+;/u','$1;',$data); $data=preg_replace('/(&#x*[0-9A-F]+);*/iu','$1;',$data); $data=html_entity_decode($data,ENT_COMPAT,'UTF-8'); // Remove any attribute starting with "on" or xmlns $data=preg_replace('#(<[^>]+?[＼x00-＼x20"＼'])(?:on|xmlns)[^>]*+>#iu','$1>',$data); // Remove javascript: and vbscript: protocols $data=preg_replace('#([a-z]*)[＼x00-＼x20]*=[＼x00-＼x20]*([`＼'"]*)[＼x00-＼x20]*j[＼x00-＼x20]*a[＼x00-＼x20]*v[＼x00-＼x20]*a[＼x00-＼x20]*s[＼x00-＼x20]*c[＼x00-＼x20]*r[＼x00-＼x20]*i[＼x00-＼x20]*p[＼x00-＼x20]*t[＼x00-＼x20]*:#iu','$1=$2nojavascript...',$data); $data=preg_replace('#([a-z]*)[＼x00-＼x20]*=([＼'"]*)[＼x00-＼x20]*v[＼x00-＼x20]*b[＼x00-＼x20]*s[＼x00-＼x20]*c[＼x00-＼x20]*r[＼x00-＼x20]*i[＼x00-＼x20]*p[＼x00-＼x20]*t[＼x00-＼x20]*:#iu','$1=$2novbscript...',$data); $data=preg_replace('#([a-z]*)[＼x00-＼x20]*=([＼'"]*)[＼x00-＼x20]*-moz-binding[＼x00-＼x20]*:#u','$1=$2nomozbinding...',$data); // Only works in IE:  $data=preg_replace('#(<[^>]+?)style[＼x00-＼x20]*=[＼x00-＼x20]*[`＼'"]*.*?expression[＼x00-＼x20]*＼([^>]*+>#i','$1>',$data); $data=preg_replace('#(<[^>]+?)style[＼x00-＼x20]*=[＼x00-＼x20]*[`＼'"]*.*?behaviour[＼x00-＼x20]*＼([^>]*+>#i','$1>',$data); $data=preg_replace('#(<[^>]+?)style[＼x00-＼x20]*=[＼x00-＼x20]*[`＼'"]*.*?s[＼x00-＼x20]*c[＼x00-＼x20]*r[＼x00-＼x20]*i[＼x00-＼x20]*p[＼x00-＼x20]*t[＼x00-＼x20]*:*[^>]*+>#iu','$1>',$data); // Remove namespaced elements (we do not need them) $data=preg_replace('#
   ]*+>#i','',$data); // http://www.111cn.net/ do{// Remove really unwanted tags  $old_data=$data;  $data=preg_replace('#
   ]*+>#i','',$data); }while($old_data!==$data); // we are done... return $data;}

To defend against XSS perfectly, every development team must fully understand the XSS knowledge.Use appropriate solutions for suitable scenariosTo encode

Recommendation reference:
Https://www.owasp.org/index.php/XSS_ (Cross_Site_Scripting) _ Prevention_Cheat_Sheet

Any effort to solve this problem using a function/library is a dream.

Re-paste one side:
Https://www.owasp.org/index.php/XSS_ (Cross_Site_Scripting) _ Prevention_Cheat_Sheet

It is never possible to provide perfect defense, but it can block at least 99% (the remaining 1% is the most fierce ~~~), The current unified approach is to do a good job of input check, good programming awareness, and security escape, with the help of third-party security libraries. Do not trust input. Do not trust the output.

Why don't CSP be enough?