XSS attacks

Cross-site Scripting (XSS) is a code injection attack. The attacker injects malicious scripts on the target website to run on the user’s browser. Using these malicious scripts, attackers can obtain sensitive user information such as cookies and sessionIDS, thus compromising data security.

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

In what way does the user “inject” the malicious script?

Not only the “user’s UGC content” on the business can be injected, but also the parameters on the URL can be the source of attack. None of the following can be trusted when processing input:

• UGC information from the user
• Links from third parties
• The URL parameter
• POST parameters
• Referer (possibly from an untrusted source)
• Cookies (possibly injected from other subdomains)

Hazards of XSS attacks

1. Steal all kinds of user accounts, such as machine login account, user network bank account, all kinds of administrator account
2. Control of enterprise data, including the ability to read, modify, add, and delete sensitive enterprise data
3. Stealing important data of commercial value from the enterprise
4. Illegal transfer
5. Force E-mail to be sent
6. Website hang a horse
7. Control the victim’s machine to launch attacks on other sites

XSS vulnerability classification

According to the attack sources, XSS attacks can be classified into storage, reflection and DOM attacks.

Type stored XSS

Storage XSS attack steps:

1. The attacker submits malicious code to the database of the target website.
2. When the user opens the target website, the website server takes the malicious code out of the database, splices it into HTML and returns it to the browser.
3. When the user’s browser receives the response, it 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 the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

This kind of attack is common in website functions with user-saved data, such as forum posts, product reviews, and user messages.

Reflective XSS

Attack steps of reflective XSS:

1. The attacker constructs a special URL that contains malicious code.
2. When a user opens a URL with malicious code, the web server takes the malicious code out of the URL, splices it into HTML and returns it to the browser.
3. When the user’s browser receives the response, it 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 the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

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

Reflective XSS vulnerabilities are common in functions that pass parameters through urls, such as website search, jump, etc.

Because users need to take the initiative to open malicious URL to take effect, attackers often combine a variety of means to induce users to click.

Reflective XSS can also be triggered by the contents of a POST, but the trigger condition is more stringent (the form submission page needs to be constructed and the user is directed to click), so it is very rare.

The DOM model XSS

DOM XSS attack steps:

1. The attacker constructs a special URL that contains malicious code.
2. The user opens a URL with malicious code.
3. When the user’s browser receives the response, it parses it and executes it. The front-end JavaScript picks up 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 the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

DOM XSS differs from the previous two types of XSS: DOM XSS attacks, in which malicious code is extracted and executed by the browser side, are security vulnerabilities of the front-end JavaScript itself, while the other two types of XSS are security vulnerabilities of the server side.

The prevention of

1. Input filtering. XSS attacks can not be completely avoided, but also introduce great uncertainty and garble problems. Clear input types, such as numbers, URLS, phone numbers, email addresses, etc., are necessary for input filtering.
2. Pure front-end rendering:

• The browser first loads a static HTML that does not contain any business-related data.
• The browser then executes the JavaScript in the HTML.
• JavaScript loads the business data through Ajax and calls the DOM API to update it to the page.

1. Fully escape HTML.
2. When concatenating strings, it is important to avoid concatenating untrusted data.
3. Control the length of input.
4. Http-only Cookie: Disables JavaScript from reading certain sensitive cookies. Attackers cannot steal these cookies after XSS injection.
5. Strict CSP can play the following roles in XSS prevention:

• Prohibit loading outfield code to prevent complex attack logic.
• Prohibit submission from the outdomain. After a website is attacked, user data will not be leaked to the outdomain.
• Forbid inline script execution (strict rules, currently found to be used on GitHub).
• Disable unauthorized script execution (new feature, in use with Google Map Mobile).
• Proper use of reports can discover XSS in a timely manner, which helps to rectify problems as soon as possible.

CSRF attacks

What is a CSRF

Cross-site Requist Forgery (CSRF) : An attacker induces the victim to access a third-party website and sends a request to the attacked website. Using the victim in the attacked website has obtained the registration credentials, bypassing the background user authentication, to achieve the purpose of impersonating the user to perform a certain operation on the attacked website.

The following is a typical CSRF attack flow:

1. The victim logged in to a.com and retained the login credentials (cookies) of WEBSITE A.
2. The attacker directs the victim to b.com
3. B.com sends a request to B.com with the victim’s cookie.
4. After a.com receives the request, it verifies the request and verifies that it is the victim.
5. Attack complete, the attacker in the victim’s knowledge, posing as a victim, to the A.com attack.

Several common types of CSRF attacks

• CSRF of the GET type

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

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

After the victim accessed the page containing this IMG, The browser will automatically to [http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker] (HTTP: / / http://bank.example/withdraw? Account =xiaoming&amount=10000&for=hacker) sends an HTTP request. Bank.example will receive a cross-domain request containing the victim’s login information.

• CSRF of the POST type

This type of CSRF is typically exploited 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

When you visit the page, the form is automatically submitted, simulating a POST operation.

Post-type attacks are generally a little more stringent than GET, but still not complex. Any personal website, blog, website uploaded by hackers may be the source of attacks, back-end interface can not rely on the security of POST only above.

• CSRF of link type

Link-type CSRFS are uncommon and require the user to click a link to trigger them, compared to the other two cases where the user opens the page and is caught. This type usually involves embedding malicious links in the pictures published in the forum, or inducing users to be lured in the form of advertisements. Attackers usually trick users into clicking with exaggerated words, such as:

< 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 and saved the login status, as long as the user actively accessed the above PHP page, the attack was successful.

The characteristics of CSRF

• Attacks are generally launched on third party sites, not the site being attacked. The attacked site cannot prevent the attack from happening.
• Instead of stealing data, the attack uses the victim’s login credentials on the targeted site to impersonate the victim to submit the action.
• The attacker can’t get the victim’s login credentials during the whole process, just “fake it”.
• Cross-site requests can be made in a variety of ways: image urls, hyperlinks, CORS, Form submissions, etc. Some requests can be directly embedded in third-party forums and articles, which are difficult to track.

CSRF is typically cross-domain because outdomains are usually more easily controlled by attackers. However, if there are easily exploited functions in the local domain, such as forums and comment areas for Posting pictures and links, the attack can be carried out directly in the local domain, and this attack is more dangerous.

Protection strategy

CSRF is usually launched from third-party websites. Attacked websites cannot prevent attacks, but can only enhance their own protection against CSRF to improve security.

The above mentioned two characteristics of CSRF are described:

• CSRF (usually) occurs in third party domain names.
• CSRF attackers cannot obtain information such as cookies, but only use.

In view of these two points, we can formulate special protection strategies as follows:

• Block access to unknown outfields

• Homologous detection

• Samesite Cookie (poor browser support)

• Submit by asking for additional information that is available only to the local domain

• CSRF Token

• Double Cookie authentication

The following is a detailed description of various protection methods:

The same-origin policy

In HTTP, each asynchronous request carries two headers, which mark the domain name of the source:

• Origin Header
• Referer Header

These two headers are carried automatically in most cases when the browser makes a request, and the content 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.

The Referer Header is not foolproof. 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. The method of verifying the Referer value relies on the security of a third party (i.e. the browser), which in theory is not very secure. In some cases, attackers can hide or even modify the Referer of their own requests

There are three ways to set the Referrer Policy:

1. In the CSP setting
2. Add meta tags to the header of the page
3. A tag adds the referrerPolicy attribute

This is a lot, but we can see one problem: attackers can hide referers in their requests. If the attacker filled out his request like this:

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

Then the attack initiated by this request will not carry the Referer.

In addition, Referer is not or cannot be trusted in the following cases:

1. In IE6 and IE7, when window.location.href= URL is used to jump to the interface, the Referer will be lost.

2. When Windows. Open is used in IE6 and IE7, Referer will also be missing.

3. When the HTTPS page is switched to the HTTP page, the Referer of all browsers is lost.

4. When clicking Flash to reach another website, the Referer’s situation is messy and not credible.

CSRF Token

1. Output the CSRF Token to the page

First of all, when the user opens the page, the server needs to generate a Token for the user, which encrypts the data through an encryption algorithm. Generally, the Token contains a combination of random string and time stamp. Obviously, the Token cannot be put in the Cookie when submitting, otherwise it will be used by attackers. Therefore, for the sake of security, it is better to keep the Token in the server’s Session, then use JS to traverse the whole DOM tree every time the page loads, and add the Token for 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.

2. The request submitted by the page carries this Token

For GET requests, the Token is appended to the request address so that the URL becomes http://url? Csrftoken = tokenvalue. For POST requests, the form ends with:

< input type = "hidden" name = "tokenvalue csrftoken" value = "" / >Copy the code

This adds the Token to the request as a parameter.

3. The server verifies the Token

When a user obtains a Token from the client and submits it to the server again, the server needs to determine the validity of the Token by decrypting the Token and comparing the encrypted string with the timestamp. If the encrypted string is consistent and the time has not expired, the Token is valid.

Distributed check

Using sessions to store CSRF tokens can be stressful on large sites. The session for accessing a single server is the same. However, in today’s large websites, we usually have more than one server, maybe dozens or even hundreds of servers, and even multiple computer rooms may be in different provinces. HTTP requests initiated by users are usually routed to specific servers after load balancers such as Ngnix. By default, sessions are stored in the memory of a single server. Therefore, in a distributed environment, multiple HTTP requests sent by the same user may be sent to different servers successively. As a result, subsequent HTTP requests cannot get the Session data stored in the server of the previous HTTP requests. Therefore, the Session mechanism is invalid in a distributed environment. Therefore, CSRF tokens need to be stored in a public storage space such as Redis in a distributed cluster.

As Session storage is used, reading and verifying CSRF tokens will cause relatively large complexity and performance problems. Currently, many websites adopt Encrypted Token Pattern mode. The Token of this approach is a calculated result, not a randomly generated string. In this way, there is no need to read the stored Token during verification, but only need to calculate the Token again.

The Token value is usually generated by encryption using a UserID, timestamp, and random number. This ensures that the tokens of distributed services are consistent and that the tokens are not easy to crack.

After the token is decrypted successfully, the server can access the resolved value, and the UserID and timestamp contained in the token will be used to verify the validity, comparing the UserID with the currently logged UserID, and comparing the timestamp with the current time.

conclusion

Token is a relatively effective CSRF defense method. As long as the page does not have XSS vulnerability to expose the Token, the CSRF attack on the interface will not succeed.

However, the implementation of this method is complicated. It needs to write a Token to every page (pure static pages cannot be used in the front end). Every Form and Ajax request carries this Token, and the back end verifies every interface to ensure that the page Token and request Token are consistent. This prevents the protection policy from being uniform across common interceptions, requiring output and validation for each page and interface. This method is a lot of work and can be missed

Double Cookie authentication

Storing CSRF tokens in a session is cumbersome, and all interfaces cannot be handled uniformly on a common interception.

Another defense is to use double-commit cookies. Taking advantage of the fact that CSRF attacks cannot retrieve user cookies, we can require Ajax and form requests to carry a value from a Cookie.

Double Cookie uses the following process:

• When a user visits a web page, a Cookie is injected into the requested domain name with a random string of content (e.gcsrfcookie=v8g9e4ksfhw).
• When the front end makes a request to the back end, the Cookie is fetched and added to the parameters of the URL (following example)POST [https://www.a.com/comment?csrfcookie=v8g9e4ksfhw](https://www.a.com/comment?csrfcookie=v8g9e4ksfhw)).
• The back-end interface verifies whether the fields in the Cookie are consistent with those in the URL parameter, and rejects any inconsistency.

This method is much simpler than the CSRF Token. It can be automated directly through the method of front and back end interception. Backend verification is also more convenient, requiring only the comparison of fields in the request without the need to query and store tokens.

Of course, this method has not been applied on a large scale, and its security on large websites is still not as high as that of CSRF Token. The reasons are illustrated by examples.

Since any cross-domain will cause the front end to be unable to get the fields in the Cookie (including between subdomains), the following happens:

• If the website accessed by the user iswww.a.com, the back-end API domain name isapi.a.com. So in thewww.a.comDown, no front endapi.a.comIs unable to complete double Cookie authentication.
• So the authentication Cookie must be planteda.comSo that each subdomain can be accessed.
• Any subfield can be modifieda.comThe cookies.
• A subdomain is vulnerable to XSS attacks (e.gupload.a.com). Although there is nothing worth stealing in this subdomain. But the attacker modified ita.comThe cookies.
• The attacker can directly use the cookies configured by himself to redirect the targeted users in XSSwww.a.comUnder, launch CSRF attacks.

conclusion

Advantages of using dual cookies to defend against CSRF:

• No need to use Session, more widely applicable, easy to implement.
• The Token is stored in the client and does not put pressure on the server.
• Compared with Token, the implementation cost is lower, and the verification can be uniformly intercepted at the front and back ends without the need to add interfaces and pages one by one.

Disadvantages:

• Additional fields are added to cookies.
• If there are other vulnerabilities (such as XSS) where the attacker can inject cookies, this defense fails.
• Isolation of subdomains is difficult.
• In order to ensure the security of Cookie transmission, it is best to use this defense mode to ensure that the whole site HTTPS mode is used. If HTTPS is not used, this mode may also be risky.

Samesite Cookie attribute

Prevent the site from being exploited

What is said in front is how to protect the websites that are attacked. Instead of preventing attacks, CSRF attacks can come from:

• The attacker’s own website.
• Have file upload bug site.
• Third party forums and other user content.
• The attacked website’s own comment function.

We can’t defend websites from hackers themselves. But in other cases, how do you prevent your website from being used as a source of attack?

• Strictly manage all upload interfaces to prevent any unexpected uploads (such as HTML).
• Add the HeaderX-Content-Type-Options: nosniffPrevent resources (such as images) that hackers upload HTML content from being parsed into web pages.
• For pictures uploaded by users, it can be saved or verified. Do not directly use the image link that the user fills in.
• Current users need to be notified of the risks when opening links filled in by other users (this is one of the reasons many forums don’t allow outland links to be posted directly in their content, not just for retention but also for security reasons).