XSS attacks

  1. XSS attacks can occur when unexpected changes (JS code execution or large style changes) occur during DOM parsing
  2. XSS is divided into reflective XSS, storage XSS and DOM XSS
  3. Reflective XSS puts the XSS code in the URL and submits the parameters to the server. The server responds after parsing, and XSS code exists in the response result, which is finally parsed and executed by the browser.
  4. Stored XSS stores THE XSS code to the server (database, memory, file system, etc.) so that the next time you request the same page, you don’t need to bring the XSS code with you, but read it from the server.
  5. DOM XSS occurs primarily as a result of using EVAL in JS, so the eval statement should be avoided.
  6. XSS harms include stealing users’ cookies, changing styles through JS or CSS, and DDos causes normal users to fail to get server responses.
  7. XSS code is mainly prevented by decoding data and filtering out dangerous labels, attributes and events.

XSS hazards

  1. Steal cookies through Document. cookie
  2. Using JS or CSS to break the normal structure and style of the page
  3. Traffic hijacking (locating to another page by accessing a segment with window.location.href)
  4. Dos attack: The use of reasonable client requests to occupy too many server resources, so that legitimate users cannot get a response from the server.
  5. Use iframe, Frame, XMLHttpRequest, or the above Flash method to perform administrative actions as the (attacked) user, or perform general operations such as tweeting, adding friends, and sending private messages.
  6. By taking advantage of the fact that the domain that can be attacked is trusted by other domains, the trusted source requests some operations that are not normally allowed, such as improper voting activities.

XSS defenses

As can be seen from the above reflection type and DOM XSS attacks, we cannot store the user input data directly to the server as is, and some data processing is needed. Some of the problems with the above code are as follows:

  1. There are no DOM nodes in danger of filtering. For example, script has the ability to execute scripts, IMG has the ability to display ads and pornographic pictures, link and style has the ability to change styles, and iframe, frame and other element nodes have embedded pages.
  2. No attribute node for filtering danger. Events, style, SRC, href, etc
  3. No httpOnly is set for cookies.

I. Protection of cookies

  1. HttpOnly important cookies to prevent clients from reading cookies through document.cookie. The server can set this field.

2. Processing of user input data

  1. Encoding: the user input cannot be kept as is, the user input data for character entity encoding. For an idea of character entities, see the reference links at the bottom of this article.
  2. Decode: The original display of the content must be decoded, otherwise the content will not be displayed.
  3. Filter: the input of some illegal things are filtered out to ensure security. For example, remove DOM attributes uploaded by users, such as onerror, and remove Style nodes, iframe and Script nodes uploaded by users.

CSRF attack The attack mechanism and process are as follows:

CSRF cross-site Request Forgery, like XSS, is a major hazard. Attackers steal your identity, in the name of your sending malicious request, the request for server is perfectly legal, but finished the attacker’s expectation of an operation, such as in the name of your email, send messages, to steal your account, add a system administrator, or even to buy goods, virtual currency transfer, etc.

  1. User C opens the browser, accesses trusted website A, and enters the user name and password to request to log in to website A.
  2. After the user information is verified, website A generates Cookie information and returns it to the browser. At this time, the user successfully logs in to website A and can send requests to website A normally.
  3. Before exiting website A, the user opens A TAB page in the same browser to visit website B.
  4. After receiving the user’s request, website B returns an attack code and sends A request to visit third-party site A.
  5. After receiving these offensive codes, the browser, according to the request of website B, carries the Cookie information without the user’s knowledge and sends A request to Website A. Website A does not know that the request is actually initiated by B, so it will process the request with C’s permission according to the Cookie information of user C, resulting in the malicious code from Website B being executed.

Victims Bob have a deposit in the bank, through to the bank send requests to http://bank.example/withdraw? website Account =bob&amount=1000000&for= BOB2 Enables Bob to transfer 1000000 deposits to boB2. Typically, after the request is sent to the site, the server first verifies that the request came from a valid session and that the session’s user Bob has logged in successfully. Mallory himself had an account at the bank and knew that the URL could transfer money. Mallory can send a request to our bank: http://bank.example/withdraw? The account = bob&amount = 1000000 & for = Mallory. But the request comes from Mallory, not Bob, who cannot pass security authentication, so the request will not work. At this moment, Mallory thought of using CSRF attacks, he first make a web site and insert the following code in the web site: SRC = “http://bank.example/withdraw? Account = Bob&amount =1000000&for=Mallory “, and entice Bob to visit his website by advertising etc. When Bob visits the site, the above URL is sent from Bob’s browser to the bank, and the request is sent to the bank server with a cookie from Bob’s browser. In most cases, the request fails because it asks for Bob’s authentication information. However, if Bob happens to visit his bank shortly after that, his browser’s session with the bank’s web site has not expired, and the browser’s cookie contains Bob’s authentication information. The url request will be answered, and the money will be transferred from Bob’s account to Mallory’s, without Bob knowing it. When Bob later found that the money was missing, even if he checked the bank logs, he could only find that there was indeed a legitimate request from him to transfer the money, without any trace of attack. Mallory gets the money and gets away with it.

Defending against CSRF attacks:

Currently, there are three main strategies to defend against CSRF attacks:

  • HTTP Referer field;
  • Add token to request address and verify;
  • Customize and validate properties in HTTP headers.

(1) Add token to request address and verify

Is to put information in the request that a hacker cannot forge and that does not exist in a cookie. A randomly generated token can be added to the HTTP request as a parameter, and an interceptor can be established on the server side to verify the token. If there is no token in the request or the token content is incorrect, the request may be rejected as a CSRF attack.

The usual approach is to use javascript to traverse the entire DOM tree each time the page loads, adding tokens to all a and form tags in the DOM. This solves most requests, but for HTML code that is generated dynamically after the page loads, this approach does not work and requires the programmer to manually add tokens at coding time.

Another disadvantage of this approach is that it is difficult to guarantee the security of tokens themselves. Especially in some forums and other websites that support users to publish their own content, hackers can publish their own personal website address. Since the system also adds a token to the address, the hacker can get the token on his own website and launch a CSRF attack right away. In order to avoid this, the system can add a judgment when adding the token, if the link is linked to their own site, add the token later, if it is to the Internet, do not add.

However, even if the CSRFtoken is not attached to the request as a parameter, a hacker’s site can also obtain the token value via the Referer to launch a CSRF attack. This is why some users prefer to turn off the browser Referer manually.

(2) Customize attributes in HTTP headers and validate them

This method also uses the token and validates by putting it in a custom attribute in the HTTP header. With the XMLHttpRequest class, you can add the CSRFToken HTTP header attribute and put the token value into all of the class requests at once. This eliminates the inconvenience of adding the token to the request in the previous method, and the XMLHttpRequest address is not logged in the browser’s address bar, and the token is not leaked to other sites through the Referer.

However, this approach has significant limitations. XMLHttpRequest is usually used for asynchronous partial page refresh in Ajax methods. Not all requests are suitable to be initiated with this class, and the page obtained through this class cannot be recorded by the browser, thus making it inconvenient for users to move forward, backward, refresh, and save.

In addition, for legacy systems without CSRF protection, this approach to protection requires that all requests be converted to XMLHttpRequest requests, which is almost an entire web site rewrite, an unacceptable cost.