Create a SSRF vulnerable website to understand the vulnerability and its implications. While learning to use basic building blocks of a website you can learn what issues developers and defenders face and at the same time learn to detect and abuse SSRF.
Create a SSRF vulnerable website – LAB
In the lab available at Substack you will learn
- How to setup a Docker container
- Use Flask to create
- A “frontend”
- An “API”
- An admin web page
- Identify the SSRF vulnerability and exploit it
Follow along the lab at https://bowtiedguppy.substack.com/p/ssrf-lab
SSRF explained – what is SSRF?
Server Side Request Forgery (SSRF) happens when you can ask the website to perform actions on behalf of you that you yourself are not authorized to do.
- For example there is a web server that hosts a restricted webpage on /secret and a public website on /public
- To visit /secret you can not make the request from an external address – you need to make it from the localhost.
- Perhaps there exists functionality on /public that you can take advantage of and make the web server send a query to /secret for you – a query from localhost.
You forged a request that was processed server side and executed for you.
Server Side Request Forgery is complicated
From the above example you can probably get the concept of SSRF but it is still a relatively complicated vulnerability.
You need multiple things going for you:
- You need to identify some functionality of a website that you can use to make requests
- Find somewhere to send the requests
- Hope the functionality you used have access to “somewhere”
So this makes this relatively complicated for you as an attacker to identify and weaponize.
SSRF is also complicated from the defensive perspective
SSRF is not only complicated for an attacker – it is also complicated from a defender / developer perspective.
If your website / server / api infrastructure is large and complex and there are many relationships between the different sites and APIs – the risk for error increases.
You can review the code for one sensitive site and make sure it only allows connections from the internal network. Great – but that is not enough. All the other sites that also are hosted on the internal network – if anyone can make them make a request..
You get the point. A good understanding of the relationships of your infrastructure is needed – what should be able to communicate with what. You also need to make sure that your code only makes the request you expect it to.
This lab is a fun way to realize the issue with SSRF and that it’s not always easy to identify. Another lab you can try is Create a XSS vulnerable website
