Lab 4 - SSRF Attacks and Defenses
In this Lab, you will explore SSRF (Server-Side Request Forgery), a common vulnerability in modern applications. SSRF allows an attacker to induce a server-side application or API to originate HTTP requests to an arbitrary URL the attacker specifies. This vulnerability can allow the attacker to access internal services behind firewalls, access sensitive data, or perform unauthorized actions on behalf of the vulnerable server.
We will explore how this vulnerability works and what type of mitigation can be effective against it.
Time allocation
15 minutes
Inspecting the download script
Step 1. Please visit the URL http://www.sansapi.com/. You should see the Animal Shelter page. If prompted for login, please use the credentials you created earlier.
Info
If you cannot remember your credentials from Lab 1, please register a new user.
Step 2. Open the Developer Tools. Use Ctrl + Shift + I or F12 on Windows and Linux. Use Cmd + Opt + I or F12 to enable the developer tools on macOS.
Step 3. Select the "Network" tab in Developer Tools.
Step 4. Click on the "Adoption Agreement" on the page and use the Developer Tools to investigate the request. Observe the URL visited.
Step 5. The browser displays the PDF contract. Please observe the URL of the file:
https://bypass.sansapi.com/fetch?pdfurl=http://static/adoption.pdf.
The query string (the portion of the URL after the "?") contains the parameter "pdfurl". The "pdfurl" refers to the file's backend URL.
Info
Allowing a full URL as an HTTP parameter can lead to Server-Side Request Forgery (SSRF) if the API or server does not limit the sources from which the server can fetch data. This vulnerability enables an attacker to manipulate the URL path, potentially accessing sensitive information from web locations that are usually inaccessible.
Step 6. Let's explore the conditions under which the URL fetching will work. Try https://bypass.sansapi.com/fetch?pdfurl=http://static/cat.pdf. This is another PDF file hosted on the same server
Step 7. Visit https://bypass.sansapi.com/fetch?pdfurl=http://static/images/cat11.jpg, which fails. Yet, we know this file exists on the server from our earlier visit. This URL points to the same file as https://www.sansapi.com/images/cat11.jpg, which works. The error message seems to indicate that some filtering is happening.
Step 8. We can also try this URL: https://bypass.sansapi.com/fetch?pdfurl=http://intranet/cat.pdf. It is referencing a different server, called intranet. It also appears to be filtered.
Info
The filtering condition for this specific "pdfurl" parameter is listed below,
const urlregex = /^(http|https):\/\/static\/[^\/]+\.pdf$/;
The conditions in this regular expression will match the URL that: * Start with either "http://" or "https://". * Followed by the hostname "static". * Followed by a forward slash. * Followed by any characters (except new line) zero or more times.
Due to this regular expression, downloading other PDFs from the same server is allowed. Different servers or other file types are not allowed. Using this restrictive filter on the URL seems effective but using some cleverly crafted strings, and attacker may evade the filter. This is not the best approach to prevent SSRF. More on that later.
Exploiting the SSRF flaw
We have a vulnerable version of the script running alongside "fetch". We can use it to learn about the inner workings of SSRF.
Step 1. Visit https://bypass.sansapi.com/fetch-ssrf?pdfurl=http://static/adoption.pdf. This URL connects to a different endpoint. We are again fetching the same file, "adoption.pdf". This URL works just like it did for the "fetch" endpoint.
Step 2. Visit https://bypass.sansapi.com/fetch-ssrf?pdfurl=http://intranet/index.html. Notice that this page looks like an intranet website. We are getting the content of this website through the "fetch-ssrf" API endpoint. It appears this SSRF vulnerability allows the attacker to fetch content from the intranet. Inspect the page's HTML source to see if you observe anything interesting. You can do so by right-clicking on the page. Next, select View page source or use the Developer Tools and look at the "Response" tab. Look for any interesting resources.
Step 3. Has anyone noticed the mascot link? Check out https://bypass.sansapi.com/fetch-ssrf?pdfurl=http://intranet/dog.pdf, a PDF containing a picture of Johannes' dog. We told you he's angry because Johannes is spending time on this lab and not taking him to the park. He is also furious that you just breached the security of the animal shelter.
Step 4. The HTML page in Step 2 links to a set of HR records, https://bypass.sansapi.com/fetch-ssrf?pdfurl=http://intranet/data.json, which should be internal only. (Dummy data only for this exercise, no actual PII)
In summary, the recent queries utilized the fetch-ssrf API to initiate HTTP GET requests to various resources accessible through the fetch-ssrf API. This included intranet resources. These resources are typically not exposed to the Internet but became indirectly accessible via SSRF through this intermediary. The diagram below helps to summarize the view,
Info
SSRF can be mitigated through multiple actions, - Network segmentation or firewalls: If the API intermediary cannot access the sensitive resource, then the damage is reduced. - Restricting the URL location: We have leveraged this in our /ssrf endpoint. It is a bare minimum defensive approach. It is possible for the filter to be evaded, if the filtering is not comprehensive in every single way. - Avoid using full URL in parameters: Design the application so that full URLs passed from users to the server are not required. This is probably a more comprehensive approach to fixing this vulnerability.