This is the second day of my participation in Gwen Challenge

XSS principles and attack and defense

XSS is introduced

XSS(Crossing Site Scripting) cross-site Scripting ->CSS has been replaced

XSS simply put, XSS occurs when a target site, accessed by a user, executes unexpected script instructions during the rendering of HTML

The attack of XSS is that the attacker uses various methods to insert some of his own scripts when the user visits the page, and the attacker obtains various information through the execution of the inserted scripts. Like getting cookies and sending them to your own website.

XSS hazards

  • Hang a horse
  • Steal users’ cookies
  • DDOS attack
  • Phishing attack
  • Deleting targeted articles, maliciously tampering with data
  • Hijacking user Web behavior
  • Web2.0 worm outbreak
  • Worm DDos attacks
  • Worm mounted attack, brush advertising, traffic.

Types of XSS

Reflective: When a request is made, the XSS code usually appears in the access link, and is submitted to the server as part of the input. After the server parses, it makes a response, and the code is sent to the browser with the response, and the browser executes the XSS code. Over and over again, the original XSS code is reflected back from the server and executed in the browser. So this is also called reflex. Chrome blocks this XSS behavior. Features: non-persistent, malicious code generally appears in urls.

** Stored: ** differs from reflection in that the submitted code is stored on the server. There is no need to commit the XSS code on the next request. As data is read, the server sends back data to the browser, such as forum posts, product reviews, etc.

Features: XSS code is stored on the Web server, and attackers can store it on the server by Posting these actions. Can be used in combination with reflective type. For example, by encoding a URL to attack, you can bypass the XSS filter on the back end. If the user clicks on the URL when accessing the page, a stored XSS attack will be triggered.

DOM: relatively simple, is to rely on the browser DOM parsing, completely the client. For example, if a DOM node is dynamically constructed from input, XSS attacks can occur if the input is not filtered. For example, the client writes a script without filtering attacks. If reflection works well, you can also use reflection to control the DOM and implement a DOM attack.

Why XSS exists

The root cause of the existence is that we do not filter the parameters of the URL, or the input submitted by the user, sufficiently, so some illegal parameters and input content can reach the Web server, and finally when the user visits the page, the XSS code may be executed.

Of course, hackers will study how to bypass XSS filtering. But there are precautions we can take

XSS detection

  • Manually detect XSS vulnerabilities using the generic XSS attack string.
    • XSS vulnerabilities can be detected in HTML,CSS and other contexts.
  • Use scanning tools to automatically detect XSS vulnerabilities.

To prevent XSS

The general idea is to filter the input and URL parameters and encode the output (the content that is dynamically output to the page). Cookie is set to HTTP-only.

1. Input processing

Input processing includes processing of input (including user input, URL parameters, POST request parameters, ajax), including

  • XSS attacks half-corner characters -> full-corner characters
  • Blacklist filtering policies are as follows:
  • Whitelist rules (suggested), but too strict.
  • Use a whitelist for username, password, etc., but a rich text editor uses a blacklist because the user does not know what to type.

2. Output processing

  • All dynamic output is encoded and escaped (depending on the context of the output).
    • For HTML pages, we can escape < to < (< is HTML enity, HTML entity).
    • For output json, we might want to add \ -> \, / -> / and so on.

3. Set the Cookie to HTTP-only

Generally, XSS uses JS to read cookies. If http-only is set on the server, JS cannot obtain cookies, but the browser can use them normally.

4. Guard against Dom attacks

Because js code is inherently indiscreet, be careful with apis such as innerHTML,document.write(), and the href attribute of the A tag. Js eval() and so on. If untrusted data is concatenated into strings and passed to the API, it is easy to create a security breach. 5. Input length control Because you control the content length for untrusted input, even when you insert XSS code, the difficulty is further increased. 6.CSP

Some advice

  • Use template engine, with HTML escape ** (2) **
  • Avoid inline events, such as onClick = “go(‘{{action}}’)”(4)
  • Avoid concatenated HTML and use a mature framework. (1)
  • Be vigilant at all times, when inserting DOM attributes, take precautions when linking, and be careful of related apis **(4)**.
  • Increased attack difficulty (CSP, input length limit, interface security measures) (5.6)
  • Proactive detection and discovery, using XSS attack strings and automatic scanning tools. (testing)

Defense of programming languages

  • For example, NodeJS uses the JS-XSS library as a transformation.

CSRF principle and defense

The essence of CSRF is that the Web server does not have enough authentication. Currently, the server verifies that the Session exists, indicating that it is logged in. But there is no guarantee that the request was triggered by the user. How to solve it? 1. Try to use POST first, because GET is too easy to exploit, but an attacker can still attack by constructing a form 2. Adding a captcha first ensures that it is the user’s behavior. 3. Verify the Referer, and you can still change the Referer or other headers when sending a request. 4. Anti-csrf Token: Hackers cannot forge information when requesting it, and the information does not exist in the cookie.

  1. Add custom headers

A CSRF attack requires two conditions:

  1. Log in to A trusted website A and store cookies locally;
  2. Accessing dangerous website B without shutting down A;

As long as website A does not have the corresponding CSRF protection, users meeting these two conditions will be taken in, and the attacker does not need to obtain the victim’s Cookie.

Protection strategy

  • Block access to unknown outfields
    • Homologous detection
    • Samesite Cookie
  • Submit by asking for additional information that is available only to the local domain
    • CSRF Token
    • Double Cookie authentication

The same-origin policy

How do I determine if a request is from an outdomain?

  • Origin Header
  • Referer Header

In some CSRF-related requests, the request Header carries the Origin field. The field contains the requested domain name (excluding PATH and Query).

Origin Header

If Origin exists, just use the fields in Origin to identify the source domain name. But Origin doesn’t exist in two cases:

  • Internet Explorer 11 Same-origin policy: Internet Explorer 11 will not add the Origin header on cross-site CORS requests, and the Referer header will remain the unique identifier.
  • 302 Redirects: After 302 redirects Origin is not included in redirected requests because Origin may be considered sensitive information from other sources. In the case of 302 redirects, the URL is directed to the new server, so the browser does not want to leak Origin to the new server.

Referer Header

The value of the Referer is provided by the browser. Although there are clear requirements on the HTTP protocol, the specific implementation of the Referer by each browser may be different, and there is no guarantee that the browser itself is free of security vulnerabilities. In some cases, attackers can hide or even modify the Referer of their own requests. Attackers can hide Referer in their requests. What if the Origin and Referer headers do not exist? If neither Origin nor Referer exists, it is recommended to block it directly, especially if you are not using a random CSRF Token (see below) as a second check. In addition, as mentioned earlier, CSRFS mostly come from third-party domain names, but local domain initiation cannot be ruled out. If an attacker has permission to post comments (including links and images, collectively referred to as UGC) in the local domain, it can directly launch attacks in the local domain. In this case, the same-origin policy cannot protect against attacks.