Abhay Bhargav Profile picture
Mar 23 ā€¢ 10 tweets ā€¢ 5 min read
#SSRF is a super popular vulnerability that is leveraged extensively, by bad actors. Let's look at SSRF defense in this šŸ§µ 1/
Let's start with the basics. SSRF happens because your app makes requests to other URLs based on user-generated data. If your app doesnt need to redirect/request random URLs (functionality), ensure that you have a tight allowlist. Only redirect to URLs in the allowlist 2/
But if your app needs to redirect to a larger (purely user-defined) set of URLs, then things may get a little more complex. Now you need to validate inputs like a mf'er. Parse and Break down URLs by scheme, domain, etc. Validate each one as required 3/
Lets start with Defense-in-depth. Remember that cloud metadata access is a big part of using SSRF. If feasible, consider applying network security policies to prevent access to these metadata endpoints. These may be difficult though, especially if you need it 4/
In that case, especially for @awscloud using IMDSv2 will go a long way. For @kubernetesio consider not injection serviceAccountTokens in the pod unless you need it. 5/
@awscloud @kubernetesio Let's look at additional defense-in-depth. Test your libs for SSRF (among other things) a major source of SSRF vulnerabilities is third party libs and using patched/securely configured ones go a long way in preventing this 6/
@awscloud @kubernetesio A very simple http client config that you should enable is to turn off "following redirects". Malicious apps might force redirect to a local resource. This is a huge class of attacks that can entirely be prevented with this simple config 7/
@awscloud @kubernetesio DNS rebinding is an issue with SSRF flaws where a so called public domain resolves to an internal/localhost address. This is a little complex, because you need to be able to detect this malice when DNS resolves. You either need to use a DNS server that has these secure configs 8/
@awscloud @kubernetesio OR look at a DNS proxy on the server that is running the app. Either way, this is a little involved.
As you can see, SSRF is not "straightforward" a'la SQL injection. It has several dimensions, especially based on the type of app and the risk. It needs nuance in defense.
@awscloud @kubernetesio That's a wrap!

If you enjoyed this thread:

1. Follow me @abhaybhargav for more of these
2. RT the tweet below to share this thread with your audience

ā€¢ ā€¢ ā€¢

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Abhay Bhargav

Abhay Bhargav Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @abhaybhargav

Mar 21
IMO #DevSecOps has a close-knit relationship with #ZeroTrust. Let's dive in with a šŸ§µ
I've already tried to cover ZeroTrust as a summary here šŸ‘‡2/
The way I see it, both the identity and policy aspects of ZeroTrust require/can do with a solid "shift left" approach of being able to incorporate identity and policy checks in the build/deployment flows. 3/
Read 7 tweets
Mar 15
Realized that there's a huge gap in knowledge for some taxonomy and terms in #infosec. Here's a šŸ§µ
Let's start with CWE from @CweCapec. Common Weakness Enumeration.
* This is šŸš« a scoring system
* This is identifier for a type of vuln
For example: SQL Injection is CWE 89
It has broad "parent" and more specific "child" categories. But EOD, they are Vulnerability IDs 2/
@CweCapec Let's look the one its most confused with. CVE (@CVEnew). This is a number that is assigned to a specific vulnerability identified against software/hardware that is publicly available (commerical/OSS). Ex: CVE-2022-0847 is a CVE given to the Linux #DirtyPipe vul. 3/
Read 10 tweets
Dec 10, 2021
ICYMI, this is how the #log4j #Log4Shell flaw works (in simple english), a šŸ§µ
1. Victim is running a Java Web that uses the log4j logging lib
2. The victim web app has code that logs http request payloads/headers with log statements (example User-Agent)
1/ Image
3. Attacker identifies vulnerable app and makes a request to the server with the User-Agent Value set to this. What does this mean? 2/ Image
jndi == Java Naming and Directory Interface. Allows Java apps to access multiple apis for LDAP, Remote Method Invocation (RMI), etc through the JNDI Interface
4. The attacker tries to get the log4j library to lookup an LDAP server through JNDI 3/
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!