A defense solution for XSS Cross-site scripting attacks

Cross Site scripting attacks (Scripting), which are not confused with the abbreviations of cascading style sheets (cascading style Sheets, CSS), are abbreviated as XSS for cross-site scripting attacks.

Here we divide the context to form a defensive solution, although it is still possible to generate XSS in some special cases, but if you follow this solution strictly, you can avoid most XSS attacks.

Principle: Prefer to die also do not let the data into executable code, do not trust any user's data, strictly distinguish between data and code.

The attack principle of XSS is not elaborated here, please visit the wiki encyclopedia or Baidu encyclopedia for details.

Since the data is injected into the code to become executable code, then we find out all possible places, the vast majority of XSS occurs in the MVC pattern inside the view layer.

Let's take a look at the process.

Where: A B C D E F marks a place where an XSS may be generated

We have different contexts to carry out different coding functions, we can definitely cut off in these places to produce XSS, as long as the situation is not special (such as: Wide-byte base64 encoding, etc.), you can guarantee security.

terminology (Must-read):

The following terms, Javascriptencode, Cssencode, HTMLEncode, UrlEncode , are not a built-in function in a language, but a function implementation. Data that can be escaped into a specific language

such as the HTMLEncode function implementation should be at least & < > "'/and other symbols escaped into &amp &lt &gt &quot & #x27 & #x2F

A: Back end " " "" "CSS

There is usually no XSS in the output to CSS, but if there is a possible user-controllable variable in the CSS, if I can customize the style property and not filter it, or you can directly control a piece of CSS.

<style= "Background-image:url (Javascript:alert (/xss/));" >
Similarly
<style>
Background-image:url (Javascript:alert (/xss/)); }

</style>

This can be achieved using pseudo-protocols.

Solution:

The data inside the style attribute is checked strictly, and the content of the user output to the XSS is appropriately CSS encoded.

B: Back end " " "" Javascript

This direct output of JS is not filtered is simply the old XSS vulnerability.

var x = ""; // If you assume that the user can control the x variable // then I enter "; alert (/xss/);// // then this string of code will become var x = ""; alert (/xss/);//"; The red section is the user-entered character // successful popup prompt and executes additional code

Of course there are a bunch of ways to implement various XSS, various poses. So this is the most simple XSS and the easiest to use.

Workaround:

The strict Javascriptencode, the escape of certain characters, such as "become \", "become \" and so on (not only these) prevent the user from escaping your double (single) quotation marks, but also prevent other poses to inject.

C:javascript the HTML element or add HTML element attributes

such as JS to <div> add height property to <div height= "200px" >

for this time, any element generated from a function such as JS output data to a property or innerhtml/document.write is considered a possible XSS output. because the context is not the same, this javascriptencode is wrong.

Otherwise you can only guarantee that the data in JS will not be injected, and in the HTML, it is not necessarily.

Workaround:

You should use HTMLEncode encoding to ensure that the elements and attributes you output from JS to HTML are not out of your control.

D:javascript "" "in the output to the HTML element inside the event or any other dynamic execution JS place

Columns are listed below a section of code, if Foo is executed from JS after the dynamic output into the HTML. Foo is user-controllable.

<script>document.write (" </script>
onload = ' alert (' var '); ' >

Then I can be the same as the last time, input "; alert (/xss/);//, even if you first use a jsencode from the back end to JS, but unfortunately, the output to the HTML event (write function) after the code will be escaped back, so I still executed.

It will become:

As you can see, congratulations on executing my malicious code when you're finished loading.

Solution:

Use Javascriptencode to encode the JS code in the event. This must also be considered as a possible XSS output.

E: Back end of the "" "the output to the HTML element inside the event or any other dynamic execution JS place

The column can be considered exactly the same as D , so you just need to understand the D situation, then this is understandable.

<img onload= ' var '>

Enter '; alert (/xss/) If Var is the backend directly without processing output;//triggers XSS

Workaround:

It is also a javascriptencode to Var.

F: Back end "" "generates HTML elements or adds HTML element attributes

The same is true of C. Only the output source is different, the principle mode is the same.

< Div > $var </ Div >

If the $var is back-end output, then I can enter <script>alert (/xss/) </script> or

Anyway, it's easy to inject XSS.

Workaround:

The Var variable is HTMLEncode, then I can not build <> any element anyway. It is impossible to have <script> or new elements to take advantage of the OnLoad event.

summarized above:

If you take a closer look at this, you will be enlightened, in short, the data and code must be strictly separated, and then to observe the output to where the context of the output is.

Remember that from one code to another, it is considered a possible XSS, because the characters that were originally escaped are escaped back at the time of the output.

For example, "will change back", because the browser to ensure that users see is "and not \", otherwise the business is wrong, you always do not want you to write a name is suwings ' blog results after the refresh into suwings\ ' blog bar ...

Thank you for your patience to read, if you like can recommend, or support, the shortcomings are also correct.

A defense solution for XSS Cross-site scripting attacks