System has security hole
You often hear the web security vulnerability can cost up to hundreds of millions of dollars. But do you know there are many kinds of cyber-attack upon to what web security vulnerability is. Every website has server and third-party libraries installed on it. Attacker would exploit the security vulnerability of third-party software to attack servers. That kind of attack called Server-Side Request Forgery Today I want to share what Server-Side Request Forgery is and a kind of security vulnerability on Axios software.
Server-Side Request Forgery is a type of cyber-attack that targets servers that store valuable resources. So, it is important to know way of protecting our resources. Some attacks over the world listing here
Capital One (2019): A misconfigured web application firewall allowed an attacker to retrieve credentials and access a backend server containing sensitive customer data. This breach exposed data of around 106 million individuals across the U.S. and Canada.
Microsoft Exchange (2021): The Hafnium group exploited multiple vulnerabilities, including SSRF, to infiltrate Microsoft Exchange servers. This attack compromised email systems used by thousands of organizations, including universities, think tanks, and defense contractors.
Microsoft Azure (2023): SSRF vulnerabilities were discovered in key Azure services such as API Management and Machine Learning. While Microsoft quickly mitigated the issues, the incident highlighted how even major cloud providers are susceptible to these attacks.
Now let get familiar with the necessary terms. If you have been fully aware of those technical terms, please go straight the issue section.
Server Side Request Forgery (SSRF): is a type of vulnerability. The attacker tricks a server into making unauthorized requests on the server’s behalf. The attacker has less privileges than the server. With this technique, the attacker can access internal services or resources. They can even perform actions that they would not do directly.
How SSRF Attacks the server
User Input is Misused: The attack begins when an application accepts user input that controls the URL or resource that the server will fetch. For example, if a web application allows users to supply a URL to fetch content, like profile images, without proper validation, an attacker can supply their own crafted URL.
Attacker Controls the Request: By controlling the URL or request, an attacker can force the server to send requests to any destination, including internal or external addresses. The attacker could send requests to internal networks, get sensitive data from metadata services or do some external services like DDos.
Server Executes the Request: Since the server typically has higher privileges and may have access to restricted internal systems or sensitive external APIs, it can send requests that the attacker could not directly initiate.
The real issue
Since my project was scanned with Veracode and it found the vulnerability from Axios. So let be aware of this extremely popular software.
Axios: is a very popular library used to make HTTP requests from Node.js or from the browser. It is often used in web development to interact with RESTful APIs. Its downloads can reach up to 50 million times per week. If your project is React.js or Next.js, you probably heart about it or used it.
In the web development, axios often used as following
const axios = require('axios');
async function fetchData(url) {
try {
const response = await axios.get(url);
console.log('Data:', response.data);
} catch (error) {
console.error('Error fetching data:', error.message);
}
} fetchData("https://jsonplaceholder.typicode.com/posts");The code run with nodejs. It fetchs the posts from free API provider with fake data. There is no error or something strange for code above. It return the posts for you. What if you change a bit for the fetchData line
fetchData(“//jsonplaceholder.typicode.com/posts”);
That should not run for the security issue. If it can be executed, the threat comes because it can be changed to ftp:// or ws://. In fact, the jsonplaceholder API is called and the posts are printed onto the console. So that is clearly a security vulnerability for SSRF.
Notice that just happens in versions 1.7.3 and before. From version 1.7.4 Do Trong Hai, a Vietnamese developer and his collaborator, have fixed the issue You can find the fix version here
Axios is a great tool for making API calls, but its rich features can also lead to vulnerabilities. Compare to fetch, a native function used for calling API calls, does not have this vulnerability due to the simplicity.
You can experiment the code yourself by creating the index.js file and paste the code. It will be executed with node.js command. If you want to fix it, just upgrade the version to latest one and see if it could print anything.
What you want to know is the reason. Here is the change in Axios code which can give us the clue.
As you see, the old code accepted everything before the double slashes. It created the chance for exploiting this hole like input //url-hackers-want. From there, the server request with its privilege or permission will reveal the hidden resources to the hackers. Your website is the big vulnerable one. So, the fix has stopped that behavior.
SSRF cannot be exploited on client environment
Axios vulnerability only be exploited in server side. It is safe in client side due to following reasons
- Axios in the browser cannot access internal networks or sensitive services because the browser environment is isolated from those resources.
- Same-Origin Policy (SOP) and CORS prevent cross-origin attacks that could otherwise be used to exploit SSRF vulnerabilities.
- Browser limitations on protocols and headers further restrict the types of requests that can be made, reducing attack vectors.
Solutions to avoid server attacking
You can protect your server from SSRF by following methods
Educate developer awareness: developers are source of vulnerability. While they are creating code without knowledge about SSRF, they inadvertently create the chance for hackers attacking their system. There should be training courses for your company in a period about web security.
Keep update your libraries to latest: update your library to latest version is critical to your app security. The case of Axios proves to that issue. But the community always have the significant contribute to the source code and publish the batch in time. Also keep an eye on security report of the security sites. Or you use the security scan tools to soon find any arise issue.
Sanitize User Input: if your app has anywhere to allow user input, it is a posing risk. Make sure that input data conforms to expected types and formats. For instance, if a URL is expected, check that the input is a well-formed URL. Disallow or sanitize special characters or patterns that could be used for SSRF, such as internal IP ranges (e.g., 127.0.0.1, localhost). By specifying your application’s allowed URL schemes (eg HTTP and HTTPS), you can restrict users from inputting URLs with potentially dangerous or unwanted schemas (eg file:// and ftp://). If the URL doesn’t adhere to these schemas, you can reject it
Safe domains or whitelist approach: Define a list of allowed URL patterns, IP addresses, or domains. Reject any input that does not match these patterns.
Firewall approach: You can get Network level protection like firewall or proxy app. It can block unintended outbound traffic. A well-configured firewall can block or restrict outbound requests to untrusted or internal IP ranges (such as localhost or private IP addresses like 192.168.x.x, 10.x.x.x), thus preventing the server from making malicious requests. Another capability is preventing DNS rebinding. Some firewalls are capable of blocking or detecting DNS rebinding attacks, a technique sometimes used in SSRF to bypass IP address-based filtering.
Conclusion
Web security is always a big concern and SSRF is the very popular one among them. By understanding what the SSRF is, prepare the solutions to prevent and mitigate the sequence are the most effective way to save money and effort. But keep in mind single solution will not the smart way but combining all available methods would protect your system at highest level. Wish you guys would be safe all the time along your apps.
Reference: