CSRF / SSRF: Why did you avoid XSS or did you "send" a Weibo?

How did the CSRF attack occur?

When we visit a Web page, it is not our own to get the page information, but the browser to get the information and display them. This means that you allow the browser to interact with the Web server on your behalf. In order to be able to accurately represent your identity, browsers usually store some necessary identity information in cookies. Therefore, when we use a web page, we only need to log in on the first visit.

In terms of user experience, this is of course very convenient. However, hackers use this to write web pages with malicious JavaScript scripts to induce you to visit by "phishing". Then, the hacker will steal your identity information saved in the webpage through these JavaScript scripts, by spoofing you, let your browser initiate a fake request, and finally perform the operation defined by the hacker. And all this is imperceptible to you. This is the CSRF (Cross-Site Request Forgery) attack.

When you initiate a transfer on the bank page, this process is actually done through a transfer interface. The contents of this interface may include the following:

Interface address: http://bank.com/transfer ;
HTTP method: POST;
Interface parameters: to (target account), amount (amount).

What can a hacker do with a CSRF attack?

Like XSS, CSRF can also impersonate users to make some functional operation requests, such as changing passwords, transferring funds, etc., which is equivalent to bypassing identity authentication and performing unauthorized operations.

Even if there is no injection vulnerability in your web page, as long as the interface is not configured properly, it can be exploited by CSRF. And hackers only need to build an inductive webpage in their own domain name, so that any user who visits the webpage can be subject to CSRF attacks. Moreover, users need to visit a large number of web pages every day, there is no way to confirm the legality of each web page. Strictly speaking, users have no way to prevent CSRF attacks. Therefore, we can only start from the application itself to strengthen protection.

How to perform CSRF protection?

The standard CSRF protection method in the industry is CSRFToken.

CSRF launches attacks by automatically submitting forms. Therefore, in the previous transfer example, the hacker can analyze the parameters required by the interface http://bank.com/transfer by capturing the packet to construct the corresponding form. Therefore, we only need to add a parameter that cannot be guessed by hackers to this interface to effectively prevent CSRF. This is how CSRF Token works.

In addition to CSRF Token, we can also strengthen protection through secondary verification.

The hacker initiated a transfer for you through the CSRF attack. At the time of payment, the bank will launch a brand new page to allow you to verify the payment password. At this time you found that this payment request was not initiated by you, then you will definitely not enter the payment password to complete the verification. Therefore, when a user performs a sensitive operation such as payment, the application usually requires the user to provide some private information, just to protect against CSRF attacks.

CSRF is actually a feature that hackers use browsers to store user cookies to simulate a user's request for authentication information, such as transferring money and changing passwords.

The principle of protecting CSRF is also very simple. In these requests, add some parameter information that hackers cannot get, such as CSRF Token or independent payment password.

SSRF: The same principle, what happens to the server?

When we search for pictures in Baidu, cross-domain loading protection of pictures is involved. Baidu does not directly load the source address of the picture on the page, but submits the address to the Baidu server through GET parameters, and then Baidu server requests the corresponding Picture, and then return to the page to display.

During this process, the Baidu server will actually initiate a request to another URL address (for example, http://s1.sinaimg.cn in the figure above). Using this agent's request-initiating function, a hacker can access any intranet service by submitting an intranet address. This is the implementation process of the SSRF attack, which is what we often refer to as "intranet penetration".

What can hackers do with SSRF attacks?

Intranet detection

We assume such a server logic: during this request, the server will determine whether the Content Type of the data returned by objurl is image / jpeg. Then, there are three possible return results:

"Yes", show pictures;
"No", it returns "Format error";
If there is no response, it returns "No picture found".

Based on these three return logics, a hacker can construct a malicious request address: https://image.baidu.com/search/detail?objurl=127.0.0.1:3306. If the server returns "format error", it means that the local port 3306 is available; if it returns "cannot find the picture", it means it is not available. We know that 3306 is the port number corresponding to MySQL. Therefore, according to the returned information, the hacker can know whether a MySQL service is enabled locally on the server. Next, the hacker only needs to repeat this process continuously and try different IP and port numbers to detect the structure of the entire intranet bit by bit.

File reading

In addition to not judging the legality of the agent of the picture, the server does not judge many other agents, but directly returns the result of the agent to the front end. We call this situation "SSRF with echo". In this case, the hacker can not only know whether the request was successful, but also know the specific content returned.

In the URI, the http: // and https: // at the beginning represent what protocol needs to be used to make the request. In addition to HTTP, URI also has a variety of protocols to choose from, such as file: // is to directly read the local file. By entering file: // etc / passwd, the hacker can obtain the local passwd file through a request, so as to know which users are local. After continuous attempts, hackers can pull out the contents of files in the entire server, including extremely sensitive information such as keys and source code.

How to perform SSRF protection?

Whitelist restrictions, protocol restrictions, and requester restrictions.

Whitelist restrictions are always the simplest and most effective protection measures. The whitelist in SSRF is to restrict the target URL submitted by users. For example, only URLs under the same domain name are allowed. You can understand that letting Baidu Picture's proxy service only allow to proxy the URL of baidu.com.

Restrictions on protocols and resource types. For example: for the use protocol, we only allow HTTP or HTTPS protocol; for the returned content, we only allow content in image format.

Request-side restrictions

First, the service interfaces provided for other businesses should use POST as much as possible to avoid the use of GET.

Second, the service interfaces provided for other businesses should be verified every time.

to sum up

CSRF is a hacker-controlled user's browser to initiate a forged request, SSRF is a hacker-controlled server to initiate a forged request. Through forged requests, hackers can forge the identity of users or servers, obtain data beyond their authority, or initiate requests. The more sensitive the request interface in the application, the more damage the hacker can cause.

CSRF and SSRF are generated in the normal business function logic, therefore, we have no way to fundamentally organize hackers to initiate forged requests. However, you can strengthen the security verification of the interface to avoid the impact of forged requests. In CSRF, we can strengthen protection through operations such as CSRF Token or secondary verification. In this way, hackers cannot obtain private information, and they cannot initiate continuous requests. In SSRF, we need to limit the domain names that can be requested to limit the resources that hackers can access. In addition, the target server also needs to strengthen the verification of the interface to avoid the forgery request successfully passing authorization.