Build security (same-origin policy, some protections against CSRF and DNS rebinding) into requests

`requests` has some security problems.

Browsers have same-origin policies, csrf protection headers and security addons like uMatrix and NoScript, preventing CSRF and some XSS attacks. Requests doesn't. So if a user of a browser opens a web page with a malicious script, the page won't access the authenticated admin consoles of user's IoT or local CUPS server: the addons provide the protections against even dns rebinding. But a script crawling the web lacks these protections, so a malicious webpage can trick the script into accessing local rezources.

So we need introduce security contexts.

1. a user creates a session
2. a user spawns a security context
3. a user is not allowed to access the URIs non available from the context using that context object.
4. for accessing them a user can redefine the restrictions of a context.
5. user should access the links from the pages loaded from the context using only a contexts, and this should be checkable by taint analysers.
6. spawning a context should be a simple call, and `requests` should do the work automatically
7. requests should by default enable the checks preventing accessing addresses from intranet.



Hi @KOLANICH,

Thanks for reaching out. I'm not sure if this makes sense in the scope of Requests. Requests is not a web browser and deals with the web in the context of a single http request. We don't execute any asynchronous scripts or additional asynchronous requests in a single call. If you have a script that's capable of being tricked into retrieving local information and sending it back to a remote server, that's at least 3 requests and would be a vulnerability in code implemented using Requests.

If you have specific examples of a vulnerability, I'd encourage you to reach out to Ian or I with the disclosure information [here](http://docs.python-requests.org/en/master/community/vulnerabilities/).

> If you have a script that's capable of being tricked into retrieving local information and sending it back to a remote server, that's at least 3 requests and would be a vulnerability in code implemented using Requests.

Yes, it would be a vulnr in the code, but it would be a flaw in requests design. The tools should be designed in the way encouraging and making easy to use them in a secure way. If one violates this recommendation, if the tool is popular, there will be many apps using it insecurely.

So IMHO some security should be built into `requests` itself.

@KOLANICH do you understand that Requests does not execute JavaScript or any of the contents of the response body?

I do, but it is still possble to repurpose the existing code.

For example, let we have the following script

```python
resources=requests.get("https://someSite.com/mirrors.json").json()
for r in resources:
    try:
       csv=requests.get(r).text
    except:
       warn("Mirror"+r+" is not available, trying another one")
       continue
    dataset=parseCsv(csv)
    break
```

What if the malicious server sends the following response:

```javascript
["http://192.168.1.1/index.html", "https://someSite.com/dataset.csv"]
```

If http://192.168.1.1/index.html is available, then the program gets html and crashes because it is invalid csv and doesn't probe the second URI, and the server can derive it.
If it is not available, it probes the second URI.

This way a malicious server hosting a list of mirrors can probe intranet.

This sounds like user issue rather than a requests issue. Like Nate said above, this library is only for singular HTTP requests. What a user does with response information isn't really requests business.  The same goes for curl/wget and every other HTTP library.

>This sounds like user issue rather than a requests issue.

It is. But the purpose of libraries is to solve issues of its users. Of course it is possible to create a wrapper for `requests` checking same-origin policy, but ... it would be used by noone.