XSS vulnerability of one cross-origin request continued

XSS vulnerability of one cross-origin request continued

As mentioned above, because you need to use the proxy page to solve the cross-origin request of POST requests, You need to execute the passed function on the proxy page. Therefore, we implemented a whitelist. Only the callback functions we recognized can be executed on the page to prevent execution of illegal JS methods and script attacks.

The method we use is to introduce the whitelist and filtering methods as separate files to the page and then use them (this provides a new opportunity for the vulnerability ).

There are two reasons for this vulnerability:

If the current page of JS files blocked by the whitelist cannot be detected, the method will not be filtered out (why? This prevents a request from failing due to some reasons after the whitelist fails, resulting in a process failure. For this reason, the vulnerability is given a chance .)

How can I easily control this white list? This vulnerability exploits the xss filter feature of the browser. When an xss attack is detected in the URL, the browser automatically filters the JS content on the page. By using this principle, the white list filtering function of the page is disabled, and no restrictions are imposed. As a result, the filter function can be bypassed directly and the attack code is executed on the page.

After investigation, the browser filters out the JS address in the URL to prevent XSS attacks. Visit the following address:

https://www.baidu.com/?xss=%3Cscript%20type%3D%22text%2Fjavascript%22%20src%3D%22https%3A%2F%2Fss1.bdstatic.com%2F5eN1bjq8AAUYm2zgoY3K%2Fr%2Fwww%2Fcache%2Fstatic%2Fprotocol%2Fhttps%2Fjquery%2Fjquery-1.10.2.min_f2fb5194.js%22%3E%3C%2Fscript%3E

The following error is reported:

The XSS Auditor refused to execute a script in 'https: // www.baidu.com /? Xss = % 3 Cscript % 20 type % 3D % 22 text % 2 Fjavascript % 22% 20src... Ocol % 2 Fhttps % 2 Fjquery % 2Fjquery-1.10.2.min_f2fb5194.js % 22% 3E % 3C % 2 Fscript % 3E 'because its source code was found within the request. the auditor was enabled as the server sent neither an 'X-XSS-Protection 'nor 'content-Security-policy' header.

As a result, the page cannot load jquery JS, and this JS is considered an XSS attack.

Here, we can check whether the XSS filter function of the browser is enabled by using this field in the http header. That is: X-XSS-Protection.

So what is X-XSS-Protection? This is to prevent XSS attacks. You can set its value to enable or disable XSS filtering. Of course, you should enable this function to understand and learn this field in http. How should I configure it?

0-Disable xss protection for the browser 1-enable xss protection 1; mode = block-enable xss protection and notify the browser not to filter user injection scripts. 1; report = http://site.com/report-this is only supported by chrome and webkit kernels, this mode tells the browser to post this part of data to the specified address when it finds a suspected xss attack.

After XSS protection is enabled, the browser hides the output of reflective XSS.

Here, I have two solutions:

Put the filtering method on the page, and do not use the external form; or if the detection method cannot be detected, the process is directly blocked.

XSS is not a battle.