Workarounds for XSS attacks

In my previous "front-end security XSS attack" article, did not put the solution of XSS attack is complete, and the attack of XSS is so multifarious, there is not a recruit "lone nine swords" can contend, after all, so many scenarios, developers can not take care of each other, and today by reading "White hat talk about Web security." This book, the coping style has a better summary, divided into two categories, one is the service can do, the second is the client can do.

Premise

There is a premise when it comes to XSS solutions. Is the same-origin policy-the browser's same-origin policy (the basis of browser security, even if the attack script to abide by the law), restricting the "document" or script from different sources, reading or setting some properties on the current "document". In addition to DOM, cookies, and XMLHttpRequest are subject to the same-origin policy, some third-party plugins loaded by the browser also have their own homologous policies. However, tags such as script, IMG, IFRAME, and link can load resources across domains without being constrained by the same-origin policy.

What you can do on the service side

1. HttpOnly

In fact, it is now the HTTP protocol (HTTPS is also possible) to read Cookies,javascript is not read cookies. Supported browsers are ie6+, firefox2+, Google, safari4+.

Java EE adds httponly code to a cookie:

Response.setheader ("Set-cookie", "cookiename=value; path=/;D Omain=domainvalue; Max-age=seconds; HttpOnly ");

PS: For HTTPS, you can also set the secure field to encrypt the cookie securely.

This is not essentially preventing XSS, but not allowing JS to read cookies when it is compromised.

2. Working with Rich Text

Some data cannot be escaped directly on the server because of the use of scenario problems. However, rich text data semantics are full HTML code, and in the output will not be pieced together in the properties of a tag, so you can be special case when special processing. The process is to configure a white list of rich text tags and attributes on the server, and not allow other tags or attributes (such as script, iframe, form, etc.), or "XSS Filter." It is then filtered before storing (the filtering principle is not explored).

Java has an open source project Anti-samy is a very good XSS Filter:

Policy Ploicy =new= As.scan (dirtyinput, policy); Myuserdao.storeuserprofile (cr.getcleanhtml ());

PS: Of course, can also be filtered before the front-end display, but I think, let the front-end personnel to do less good, and the server only need to turn once.

What the client can do

1. Input check

The logic of the input check must be implemented in the server-side code (because JavaScript does input checking and is easily bypassed by attackers). The common practice of web development at the moment is to implement the same input checks in both client-side JavaScript and server code. Client JavaScript input Check, can block most of the normal users of misoperation, thereby saving service resources.

PS: Simply put, is the input check, the server and the client to do.

In addition, where an attacker could enter XSS, for example:

1. All input frames on the page 2.window.location (href, hash, etc.) 3.window.name4.document.referrer5.document.cookie6.localstorage7.xmlhttprequest returned data

PS: Of course not only these

2. Output check

In general, when a variable is exported to an HTML page, it is encoded or escaped to protect against XSS attacks. The essence of XSS is "HTML injection", and the user's data is executed as part of the HTML code, thus confusing the original semantics and generating new semantics.

Where XSS is triggered

1.document.write2.xxx.innerhtml=3.xxx.outerhtml=4. InnerHTML.replace5.document.attachEvent6.window.attachEvent7.document.location.replace8.document.location.assign

PS: If you use jquery, that is, those append, HTML, before, after, and so on, is actually stitching the variable to HTML page generation. Most MVC frameworks automatically handle XSS issues, such as ANGULARJS, in the template (view layer).

What code to use to escape

HTMLEncode and Javascriptencode are the main two, the client and the server can do. But let the back end to do, I feel is not reliable, because the data usage scene may have several, can in the tag, the attribute, or the script (even other terminal use), only in one way to encode is the limit.

1.HTMLEncode, is the conversion of characters to htmlentities, will generally turn (&, <, >, ",",/) the 6 characters.

2.JavaScriptEncode, is the use of "\" to escape special characters.

PS: In the article "HTMLEncode and Javascriptencode (Prevention of XSS)" I summarize the more complete HTMLEncode and Javascriptencode two front-end functions, as well as a few examples.

Which areas need to be escaped

1. Output in HTML tags, attributes--with HTMLEncode

2. Output in Script tab--with Javascriptencode

3. Output in Event--with Javascriptencode

<href= "#"  onclick= "Funca (' $var ')">Test< /a>

4. Output in CSS

In a way similar to Javascriptencode. Encodes all characters except letters and numbers into 16 binary form "\uhh".

5. Output in Address

In general, if the variable is the entire URL, first check whether the variable begins with "http" (not the Help to add HTTP), to ensure that there is no pseudo-protocol class of XSS attacks. The variable is then UrlEncode.

Ps:urlencode will convert the characters to "%hh" form.

Summarize

Front-end developers should pay attention to the correct coding in the right place, and sometimes in order to defend against XSS, in one place we need to combine HTMLEncode, javascriptencode to encode, or even overlay, not a fixed way of coding (and specific case specific analysis).

General Storage-type XSS risks are higher than reflected XSS. Reflective XSS generally requires an attacker to persuade a user to click a URL link that contains an XSS code, whereas a storage type requires the user to view a normal URL link, and the XSS payload is executed when the user opens the page. This vulnerability is extremely covert, and ambush in the user's normal business, the risk is high. (The Confession Hat Speaks Web security original)

This article for the original article, reproduced please retain the original source, convenient traceability, if there is the wrong place, thank you correct.

This address: http://www.cnblogs.com/lovesong/p/5223989.html

Workarounds for XSS attacks