13.6.4 Cross-Site Scripting
This two-line script uses window.location.search to obtain the portion of its own URL that begins with ?. It uses document.write() to add dynamically generated content to the document. This page is intended to be invoked with a URL like this:
When used like this, it displays the text “Hello David”. But consider what happens when it is invoked with this URL:
With this URL, the script dynamically generates another script (%3C and %3E are codes for angle brackets)! In this case, the injected script simply displays a dialog box, which is relatively benign. But consider this case:
Cross-site scripting attacks are so called because more than one site is involved. Site B (or some other site C) includes a specially crafted link (like the one above) to site A that injects a script from site B. The script evil.js is hosted by the evil site B, but it is now embedded in site A, and it can do absolutely anything it wants with site A’s content. It might deface the page or cause it to malfunction (such as by initiating one of the denialof-service attacks described in the next section). This would be bad for site A’s customer relations. More dangerously, the malicious script can read cookies stored by site A (perhaps account numbers or other personally identifying information) and send that data back to site B. The injected script can even track the user’s keystrokes and send that data back to site B.
In general, the way to prevent XSS attacks is to remove HTML tags from any untrusted data before using it to create dynamic document content. You can fix the greet.html file shown earlier by adding this line of code to remove the angle brackets aroundtags:
name = name.replace(//g, ">");
HTML5 goes beyond content sanitation strategies and is defining a sandbox attribute for the欢迎转载,转载请注明来自一手册:http://yishouce.com/book/1/31418.html