XSS (Cross-site Scripting) Cross-site Scripting attacks

Cross-site Scripting (XSS) is an attack that uses illegal HTML tags or JavaScript running in the browser of a registered user of a vulnerable Web Site. Dynamically created HTML sections can hide security holes. In this way, attackers write scripts to trap users running on their own browsers, exposing them to passive attacks if they are not careful.

XSS type

1. Non-persistent XSS (Reflective XSS)

Reflective XSS simply “reflects” the data entered by the user back to the browser. This type of attack usually requires the attacker to trick the user into clicking on a malicious link, or submitting a form, or injecting a script into a malicious site when entering it. When a user clicks a malicious link, the page is redirected to the page prepared by the attacker, and the JS script is executed on the attacker’s page. Depending on the attacker’s purpose, an attacker can inject any malicious script to attack, either a hoax script or a script that can capture a user’s private data, such as cookies.

Defense strategy:

  • All content rendered on a Web page orRendered dataAll must come from the server side.
  • Try not to render directly from DOM apis such as URLS, document.referrer, document.forms, etc.
  • Try not to useeval, new Function(), document.write(), document.writeln(), window.setInterval(), window.setTimeout(), innerHTML, Methods such as document.createElement() that execute strings.
  • Filter unnecessary HTML tags, such as:iframeAlt Script and special characters. Filter some events onclick onfocus.

2. Persistent XSS (Storage XSS)

Stored XSS “stores” user-input data on the server side, where scripts are returned and executed when the browser requests the data. This XSS attack is very stable.

A common scenario is that an attacker writes an article or comment on a community or forum that contains malicious JavaScript code. After the article or comment is published, all users who visit the article or comment will execute the malicious JavaScript code in their browser.

Defense strategy:

  • CSP: The browser has built-in protection against XSS. CSP is essentially a whitelist, where the developer explicitly tells the browser which external resources can be loaded and executed. We just need to configure the rules, how to intercept is up to the browser implementation. We can minimize XSS attacks in this way.

  • HttpOnly (Most effective Defense)

    Do not obtain cookies through document.cookie. Strictly speaking, HttpOnly does not prevent XSS attacks, but rather prevents cookiehijacking attacks after XSS attacks.

  • Input inspection

    Don’t trust any input from the user. Any input from the user is checked, filtered, and escaped. Creates a trusted whitelist of characters and HTML tags, and filters or encodes characters or tags that are not in the whitelist.

  • Output check

    There will be problems with the user’s input, and problems with the server’s output. In general, with the exception of rich text output, you can use encoding or escaping to defend against XSS attacks when a variable is output to an HTML page.

3. Based on DOM

Dom-based XSS attacks are client-side attacks that modify the DOM structure of a page through malicious scripts.

CSRF

Cross Site Request Forgery (CSRF) is an attack that hijacks trusted users to send unexpected requests to the server.

Under normal circumstances, CSRF attack means that the attacker uses the victim’s Cookie to win the trust of the server and sends forged requests to the attacked server in the victim’s name without the victim’s knowledge, so as to perform operations under permission protection without authorization.

Defense strategy:

You can take the following measures to defend against CSRF attacks.

  • Verification code

    Captchas are considered to be the simplest and most effective defense against CSRF attacks.

    As you can see from the examples above, CSRF attacks often construct network requests without the user’s knowledge. Captcha forces the user to interact with the application in order to complete the final request. In general, captchas are a good deterrent against CSRF attacks.

    But captcha is not a panacea, because for the sake of users, you can’t add captcha to every operation on the site. Therefore, captchas can only be used as an adjunct to CSRF defense, not as a primary solution.

  • Referer Check

    According to the HTTP protocol, there is a field in the HTTP header called Referer that records the source address of the HTTP request. With the Referer Check, you can Check whether the request is from a legitimate “source.”

  • Adding token Authentication

    The reason why CSRF attack can be successful is that the attacker can completely forge the user’s request, and all the user authentication information in the request is in the Cookie, so the attacker can directly use the user’s own Cookie to pass the security authentication without knowing the authentication information. The key to defending against CSRF is to put information in the request that an attacker 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.

Refer to the article

Web Security (XSS/CSRF) Simple Attack Principle and Defense Scheme (Theory)

Web Security (XSS/CSRF) Simple Attack Principle and Defense Scheme (Actual Combat)

Let’s talk about XSS and CSRF

Front-end Security series 1: How do I Prevent XSS attacks?

Front-end Security Series 2: How do I Prevent CSRF Attacks?