XSS

What is a XSS

Cross-site Scripting (XSS) is a code injection attack. By injecting a malicious script into the target website, the attacker makes it run on the user’s browser. Using these malicious scripts, attackers can obtain sensitive user information such as cookies and sessionIDS, thereby compromising data security.

The essence of XSS is that malicious code is unfiltered and mixed with the normal code of the site; The browser cannot tell which scripts are trusted, causing malicious scripts to be executed.

Occurrence and repair of XSS vulnerabilities

A case study

(1)

Suppose you develop a search page and determine the content of your keywords based on the URL parameters. The HTML code is as follows:

<input type="text" value="<%= getParameter("keyword") %>"> <%= getParameter("keyword") %></div>Copy the code

When a browser requests http://xxx/search? Keyword =”> This forms the following HTML:

<input type="text" value=""><script>alert('XSS'); Search "> < / script > < button > < / button > < div > you search key word is:" > < script > alert (' XSS); </script> </div>Copy the code

is malicious code, so execute it.

Not only is the contents of the div being injected, but the value property of the input is being injected, and the alert is popping twice.

In the face of this situation, how should we take precautions?

In fact, the browser simply executes the user’s input as if it were a script. Just tell the browser it’s text.

(2)

<input type="text" value="<%= escapeHTML(getParameter("keyword")) %>"> <%= escapeHTML(getParameter("keyword")) %> </div>Copy the code
function escapeHTML(text) { return text.replace(/[<>\"&\'\/]/g, function(match, pos, originalText) { switch(match) { case "<": return "&lt;" ; case ">": return "&gt;" ; case "&": return "&amp;" ; case "\"": return "&quot;" ; case "\'": return "&#x27;" ; case "/": return "&#x2F;" ; }})}Copy the code

After the escape function, the final response received by the browser is:

<input type="text" value="&quot; &gt; &lt; script&gt; alert(&#x27; XSS&#x27;) ; &lt; &#x2F; script&gt;" > <button> Search </button> <div> The keyword you search for is:" &gt; &lt; script&gt; alert(&#x27; XSS&#x27;) ; &lt; &#x2F; script&gt; </div>Copy the code

The malicious code is escaped and is no longer executed by the browser, and the search terms are perfectly displayed on the page.

Conclusion:

  • The user input contained in the page is presented as text in a fixed container or property.

  • Attackers take advantage of the user input fragments of these pages, splicing special-format strings, breaking through the limitations of the original location, forming code fragments.

  • Attackers create potential risks by injecting scripts into the target site and making them run on the user’s browser.

  • By using HTML escapes, you can prevent XSS attacks.

Note the special HTML attributes, JavaScript apis

In some cases, the code is escaped, but there is still a risk:

< a href = "< % = escapeHTML (getParameter (" redirect_to")) % > "> jump... </a>Copy the code

This code, when the attack URL is http://xxx/? Redirect_to =javascript:alert(‘XSS’);

<a href="javascript:alert(&#x27; XSS&#x27;) "> jump... </a>Copy the code

The code doesn’t execute immediately, but once the user clicks on the A TAB, the browser will pop up “XSS.”

The user’s data does not break our limitations in location and is still the correct href attribute. But the content was not what we expected.

It turns out that it’s not just special characters, javascript: can also trigger XSS attacks if they occur in certain locations.

You can solve this problem by setting the whitelist:

AllowSchemes = [" HTTP ", "HTTPS "]; allowSchemes = [" HTTP "," HTTPS "]; valid = isValid(getParameter("redirect_to"), allowSchemes); If (valid) {< a href = "< % = escapeHTML (getParameter (" redirect_to")) % > "> jump... < span style =" box-sizing: border-box; color: RGB (74, 74, 74); line-height: 22px; font-size: 14px! Important; white-space: inherit! Important;" </a> }Copy the code

Conclusion:

  • Escaping code inserted into HTML is not enough

  • For link hops, such as

Bug summary

  • In text embedded in HTML, malicious content is injected with script tags.

  • In inline JavaScript, concatenation of data breaks the original limits.

  • In tag attributes, malicious content contains quotes to break the attribute value and inject other attributes or tags.

  • In the tag href, SRC and other attributes, include javascript: and other executable code.

XSS classification

According to the source of attacks, XSS attacks can be classified into three types: storage, reflection and DOM.

Type stored XSS

Attack steps of storage XSS:

  1. The attacker submits the malicious code to the target site’s database.
  2. When the user opens the target site, the server pulls the malicious code out of the database and returns it to the browser in HTML.
  3. The user’s browser receives the response, parses it and executes the malicious code mixed in.
  4. Malicious code steals user data and sends it to the attacker’s website, or impersonates a user to invoke the target website interface to perform operations specified by the attacker.

Such attacks are common on web features with user saved data, such as forum posts, product reviews, and private messages.

Reflective XSS

The attack steps of reflective XSS:

  1. Attackers construct special urls that contain malicious code.
  2. When a user opens a URL with malicious code, the web server takes the malicious code out of the URL and returns it to the browser in HTML.
  3. The user’s browser receives the response, parses it and executes the malicious code mixed in.
  4. Malicious code steals user data and sends it to the attacker’s website, or impersonates a user to invoke the target website interface to perform operations specified by the attacker.

The difference between reflected XSS and stored XSS is that the malicious code of stored XSS is stored in the database, while the malicious code of reflected XSS is stored in the URL.

Reflective XSS vulnerabilities are commonly found in functions that pass parameters through urls, such as website search, jump, and so on.

Because the user needs to open the malicious URL to take effect, the attacker will often use a variety of methods to induce the user to click.

The DOM model XSS

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

DOM XSS attack steps:

  1. Attackers construct special urls that contain malicious code.
  2. The user opens a URL with malicious code.
  3. The user’s browser receives the response, parses it and executes it. The front-end JavaScript pulls out the malicious code in the URL and executes it.
  4. Malicious code steals user data and sends it to the attacker’s website, or impersonates a user to invoke the target website interface to perform operations specified by the attacker.

DOM XSS is different from the previous two XSS: In DOM XSS attack, the extraction and execution of malicious code is done by the browser side, which is a security vulnerability of the front-end JavaScript itself, while the other two XSS are security vulnerabilities of the server side.

Here’s an example:

<h2>XSS: </h2>
<input type="text" id="input">
<button id="btn">Submit</button>
<div id="div"></div>
<script>
    const input = document.getElementById('input');
    const btn = document.getElementById('btn');
    const div = document.getElementById('div');

    let val;
     
    input.addEventListener('change', (e) => {
        val = e.target.value;
    }, false);

    btn.addEventListener('click', () => {
        div.innerHTML = `<a href=${val}>testLink</a>`
    }, false);
</script>
Copy the code

Clicking the Submit button inserts a link to the current page with the address of the user’s input. If the user constructs the following while typing:

'' onclick=alert(/xss/)
Copy the code

After the user submits, the page code becomes:

<a href onlick="alert(/xss/)">testLink</a>
Copy the code

At this point, the user clicks on the generated link, and the corresponding script is executed:

XSS attack prevention

Prevent DOM XSS attacks

When using.innerHTML,.outerHTML, document.write(), be careful not to insert untrusted data into the page as HTML. Instead, use.textContent,.setAttribute(), etc.

If using the Vue/React technology stack, use the v – HTML/dangerouslySetInnerHTML function, can cooperate DOMPurify plugin to handle insert data.

href = location, onclick, onError, onLoad, onMouseover, etc. JavaScript eval(), setTimeout(), setInterval(), and so on can run strings as code. If untrusted data is concatenated into strings and passed to these apis, it is easy to create a security hazard and must be avoided.

<! <img onclick="UNTRUSTED" onError ="UNTRUSTED" SRC ="data:image/ PNG,"> <! -- Link contains malicious code --> <a href="UNTRUSTED">1</a> <script> // setTimeout()/setInterval() calls malicious code setTimeout("UNTRUSTED") SetInterval ("UNTRUSTED") // location calls malicious code location.href = 'UNTRUSTED' // eval() calls malicious code eval("UNTRUSTED") </script>Copy the code

Other XSS precautions

Content Security Policy

Strict CSP can play the following roles in XSS prevention:

  • The loading of external domain code is prohibited to prevent complex attack logic.
  • If the site is attacked, user data will not be leaked to the outdomain.
  • Inline script execution is prohibited (strict rule, currently found on GitHub).
  • Prohibit unauthorized script execution (new feature, Google Map Mobile).
  • Proper use of the report can discover XSS in a timely manner and help rectify problems as soon as possible.

There are two ways to enable CSP. One is through the Content-security-policy field of the HTTP header. The other is through the
tag of the web page.

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
Copy the code

Introduction to Content Security Policy

Input content length control

Any untrusted input should be limited to a reasonable length. While XSS cannot be completely prevented, it can make XSS attacks more difficult.

Other safety measures
  • Http-only Cookie: JavaScript is not allowed to read certain sensitive cookies. An attacker cannot steal this Cookie even after XSS injection is complete.
  • Verification code: prevents scripts from posing as users to submit dangerous operations.

XSS little game

CSRF

Cross-site Request Forgery (CSRF) : An attacker induces a victim to access a third-party website, and then sends a cross-site request to the attacked website. The registration certificate obtained by the victim from the attacked website is used to bypass the user authentication in the background and to impersonate a user to perform an operation on the attacked website.

A typical CSRF attack has the following process:

  • The victim logged on to a.com and retained the login credentials (cookies).
  • The attacker lured the victim to b.com.
  • B.com sent a request to a.com: a.com/act=xx
  • After receiving the request, A.com verified the request and confirmed that it was the victim’s credentials, mistaking it for the victim herself.
  • A.com was executed on behalf of the victims.
  • The attack was complete, and the attacker impersonated the victim and had the a.com perform its own defined operation without the victim’s knowledge.

Several common types of attacks

  • CSRF of the GET type

The CSRF utilization of the GET type is very simple and requires only one HTTP request. It is typically utilized like this:

<img src="http://bank.example/withdraw? amount=10000&for=hacker" >Copy the code

After the victim to visit the page containing the img, the browser will automatically to http://bank.example/withdraw? Account =xiaoming&amount=10000&for=hacker makes an HTTP request. Bank.example will receive a cross-domain request containing the victim’s login information.

  • The CSRF type is POST

This type of CSRF is usually utilized using an auto-submitted form, such as:

 <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script> 
Copy the code
  • CSRF for the link type
< a href = "http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget = "_blank" > big news!! <a/>Copy the code

Since the user logged in to the trusted website A before and saved the login status, as long as the user visits the PHP page above actively, the attack succeeds.

The characteristics of CSRF

  • The attack is usually launched on a third party site, not the site being attacked. The attacked site cannot prevent the attack from happening.

  • The attack takes advantage of the victim’s login credentials in the attacked website to submit operations as the victim; Rather than stealing data directly.

  • During the whole process, the attacker could not obtain the login credentials of the victim, but merely “fraudulently”.

  • Cross-site requests can be made in various ways: image urls, hyperlinks, CORS, Form submissions, and so on. Part of the request can be directly embedded in the third-party forums, articles, difficult to trace.

Protection strategy

Homologous detection

Since most CSRFS come from third-party sites, find a way to block requests from outlands (or untrusted domains).

In the HTTP protocol, each asynchronous request carries two headers that mark the source domain name:

  • Origin Header
  • Referer Header

These two headers are in most cases carried automatically when the browser makes a request and cannot be customized by the front end. The server can determine the source domain of the request by resolving the domain names in the two headers.

CSRF Token

A CSRF Token protection policy consists of the following steps:

1. Output the CSRF Token on the page

2. Page submitted requests carry this Token

3. The server verifies whether the Token is correct

Distributed check
Dual Cookie authentication
Samesite Cookie attribute

conclusion

Finally, a summary of common defenses against XSS and CSRF attacks:

Defend against XSS attacks

  • HttpOnly Prevents Cookie hijacking
  • Check the user’s input
  • Check the output of the server

Defend against CSRF attacks

  • Verification code
  • Referer Check
  • Token authentication

Refer to the article

# Front-end Security Series (I) : How to prevent XSS attacks?

# Front-end Security Series 2: How to prevent CSRF attacks?

XSS and CSRF