Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sandbox URL Creation #438

Closed

Conversation

pixeebot[bot]
Copy link
Contributor

@pixeebot pixeebot bot commented Feb 21, 2024

This codemod sandboxes calls to requests.get to be more resistant to Server-Side Request Forgery (SSRF) attacks.

Most of the time when you make a GET request to a URL, you're intending to reference an HTTP endpoint, like an internal microservice. However, URLs can point to local file system files, a Gopher stream in your local network, a JAR file on a remote Internet site, and all kinds of other unexpected and undesirable outcomes. When the URL values are influenced by attackers, they can trick your application into fetching internal resources, running malicious code, or otherwise harming the system.
Consider the following code for a Flask app:

from flask import Flask, request
import requests

app = Flask(__name__)

@app.route("/request-url")
def request_url():
    url = request.args["loc"]
    resp = requests.get(url)
    ...

In this case, an attacker could supply a value like "http://169.254.169.254/user-data/" and attempt to access user information.

Our changes introduce sandboxing around URL creation that force developers to specify some boundaries on the types of URLs they expect to create:

  from flask import Flask, request
- import requests
+ from security import safe_requests

  app = Flask(__name__)

  @app.route("/request-url")
  def request_url():
    url = request.args["loc"]
-   resp = requests.get(url)
+   resp = safe_requests.get(url)
    ...

This change alone reduces attack surface significantly because the default behavior of safe_requests.get raises a SecurityException if
a user attempts to access a known infrastructure location, unless specifically disabled.

If you have feedback on this codemod, please let us know!

F.A.Q.

Why does this codemod require a Pixee dependency?

We always prefer to use built-in Python functions or one from a well-known and trusted community dependency. However, we cannot find any such control. If you know of one, please let us know.

Why is this codemod marked as Merge After Cursory Review?

By default, the protection only weaves in 2 checks, which we believe will not cause any issues with the vast majority of code:

  1. The given URL must be HTTP/HTTPS.
  2. The given URL must not point to a "well-known infrastructure target", which includes things like AWS Metadata Service endpoints, and internal routers (e.g., 192.168.1.1) which are common targets of attacks.

However, on rare occasions an application may use a URL protocol like "file://" or "ftp://" in backend or middleware code.

If you want to allow those protocols, change the incoming PR to look more like this and get the best security possible:

-resp = requests.get(url)
+resp = safe_requests.get(url, allowed_protocols=("ftp",))

Dependency Updates

This codemod relies on an external dependency. We have automatically added this dependency to your project's requirements.txt file.

This library holds security tools for protecting Python API calls.

There are a number of places where Python project dependencies can be expressed, including setup.py, pyproject.toml, setup.cfg, and requirements.txt files. If this change is incorrect, or if you are using another packaging system such as poetry, it may be necessary for you to manually add the dependency to the proper location in your project.

More reading

Powered by: pixeebot (codemod ID: pixee:python/url-sandbox)

@@ -6,3 +6,4 @@ pypng>=0.0.20
PyYAML>=5,<7
requests>=2.25.0,<3.0.0
urllib3>=1.26.5,<2.0.0
security~=1.2.0
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This library holds security tools for protecting Python API calls.

License: MITOpen SourceMore facts

@dwanderson-intel
Copy link
Contributor

security requires python >=3.8

@drdavella
Copy link

@dwanderson-intel hello @pixeebot maintainer here. Just curious but if you had been using a compatible version would this be a change you would be interested in/willing to accept?

@dwanderson-intel
Copy link
Contributor

hey, thanks for chiming in @drdavella ! For this particular change, yes,having the URL sandboxed would be nice.

Since this is a client library, we like to keep the versioning as wide as possible; but for some of our other repos (eg sigopt-server), since it's self-contained, it's more reasonable for us to bump to more recent versions of python.

@tjs-intel
Copy link
Contributor

tjs-intel commented Feb 21, 2024

@drdavella possibly, although in this particular instance the hostname of the OIDC url may resolve to a private IP address (because it is referring to an AWS service from within EKS, another AWS service), which is something that you may want to prevent in a future version of security.

@drdavella
Copy link

@tjs-intel @dwanderson-intel thanks very much for the feedback! It's possible that the security package is needlessly restrictive. I've opened an issue here: pixee/python-security#12

One reason we imposed this restriction was because Python 3.7 and earlier are officially EOL in terms of support. However I understand that there are reasons that some projects may need to retain backwards compatibility. It is especially useful for a security library to support some degree of backwards compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants