CSRF attack and defense

What is a CSRF

Cross-site Request Forgery (CSRF) : An attacker induces the victim to access a third-party website and sends cross-site request to the attacked website. Using the victim in the attacked website has obtained the registration certificate, bypassing the background user authentication, to impersonate the user to perform a certain operation on the attacked website.

A typical CSRF attack has the following flow:

• Victims log on to the website and retain their login credentials (cookies).
• The attacker lured the victim to visit b.com.
• B.com sent a request to a.com: a.com/act=xx. Browsers carry cookies from A.com by default.
• When a.com received the request, it verified it and confirmed that it was the victim’s credentials, mistaking it as a request sent by the victim himself.
• A.com enforced act= XX on behalf of the victims.
• When the attack is complete, the attacker impersonates the victim without the victim’s knowledge and allows a.com to perform its own defined operation.

Several common types of attacks

CSRF of the GET type

All you need is an HTTP request, and when the victim visits the page that contains the IMG, the browser automatically sends an HTTP request to the attacker’s site. The attacker’s web site receives 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"Word-wrap: break-word! Important; "> <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.
• Attack using the victim’s login credentials in the attacked website, posing as the victim to submit operations; Instead of stealing data directly.
• The attacker can not obtain the login credentials of the victim during the whole process, just “fake”.
• Cross-site requests can be made in a variety of ways: image urls, hyperlinks, CORS, Form submissions, and more. Part of the request can be directly embedded in third-party forums, articles, 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
• Submit by asking for additional information that is available only to the local domain
  • CSRF Token
  • Double Cookie authentication

Below we do a detailed description of the various protection methods.

Homologous detection

Since most CSRFS come from third-party sites, we simply forbid outlands (or untrusted domain names) from making requests to us.

So how do we know if the request is coming from outdomain?

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.

Use the Origin Header to determine the source domain name

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

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. The most fundamental reason is that the definition of same-origin in Internet Explorer 11 is different from that in other browsers. There are two major differences, please refer to MDN SAME-origin_policy #IE_Exceptions

• 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.

Use the Referer Header to identify the source domain name

According to the HTTP protocol, there is a field in the HTTP header called Referer that records the source address of the HTTP request. For Ajax requests, images, and script resource requests, Referer is the page address that initiates the request. For page jumps, Referer is the address of the previous page that opened the page history. Therefore, we use the Origin section of the link in the Referer to get the source domain name of the request.

This method is not foolproof, the Referer value is provided by the browser, although HTTP protocol has clear requirements, but each browser for the specific implementation of the Referer may be different, there is no guarantee that the browser itself does not have 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.

In 2014, the W3C’s Web Application Security Working Group published a draft Referrer Policy that specifies in detail how browsers should send referers. Now that most of the newer browsers support this draft, we finally have the flexibility to control the Referer policy for our sites. The new Referrer Policy specifies five Referer policies: No Referrer, No Referrer When downgraded, Origin Only, Origin When cross-origin, and Unsafe URL. Three pre-existing policies, never, Default, and always, have been renamed. Their correspondence is as follows:

According to the table above, the Referrer Policy should be set to same-origin. For same-origin links and references, the Referer will be sent with the value of Host without Path. Cross-domain access does not carry Referer. For example: Aaa.com references bbb.com resources and does not send Referer.

There are three ways to set the Referrer Policy:

• In the CSP setting
• Add meta tags to the header of the page
• A tag adds the referrerPolicy attribute

This is a lot, but we can see one problem: attackers can hide referers in their requests. 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:

• In IE6 and IE7, when window.location.href= URL is used to jump the interface, the Referer will be lost.
• When Windows. Open is used in IE6 and IE7, the Referer will also be missing.
• When the HTTPS page jumps to the HTTP page, all the browser referers are lost.
• When you click on Flash to get to another site, Referer’s situation is messy and unreliable.

The source domain name situation could not be confirmed

What happens when 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.

How do I block outfield requests

Through Header verification, we can know the source domain name of the request, which may be the site’s own domain, or a sub-domain, or an authorized third party domain name, or from an untrusted unknown domain name.

We already know if the requested domain name is from an untrusted domain name, can we prevent CSRF attacks by simply blocking these requests?

Wait a minute! When a request is a page request (such as the homepage of a website) and the source is a link from a search engine (such as baidu search results), it can also be considered as a suspected CSRF attack. Therefore, you need to filter out the page request when judging. Usually, the Header meets the following conditions:

Accept: text/ HTML Method: GET However, page requests are exposed to CSRF attacks. If your site does something to the current user in a GET request on the page, the defense will fail.

For example, the following page request:

The GET example.com/addComment?… Note: This is not strictly a risk of CSRF attacks, but there are still many sites that often implement product features by putting parameters on main document GET requests, but doing so is a security risk of its own.

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.

To sum up: Homologous authentication is a relatively simple defense method that can prevent the vast majority of CSRF attacks. But it’s not foolproof. For sites with high security requirements or a lot of user input, we need to put extra safeguards on key interfaces.

CSRF Token

Another feature of CSRF mentioned above is that attackers cannot directly steal the user’s information (cookies, headers, website content, etc.), but only use the information in cookies.

The CSRF attack succeeds because the server mistook the request sent by the attacker for the user’s own request. Then we can require all user requests to carry a Token that a CSRF attacker cannot obtain. By verifying whether the request carries the correct Token, the server can distinguish the normal request from the attack request and defend against CSRF attacks.

The principle of

The CSRF Token defense policy consists of three steps:

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.

This method is a bit safer than checking Referer or Origin before. Tokens can be generated and placed in the Session, and then taken out of the Session on each request and compared with the tokens in the request. The trickier part of this approach, however, is how to add tokens to the request as parameters.

The Token value must be randomly generated, so that it will not be an attacker to guess, consider using a Java application Java. Security. SecureRandom class to generate random long enough tags, alternative generation algorithm including the use of a 256 – bit BASE64 encoding hash, Developers who choose this generation algorithm must ensure that randomness and uniqueness are used in the hash data to generate random identifiers. Typically, developers only need to generate tokens once for the current session. After the initial generation of this Token, the value is stored in the session and used for each subsequent request until the session expires. When an end user makes a request, the server side must verify the existence and validity of the Token in the request against the Token found in the session. If the Token is not found in the request, or the value provided does not match the value in the session, the request should be aborted, the Token should be reset and the event logged as a potential CSRF attack in progress.

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.

Captcha and password can also act as a CSRF Token, which is more secure.

Why do many banks and other websites require users who have logged in to re-enter their passwords when transferring money? Is it reasonable now?

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 with a random string of content (for example, cSRFcookie =v8g9e4ksfhw). When the front end sends a request to the back end, the Cookie is fetched and added to the PARAMETERS of the URL (following example POST www.a.com/comment?csr… 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 user accesses the website www.a.com, the back-end API domain name is api.a.com. So in www.a.com, the front end can not get the Cookie of API.a.com, it can not complete double Cookie authentication.

The authentication Cookie must then be planted under a.com so that each subdomain can access it. Any subdomain can modify the cookies under a.com.

A subdomain has been attacked by XSS (for example, upload.a.com). Although there is nothing worth stealing in this subdomain. But the attacker modified the cookies under a.com. Attackers can directly use their own cookies to launch CSRF attacks against users caught in XSS to www.a.com.

Conclusion:

Advantages of dual Cookie defense 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

The way to prevent CSRF attacks already has the above precautions. In order to solve this problem at the source, Google drafted a draft to improve the HTTP protocol, that is, to add the Samesite attribute to the set-cookie response header, which is used to indicate that the Cookie is a “peer Cookie”, and the peer Cookie can only be used as a first-party Cookie. It cannot be used as a third-party Cookie. Samesite has two property values, Strict and Lax, explained below:

Samesite=Strict

This mode, called strict mode, indicates that the Cookie cannot be used as a third-party Cookie under any circumstances, without exception. For example, b.com sets the following Cookie:

Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
Copy the code

When we make any request to b.com under a.com, the Cookie foo will not be included in the Cookie request header, but bar will. For example, if the Cookie used by Taobao website to identify whether users log in or not is set to Samesite=Strict, then after users click on the link of Baidu search page or even Tmall page to enter Taobao, Taobao will not be logged in, because Taobao’s server will not accept that Cookie. Any request to Taobao from other websites will not carry the Cookie.

Samesite=Lax

This is called loose mode and is a bit more restrictive than Strict: if the request is one of these (changes the current page or opens a new page) and is also a GET request, the Cookie can be used as a third-party Cookie. For example, b.com sets the following Cookie:

Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
Copy the code

When a user clicks a link from a.com to b.com, the Cookie foo will not be included in the Cookie request header, but bar and Baz will. In other words, the user will not be affected by the link between different websites. However, bar will not send the request if it is an asynchronous request to B.com from a.com, or if the page jump is triggered by a POST submission of the form.

The Samesite that generates the Token to put in the Cookie and sets the Cookie

How should we use SamesiteCookie

If the SamesiteCookie is set to Strict, the browser does not carry cookies in any cross-domain requests, nor does a new tag reopen, so CSRF attacks have little chance.

But jump the rotor domain name or a new TAB to reopen the site just logged in, the previous Cookie will not exist. In particular, there are login websites, so we open a new label to enter, or jump to the sub-domain site, need to log in again. For users, the experience may not be very good.

If SamesiteCookie is set to Lax, other web sites can use cookies when they jump to the page, ensuring the login status of the user when the page is opened from the outer domain connection. But correspondingly, its security is also relatively low.

Another problem is that Samesite is not very compatible. Currently, Safari and iOS Safari are not supported except for the new Chrome and Firefox versions, so it is not widely available at this stage.

Also, SamesiteCookie currently has a fatal flaw: it does not support subdomains. For example, a Cookie planted under Topic.a.com cannot use a SamesiteCookie planted under A.com. This results in the inability to use SamesiteCookie to store user login information in the main domain when our site has multiple subdomains. Each subdomain requires the user to log in again.

In conclusion, SamesiteCookie is a possible alternative to homologous authentication, but it is not yet mature and its application scenario remains to be seen.

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 Header x-Content-type-options: Nosniffing Prevents HTML resources (such as images) uploaded by hackers from being parsed as 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).

CSRF Other precautions

For programmers on the front line, we can defend against CSRF through various protection strategies. For QA, SRE, security leaders, etc., what can we do to improve security?

CSRF test

CSRFTester is a CSRF vulnerability test tool, the test principle of CSRFTester tool is probably like this, use proxy capture we have visited in the browser all connections and all forms and other information, by modifying the corresponding form in CSRFTester information, resubmit, It is equivalent to a forged client request. If the modified test request is successfully accepted by the website server, it indicates the existence of CSRF vulnerability. Of course, this tool can also be used to carry out CSRF attacks. CSRFTester use method roughly divided into the following steps:

Step 1: Set the browser proxy

CSRFTester defaults to using port 8008 on Localhost as its proxy, and if the proxy is successfully configured, CSRFTester will generate debug messages for all subsequent HTTP requests generated by your browser.

Step 2: Access the site with a legitimate account to start testing

We need to find a specific business Web page that we want to test for CSRF. After finding this page, select the “Start Recording” button in CSRFTester and perform the business function; When done, click the “Stop Recording” button in CSRFTester; Normally, the software will go through all requests for the current page.

Step 3: Modify and forge the request through CSRF

We then see a series of record requests running out of the software, all the GET or POST requests that our browser made while performing a business function. By selecting a row in the list, we can now modify the parameters used to perform the business function, and we can modify the query and form parameters by clicking on the corresponding request. When we have modified all the values we want to induce the user to submit for the form, we can choose to start generating the HTML report.

Step 4: Get the results and fix any bugs

You must first select Report Type. The report type determines how we want the victim’s browser to submit requests for previous records. There are currently five possible reports: forms, iFrame, IMG, XHR, and links. Once the report type is selected, we can choose to launch the newly generated report in the browser, and finally conduct troubleshooting and repair according to the report situation.

CSRF monitoring

For a complex web site system, it is likely that some items, pages, and interfaces will miss CSRF safeguards.

Once CSRF attacks occur, how do we detect them in a timely manner?

CSRF attack has obvious characteristics:

• Cross-domain request.
• The MIME type of the GET request Header is probably an image, but the ACTUAL MIME type of the return Header is Text, JSON, or HTML.

We can monitor all interface requests at the proxy layer of the site, and if the request matches the above characteristics, we can consider the request as a CSRF attack suspect. We can remind corresponding page and project leaders to Review or Review their CSRF protection policies.

Recommendations for individual user CSRF security

Frequent Internet users can use the following methods to protect themselves:

• Using the web version of email to read emails or news also poses an additional risk, as checking emails or news messages can lead to malicious code attacks.
• Try not to open suspicious links, and be sure to open them with an infrequently used browser.

conclusion

A brief summary of the above protection strategies:

• CSRF automatic defense policy: Origin detection (Origin and Referer verification).
• CSRF active defense measures: Token authentication or double Cookie authentication and Samesite cookies.
• Keep the page idempotent, and the backend interface does not do user operations in the GET page.

In order to better defend against CSRF, the best practice is to consider the advantages and disadvantages of the defense measures summarized above and make appropriate choices based on the current situation of the Web application to better prevent THE occurrence of CSRF.

Case history

CSRF vulnerability in WordPress

In March 2012, WordPress discovered a CSRF vulnerability that affected version 3.3.1 of WordPress, the popular blogging platform, and allowed an attacker to change the title of a Post, add users with administrative rights, and manipulate user accounts. Including but not limited to deleting comments, modifying profile pictures, etc. The specific list is as follows:

Add Admin/User Delete Admin/User Approve comment Unapprove comment Delete comment Change background image Insert custom Header image Change site title Change administrator’s email Change WordPress Address Change site Address So this vulnerability actually means that the attacker guides the user to enter the target WordPress first, and then clicks a button on the phishing site. The button is actually a form submission button, which will trigger the submission of the form and add a user with administrator rights. The code is as follows:

<html> 
<body onload="javascript:document.forms[0].submit()"> 
<H2>CSRF Exploit to add Administrator</H2> 
<form method="POST" name="form0" action="http://<wordpress_ip>:80/wp-admin/user-new.php"> 
<input type="hidden" name="action" value="createuser"/> 
<input type="hidden" name="_wpnonce_create-user" value="<sniffed_value>"/> 
<input type="hidden" name="_wp_http_referer" value="%2Fwordpress%2Fwp-admin%2Fuser-new.php"/> 
<input type="hidden" name="user_login" value="admin2"/> 
<input type="hidden" name="email" value="[email protected]"/> 
<input type="hidden" name="first_name" value="[email protected]"/> 
<input type="hidden" name="last_name" value=""/> 
<input type="hidden" name="url" value=""/> 
<input type="hidden" name="pass1" value="password"/> 
<input type="hidden" name="pass2" value="password"/> 
<input type="hidden" name="role" value="administrator"/> 
<input type="hidden" name="createuser" value="Add+New+User+"/> 
</form> 
</body> 
</html> 
Copy the code

CSRF vulnerability in YouTube

In 2008, security researchers found CSRF vulnerabilities in almost every action a user can perform on YouTube. If the attacker has added the video to the user’s “Favorites,” he can add himself to the user’s “Friend” or “Family” list, send arbitrary messages as the user, mark the video as undesirable, and automatically share a video with the user’s contacts. For example, to add a video to a user’s “Favorites,” an attacker would simply embed an IMG tag like this on any site:

<img src="http://youtube.com/watch_ajax?action_add_favorite_playlist=1&video_
id=[VIDEO ID]&playlist_id=&add_to_favorite=1&show=1&button=AddvideoasFavorite"/>
Copy the code

Attackers may have exploited the vulnerability to increase the popularity of videos. For example, if you add a video to enough users’ Favorites, YouTube will display it as Top Favorites. In addition to increasing the popularity of a video, attackers can cause users to unwittingly flag a video as “inappropriate,” which can cause YouTube to remove it.

The attacks may also have been used to violate users’ privacy. YouTube allows users to restrict certain videos to friends or relatives. These attacks cause attackers to add it to a user’s ‘Friend’ or ‘Family’ list, which gives them access to all private videos that would otherwise be restricted to users in their friends and relatives lists.

An attacker can also share a video through a user’s entire contact list (” Friends, “” Family,” etc.). “Sharing” means sending them a link to a video, with the option of additional messages. The link in the message was no longer a video link, but a link to an offensive website that users were likely to click on, allowing the attack to go viral.

Related articles

How do I prevent CSRF attacks?