Cross Site Request Forgery, or CSRF, is an attack that occurs when a malicious site, letter, message, application, or anything else forces a user's browser to perform some action on another site where that user is already authenticated. This often happens without the knowledge of the user.
The damage from a CSRF attack depends on the site taking the action. Here's an example:
- Bob logs into his personal account in the online banking client, performs some operations, but does not log out.
- Bob checks his mail and clicks a link to an unfamiliar site.
- An unknown site makes a request to the online client of Bob's bank to transfer money, passing information in Bob's cookie, preserved from his previous session.
- Bank site Bob accepts a request from an unknown (malicious) site without using a CSRF token and performs the translation.
Even more interesting is the situation when a link to a malicious
the site can be contained in valid HTML, thanks to which Bo-
you don't even have to click on the link: ... If Bob's device (such as a browser) renders
If this image is attached, it will make a request to malicious_site.com and potentially commit a CSRF attack.
Now, knowing the dangers of CSRF attacks, you can defend against them in many ways, the most popular of which is perhaps the use of a CSRF token, which should be sent with any request that could potentially change data (for example, with POST requests ). A web application (such as Bob's online bank) will need to generate a token in two parts, one of which Bob gets and the other is stored in the application.
When Bob tries to make a money transfer request, he will have to send a token, which will be verified by the bank for validity using the token stored in the application.
Now that we know about CSRF and CSRF tokens, Cross Origin Resource Sharing (CORS) becomes clearer, although perhaps I just noticed it as I researched new targets. In general, CORS limits the list of resources that can access data. In other words, when CORS is used to secure a site, you can write Javascript to call the target application, read the response, and make another call if the target site allows you.
If this seems confusing, try using Javascript to make a call to HackerOne.com/activity.json, read the response, and make a second call. You will also see the importance of this and potential workarounds in example # 3 below.
Finally, it's important to note (thanks to Jobert Abma for pointing this out at this point) that not every request without a CSRF token is invalid. Some sites may perform additional checks, such as comparing the outgoing side header (although this is not a guarantee of security and there are known workarounds). This is a field that identifies the address of the page that links to the requested resource. In other words, if the outgoing side (referrer)
makes a POST call from a site other than the same site that received the HTTP request, the site may not allow the call to achieve the same effect as achieved using the CSRF token. Also, not every site uses the term csrf when creating or defining a token. For example, on Badoo, this is the rt parameter, as described below.
Read the OWASP Testing for CSRF Testing Guide
Examples of
1. Export installed Shopify users
Difficulty: Low
Url: https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users
Description:
The Shopify API provides an endpoint for exporting a list of installed users via the URL shown above. The vulnerability was that the site could make a request to this endpoint and receive information in response, because
Shopify did not use a CSRF token to validate this request. As a result, the following HTML code could be used to submit a form on behalf of an unsuspecting victim.
1 2
9
In this example, on a simple visit to the page, Javascript submits a form that includes a GET request to the Shopify API using the Shopify cookies set on the victim's browser.
conclusions
Scale up your attacks and look for bugs not only on the website, but also in the API. API endpoints are also a potential playground for vulnerabilities, so it's worth keeping this in mind, especially if you know the API may have been developed or made available after the web interface was created.
2. Disconnecting Shopify from Twitter
Difficulty: Low
Url: https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect
Shopify provides Twitter integration that allows store owners to tweet about their products. Likewise, the service allows and disconnects the Twitter account from the associated store.
The URL to disconnect your Twitter account from the store is listed above. When making a request, Shopify did not validate the CSRF token, which allowed an attacker to create a fake link, clicking on which would lead an unsuspecting store owner to disconnect their store from Twitter.
Describing the vulnerability, WeSecureApp provided the following example of a vulnerable request, note that using the img tag makes a call to the vulnerable URL:
1 GET / auth / twitter / disconnect HTTP / 1.1 2 Host: twitter-commerce.shopifyapps.com 3 User-Agent: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10.1 4 1; rv: 43.0) Gecko / 20100101 Firefox / 43.0 5 Accept: text / html, application / xhtml + xml, application / x 6 ml 7 Accept-Language: en-US, en; q = 0.5 8 Accept-Encoding: gzip, deflate 9 Referer: https: // twitter-commerce .shopifyapps.com / accou 10 nt 11 Cookie: _twitter-commerce_session = REDACTED 12> Connection: keep-alive
Since the browser makes a GET request to get the image from the passed URL and the CSRF token is not validated, the custom store is now disabled:
1 2
36
conclusions
In this situation, the described vulnerability could be found when using a proxy server such as Burp or Firefox Tamper Data, it was enough to look at the request sent to Shopify and see that this request was made using a GET request. Since this was destructive and GET requests should not change the data to the server, this is worth investigating.
3. Complete takeover of the Badoo account
Difficulty: Medium
Url: https://badoo.com
Report link: https://hackerone.com/reports/12770312
Reported date: April 1, 2016
Bounty Paid: $ 852
Description:
If you take a look at Badoo, you can see that they are protected from CSRF by including the rt parameter in the URL, which is only 5 characters long (at least at the time of writing). Although I noticed this when Badoo launched a campaign on HackerOne, I couldn't find a way to use it. However, Mahmoud Jamal (zombiehelp54) found it.
After realizing the meaning of the rt parameter, he also noticed that the parameter was returned in almost all json responses. Unfortunately, it didn't do much good as CORS protects Badoo from attacks by reading these answers. Mahmoud continued to search.
It turned out that the file https://eu1.badoo.com/worker-scope/chrome-ser contains the rt value. Better yet, this file
could be read arbitrarily by the attacker and did not require
victims take no action other than visiting a malicious web page. Here is the code he provided:
1 2
3Basically, when the victim loaded the page, they made a request to the Badoo script, took the rt parameter for that user, and then made the request on behalf of the victim. In this case, it was linking Mahmoud's account with the victim's account, which allowed for a complete takeover of the account.
conclusions
Where there is smoke, there is fire. Here Mahmoud noticed that the rt parameter was returned in different places, in specific json responses. So he correctly assumed that it might be shown somewhere where it could be used in this case in a js file.
Outcomes
CSRF attacks represent another dangerous vector for attacks and can be carried out without active action on the part of the victim or even without his notification. Finding CSRF vulnerabilities requires some ingenuity and, again, willingness to test everything.
Typically, forms are protected by default frameworks like Rails if the site makes a POST request, but APIs can
be a separate story. For example, Shopify is written primarily based on the Ruby on Rails framework, which provides CSRF protection for all forms by default (although it can be disabled). However, it is clear that this is not necessarily the case for APIs built with this framework. Finally, look out for calls that change data on the server (such as a delete action) and are made with a GET request.
ASP.NET MVC is not the most hype, but rather popular stack among web developers. From an (anti) hacker's perspective, its standard functionality gives you some basic security, but extra protection is needed to guard against the vast majority of hacker tricks. In this article, we'll go over the basics that an ASP.NET developer (be it Core, MVC, MVC Razor, or Web Forms) should know about security.
Let's start with all known types of attacks.
SQL Injection
Oddly enough, but in 2017, injection and, in particular, SQL injection are in the first place among the "Top 10 OWASP security risks" (Open Web Application Security Project). This type of attack implies that the data entered by the user is used on the server side as query parameters.
The example of classic SQL injection is more typical for Web Forms applications. Using parameters as query values helps protect against attacks:
String commandText = "UPDATE Users SET Status = 1 WHERE CustomerID = @ID;"; SqlCommand command = new SqlCommand (commandText, connectionString); command.Parameters ["@ ID"]. Value = customerID;
If you are developing an MVC application, then the Entity Framework covers some vulnerabilities. Getting a SQL injection that works in an MVC / EF application has to be tricky. However, this is possible if you execute SQL using ExecuteQuery or call poorly written stored procedures.
Although ORM avoids SQL injection (with the exception of the examples above), it is recommended that you restrict attributes to the values that model fields, and therefore forms, can take. For example, if it is assumed that only text can be entered in the field, then use Regex to specify the range ^ + $. And if numbers must be entered in the field, then indicate this as a requirement:
Public string Zip (get; set;)
In Web Forms, you can limit values using validators. Example:
Since .NET 4.5 Web Forms use Unobtrusive Validation. This means that you do not need to write any additional code to validate the value of the form.
Data validation, in particular, can help protect against another well-known vulnerability called cross-site scripting (XSS).
XSS
A typical example of XSS is adding a script to a comment or guestbook entry. It can look like this:
As you can imagine, in this example, cookies from your site are passed as a parameter to some hacker resource.
In Web Forms, you can make a mistake with code like this:
sorry<%= username %>but the password is wrong
It is clear that instead of username there can be a script. To avoid script execution, you can at least use another ASP.NET expression: that encodes its content.
If we use Razor, the strings are automatically encoded, which minimizes the possibility of XSS implementation - a hacker will be able to pull it off only if you make a gross mistake, for example, use @ Html.Raw (Model.username) or use MvcHtmlString instead of string in your model.
For additional protection against XSS, the data is also encoded in C # code. In NET Core, you can use the following encoders from the System.Text.Encodings.Web namespace: HtmlEncoder, JavaScriptEncoder, and UrlEncoder.
The following example will return the string
