Server-Side Request Forgery (SSRF) Explained : Web Security & Vulnerability

Known as SSRF, Server-Side Request Forgery indicates an attack which lets an attacker send some deliberately modified requests from some vulnerable web server applications. When the client is interacting with the web server to get some required resources, due to the fact that the web server is the contact point to the external world, there will be some firewall services protecting this server from unauthorized access. However, for other internal resources or services which are not accessible to the public, there will be few protection regarding the permissions to access them. Since the web server will be considered as a member of the internal network, it will have permission to access a number of secure services in the network. That means if there are some vulnerable codes existing on the public-facing web server, hackers can take advantage of that compromised web server to forward requests to other internal services and get unauthorized access to the data. This is what the SSRS is talking about. Let's illustrate this idea through an example. In most web servers, there will be some services which enable clients to provide some data from the external world such as updating the profile image or redirecting to other pages etc. For example, there is a page which enables users to update the profile image by uploading one from another website. In the case of a normal user, the client will provide the image url to the server. Then the web server will call some functions such as get_file_contents(url) to get the image contents. The fetched contents will be displayed on the screen for customers to double confirm. If the customer is happy with the image and clicks the accept button, that image will be saved to the database. The last step will be redirecting the customer to the confirmation page. Since the url will be provided by the user, we can see there might be a vulnerability in this workflow which can be used by a hacker to get authorized access. When the hacker initiates the request, he may use a url pointing to the internal non-public-facing web server instead of an external image. So, when the server is using the get_file_contents(url) function to get the contents, it will return the contents from that website. Moreover, if the hacker is using an url pointing to a local file server, he may easily get some Secure Credential files from that server. The same trick can also be used for other internal web resources such as ftp server, web services, databases etc. The previous SSRF example shows how a hacker can get some secret data via unauthorized access. Since they will get the content of the data, those attacks are categorized as "Content-Based" SSRF attacks, which is considered to be potentially the most dangerousones. Apart from that, there are other types of attacks which do not get the exact data. However, via some redirections in the internal network, some other data about the server or the internal network such as the existence of some resources etc. A "Boolean-Based" SSRF will detect if a resource or a server does exist in the internal network or not. An "Error-Based" SSRS will detect if HTTP (404 or 500) will be returned when trying to access some services, and thus determine if those resources do exist or not. Although those SSRF variations do not provide any specific data, it will give the hacker some clues to illustrate the topology of the internal network. Actually, each programming language will have some vulnerable functions which are similar to the one in step one. So, being aware of this issue, developers should pay more attention to those vulnerabilities. The protection of important internal resources should be strengthened. Also, the use of localhost and some non-http protocols such as file:// or ftp:// should be disabled on the server which may be vulnerable to SSRF attacks. Moreover, nowadays, there are also some ready-to-use tools which can help to quickly identify the vulnerabilities of a web page or a web server.