Front-end defense against XSS

Front-end input and feedback defenderxsstest.html:

#! XML front-end defense XS #Demo1
    





Copy the code

There are three files in total. For testing purposes, I did not separate the basic database configuration into other files.

Now we open defenderxsstest.html in a browser:

Review images

Review images

Now let's look at the database:

Review images

It's already imported into the database.

OK, the above is the most common savings XSS case. The reason for this problem is that PHP does not filter properly. At the same time, the front end is not well filtered. Some people say that the front end is useless. Attackers can use BURp to catch this packet, and then change the packet to bypass it. Yes, that's true. But everyone was misled from the start. If you want to know what's misleading, read on.

Here I draw a front end, Nginx, back end are filtered:

Review images

Mind mapping URL:www.processon.com/view/link/5...

Here we can see that the first door of the firewall is the front-end filtering XSS mechanism. It is also known as the filter structure. This chapter is about: why not copy or move front-end filtering to back-end filtering?

Here's a picture of the new filtering mechanism:

Review images

Mind mapping URL:www.processon.com/view/link/5...

Here we add front-end filtering to the back-end filtering mechanism. Why do you do that?

We all know that front-end filtering XSS can be captured software to modify, so it can be bypassed, there is no use. And Nginx filter I believe we all know, few people are willing to use it, because if do security article category, will be Nginx is to abandon the current packet, that is you publish articles will not be saved to the database, and Nginx defense XSS module is not quite as simple as the front-end and back-end, there were so many things need to be configured. As a result, many administrators do not work hard on Nginx security, even if the administrator has configured the Nginx filtering XSS module, it can be bypassed.

Using a logical defects of Nginx (details please click: www.freebuf.com/articles/we... (section 0x03: exploit Nginx&Apache environment bugs), the backend filtering mechanism must be lax at times, otherwise it would not have caused so many XSS vulnerabilities. So when an attacker enters an XSS string that bypassed the front end, Nginx, and back end, it is imported directly into the database. Then the data from the back end is not trusted. What if we added a filter on the front end to display the data coming from the back end? The answer is very good. Of course, the premise is that the front end displays the data from the back end using AJAX methods, rather than using ThinkPHP calls in templates. To be exact: this method applies only to the API interface

Now let's do a test. The previous code used the AJAX method, and

Defenderxsstest_getdata.php and defenderxsstest_querydata.php are similar to the API interfaces on the back end. We now add some code to the original:

Here is the code for front-end filtering XSS, taken from baidu FEX front-end team's Ueditor online editor:

#! php function xssCheck(str,reg){ return str ? str.replace(reg || /[&<">'](? :(amp|lt|quot|gt|#39|nbsp|#\d+);) ? /g, function (a, b) { if(b){ return a; }else{ return { '<':'<', '&':'&', '"':'"', '>':'>', "'":''', }[a] } }) : ''; }Copy the code

We then add the xssCheck() function to the original code. As follows:

#! XML front-end defense XS #Demo1
    




Copy the code

Now let's enter the XSS string and see:

Review images

It looks something like this. Let's go to the database again:

Review images

It is a full XSS string, but the front-end filters it so that the XSS is useless.

So front-end developers just need to add XSS filtering functions to the site's base.js code and add functions to each ajax data.

0x02 Front-end alarm mechanism

The alarm mechanism here is not particularly complete and can be bypassed. So what's the use of this alarm mechanism? Is in the attacker test when the detection and alarm.

We all know that when testing XSS and loading, the attacker will enteralert()Function, and the previous filtering method, are using regular matching, resulting in the regular is too long, matching is not easy, running too slow and other problems. Now we can rewrite the alert function so that the attacker can use the rewritten function when testing. The advantage of this is that the function will not fire when XSS does not exist in the current argument. If the current parameter has XSS, the attacker will enter:woaini-> Check whether the output is in the source code ->woaini<>- > check<>There is no filter -> inputor-> Uses our rewritten function -> triggers the alarm mechanism. For those of you who don't understand, here's what I drew:

Review images

A mind map: www.processon.com/view/link/5...

Let's look at the actual code:

#! php var backAlert = alert; // Assign alert to backAlert. When overwriting alert later, avoid an infinite loop and an overflow error. Window. alert = function(STR){backAlert(STR); Console. log(" alarm triggered to send data to background "); }Copy the code

Replace console.log with Ajax to send data to the backend application. Make sure you filter it when you accept it backstage. The front-end code remembers to be encrypted to prevent the attacker from seeing the intent and thus causing a bypass without triggering an alarm. Because some companies, personal websites may have their own attack alarm system, intelligent log retrieval system, I will no longer write. The data sent by Ajax is filtered and stored in the database, and then displayed. Can be developed according to their existing framework, the idea has been above, it is not difficult to understand, the code is not difficult to write. If you can't or don't want to, wait until my next article. It will have the full source code in it.

The next chapter is also about XSS defense, which is improved on the basis of the "front-end alarm mechanism" and may use the back-end. I have some ideas at present, but I don't have time to write. Let's see if we can write it by the end of March.

0 x03 epilogue

EtherDream already talked about the front firewall, but it was defensive, and I didn't. Then fix the code manually. Because even though you can defend it, the backend vulnerability is still there, and you can manually fix it by triggering the alarm mechanism. It's not that EtherDream's writing is bad, it's quite good, and it could be modified with a front-end alarm mechanism, but I still like to keep the attacker happy for a few minutes and then get confused. There is a nice snippet in EtherDream's code that uses inline events to listen for on events such as onclick, which can be used to further monitor the hacker's actions. Due to copyright issues, IT is not convenient for me to post the code in this article, after all, it is the crystallization of others' ideas. Check it out:

Fex.baidu.com/blog/2014/0...