JordanMilne / Advocate

An SSRF-preventing wrapper around Python's requests library. Advocate is no longer maintained, please fork and rename if you would like to continue work on it.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Advocate

image

image

Advocate is no longer maintained, please fork and rename if you would like to continue work on it

Advocate is a set of tools based around the requests library for safely making HTTP requests on behalf of a third party. Specifically, it aims to prevent common techniques that enable SSRF attacks.

Advocate was inspired by fin1te's SafeCurl project.

Installation

Advocate is officially supported on CPython 3.6+. PyPy 3 may work as well, but is not tested.

Examples

Advocate is more-or-less a drop-in replacement for requests. In most cases you can just replace "requests" with "advocate" where necessary and be good to go:

Advocate also provides a subclassed requests.Session with sane defaults for validation already set up:

All of the wrapped request functions accept a validator kwarg where you can set additional rules:

If you require more advanced rules than the defaults, but don't want to have to pass the validator kwarg everywhere, there's RequestsAPIWrapper . You can define a wrapper in a common file and import it instead of advocate:

Other than that, you can do just about everything with Advocate that you can with an unwrapped requests. Advocate passes requests' test suite with the exception of tests that require Session.mount().

Conditionally bypassing protection

If you want to allow certain users to bypass Advocate's restrictions, just use plain 'ol requests by doing something like:

requests-futures support

A thin wrapper around requests-futures is provided to ease writing async-friendly code:

You can do basically everything you can do with regular FuturesSession s and advocate.Session s:

When should I use Advocate?

Any time you're fetching resources over HTTP for / from someone you don't trust!

When should I not use Advocate?

That's a tough one. There are a few cases I can think of where I wouldn't:

  • When good, safe support for IPv6 is important
  • When internal hosts use globally routable addresses and you can't guess their prefix to blacklist it ahead of time
  • You already have a good handle on network security within your network

Actually, if you're comfortable enough with Squid and network security, you should set up a secured Squid instance on a segregated subnet and proxy through that instead. Advocate attempts to guess whether an address references an internal host and block access, but it's definitely preferable to proxy through a host can't access anything internal in the first place!

Of course, if you're writing an app / library that's meant to be usable OOTB on other people's networks, Advocate + a user-configurable blacklist is probably the safer bet.

This seems like it's been done before

There've been a few similar projects, but in my opinion Advocate's approach is the best because:

It sees URLs the same as the underlying HTTP library

Parsing URLs is hard, and no two URL parsers seem to behave exactly the same. The tiniest differences in parsing between your validator and the underlying HTTP library can lead to vulnerabilities. For example, differences between PHP's parse_url and cURL's URL parser allowed a blacklist bypass in SafeCurl.

Advocate doesn't do URL parsing at all, and lets requests handle it. Advocate only looks at the address requests actually tries to open a socket to.

It deals with DNS rebinding

Two consecutive calls to socket.getaddrinfo aren't guaranteed to return the same info, depending on the system configuration. If the "safe" looking record TTLs between the verification lookup and the lookup for actually opening the socket, we may end up connecting to a very different server than the one we OK'd!

Advocate gets around this by only using one getaddrinfo call for both verification and connecting the socket. In pseudocode:

See Wikipedia's article on DNS rebinding attacks for more info.

It handles redirects sanely

Most of the other SSRF-prevention libs cover this, but I've seen a lot of sample code online that doesn't. Advocate will catch it since it inspects every connection attempt the underlying HTTP lib makes.

TODO

Proper IPv6 Support?

Advocate's IPv6 support is still a work-in-progress, since I'm not that familiar with the spec, and there are so many ways to tunnel IPv4 over IPv6, as well as other non-obvious gotchas. IPv6 records are ignored by default for now, but you can enable by using an AddrValidator with allow_ipv6=True.

It should mostly work as expected, but Advocate's approach might not even make sense with most IPv6 deployments, see Issue #3 for more info.

If you can think of any improvements to the IPv6 handling, please submit an issue or PR!

Caveats

  • mount() ing other adapters is disallowed to prevent Advocate's validating adapters from being clobbered.
  • Advocate does not, and might never support the use of HTTP proxies.
  • Proper IPv6 support is still a WIP as noted above.

Acknowledgements

About

An SSRF-preventing wrapper around Python's requests library. Advocate is no longer maintained, please fork and rename if you would like to continue work on it.

License:Other


Languages

Language:Python 100.0%