Opened 9 years ago
Last modified 4 years ago
#27961 closed Bug
HTTP_X_FORWARDED_PROTO is bypassed — at Version 6
| Reported by: | cryptogun | Owned by: | nobody |
|---|---|---|---|
| Component: | HTTP handling | Version: | 1.10 |
| Severity: | Normal | Keywords: | redirect HTTPS X-Forwarded-Proto |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
I'm using nginx + gunicorn and display pages via HTTPS:
- Both default settings:
Nginx setting: proxy_set_header X-Forwarded-Proto $scheme;
Django setting: SECURE_PROXY_SSL_HEADER = None
Result: No redirect. I'm not getting a ERR_TOO_MANY_REDIRECTS complain from Chrome.
- Use default setting in nginx; use a wrong setting in Django, i.e. the 'httpsssss' part:
proxy_set_header X-Forwarded-Proto $scheme;
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'httpssssssss')
No redirect.
- Use default setting in nginx; use a wrong setting in Django:
proxy_set_header X-Forwarded-Proto $scheme;
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTASDF', 'httpssssssss')
No redirect.
- Use custom HTTPS indicator in both nginx and Django:
proxy_set_header X-Forwarded-Protooo $scheme;
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTOOO', 'https')
No redirect. This is the expected behavior.
- Use custom HTTPS indicator in both nginx and Django, and testing for a unsafe protocol ( != 'https'):
proxy_set_header X-Forwarded-Protooo $scheme;
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTOOO', 'httpsssss')
Chrome complains ERR_TOO_MANY_REDIRECTS. This is the expected behavior.
- A fix testing by myself:
Add an else clause under these lines.
else:
return 'http'
And set:
proxy_set_header X-Forwarded-Proto $scheme;
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'httpssssssss')
Chrome would report the expected ERR_TOO_MANY_REDIRECTS.
Did someone forget to add the else clause, or there are 3 'http' 'ftp' and 'ftps' scheme left?
If a site use 5. An attacker may set request X-Forwarded-Proto header to bypass the HTTPS check and result in 1,2,3.
Change History (5)
follow-up: 3 comment:1 by , 9 years ago
| Component: | contrib.redirects → HTTP handling |
|---|
comment:2 by , 9 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 9 years ago
Replying to Tim Graham:
I'm having trouble understanding the report. What is the second line in each item (e.g.
HTTP_X_FORWARDED_PROTO=Nonesupposed to represent? Values of the SECURE_PROXY_SSL_HEADER setting? By the way, if there is a security issue here, please report the issue to the security team.
Yes your guess is right. Django sets HTTP_X_FORWARDED_PROTO to None by default as the link you provided tells. I've updated the main thread to make it more clear.
I think this is a small issue so not reported it to the security team. Since normally we do a HTTP to HTTPS redirect in nginx by this setting listen: 80; return 302 https://$server_name$request_uri;
comment:5 by , 9 years ago
| Description: | modified (diff) |
|---|
There are 2 bug cases:
- In case 1, with no Django complain, user don't know whether his/her setting is correct and whether the HTTPS setup correctly.
- In case 4, using a custom header by admin, a MITM may happen by:
user -- HTTP -- MITM(retrive password, set header: HTTP_X_FORWARDED_PROTO: https) -- nginx(header: HTTP_X_FORWARDED_PROTO: https, set header: HTTP_X_FORWARDED_PROOO: http) -- gunicorn(Pass, no user redirect because HTTP_X_FORWARDED_PROTO == https) -- Django(is_secure() == True because there's no else clause).
comment:6 by , 9 years ago
| Description: | modified (diff) |
|---|
I'm having trouble understanding the report. What is the second line in each item (e.g.
HTTP_X_FORWARDED_PROTO=Nonesupposed to represent? Values of the SECURE_PROXY_SSL_HEADER setting? By the way, if there is a security issue here, please report the issue to the security team.