Closed Bug 1373295 Opened 7 years ago Closed 7 years ago

Encoded slashes in url allow misleading text on unstyled 404 pages due to AllowEncodedSlashes

Categories

(bugzilla.mozilla.org :: General, defect)

Production
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: vaibhavchhabra800, Assigned: dylan)

Details

Attachments

(2 files)

Attached image bugzillabug.png
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Steps to reproduce:

Vulnerable URL-->

https://bugzilla.mozilla.org//www.google.com%20%20has%20been%20moved%20tempoarily%20.Please%20visit%20www.attacker.com%20The%20Present%20Resource%20%2f/www.google.com%2f


Actual results:

I received this

Not Found

The requested URL /www.google.com has been moved tempoarily .Please visit www.attacker.com The Present Resource //www.google.com/ was not found on this server.


Expected results:

URL supplied should have been hidden
Seems like an oversight of the httpd config.

That should display our custom 404 page...

:atoll, suggestion on a fix?
Flags: needinfo?(rsoderberg)
Find the Redirect statement that's missing a trailing slash from https://domainname
Flags: needinfo?(rsoderberg)
OH. Yeah, so, heh. This is something EIS wants us to fix on all Mozilla properties.

I assume the request isn't being sent to your mod_perl handler at all since it starts with //.

ErrorDocument 404 to a static page will protect against the issue sufficiently for you to close this bug.
Summary: TExt Injection(Content Spoofing) → Complex URL triggers Apache default 404 page, which permits content spoofing
ErrorDocument 404 is already present.
That's very odd. Uh. Is there a self-proxy in play here somehow?
note it's %2f. real-slash is fine, but %2f is being handled farther up the apache pipeline.

https://bugzilla.mozilla.org/www./stuff

https://bugzilla.mozilla.org/www.%2fstuff
I don't think there is any value in marking this private after it's been public for this long.
Also, I don't think /unstyled pages/ are that vulnerable to attack.

That said, this is a common misconfiguration:

http://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes
Group: bugzilla-security
:fubar, can we set AllowEncodedSlashes to NoDecode? The application should do the right thing at that point.
Component: General → Infrastructure
Flags: needinfo?(klibby)
QA Contact: mcote
Summary: Complex URL triggers Apache default 404 page, which permits content spoofing → Encoded slashes in url allow misleading text on unstyled 404 pages due to AllowEncodedSlashes
(In reply to Dylan Hardison [:dylan] (he/him) from comment #9)
> :fubar, can we set AllowEncodedSlashes to NoDecode? The application should
> do the right thing at that point.

This option was added in Apache 2.3.12.
Okay, then we're going to need to have zeus redirect any request containing %2f (or the backslash) to /errors/404.html
Alternatively, saying ErrorDocument /erorrs/404.html at the top-level apache config seems to work as well.
Technically this is a bad default for infra, but since my application has total control over the httpd config...
I can feed the right config to apache at mod_perl startup time.
Assignee: nobody → dylan
Status: UNCONFIRMED → ASSIGNED
Component: Infrastructure → General
Ever confirmed: true
QA Contact: mcote
Flags: needinfo?(klibby)
Attached file PR
Attachment #8881652 - Flags: review?(rsoderberg)
Comment on attachment 8881652 [details] [review]
PR

This should be pretty easy to test. With this patch applied, %2f in the URL doesn't give a default (unstyled, black and white) error message.
Attachment #8881652 - Flags: review?(rsoderberg) → review?(sebastinssanty)
Attachment #8881652 - Flags: review?(sebastinssanty) → review+
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Dylan Hardison [:dylan] (he/him)
It is still working ,it has NOT BEEN FIXED  
Please I am asking for the third time please let me know if i will be awarded for it or not in any way ?
The changes aren't pushed till now. FIXED just means that the code has been merged into the codebase, but it doesn't mean that the code is pushed to the production servers. AFAIK a push is done once a week.
(In reply to Vaibhav Chhabra from comment #19)
> Please I am asking for the third time please let me know if i will be awarded for it or not in any way ?

For bounty-related questions please mail our security alias as described in our bug bounty guidelines. It is off-topic for the bug itself which should remain focused on fixing the bug.
Flags: sec-bounty? → sec-bounty-
Content injection on unstyled pages is not eligible for a bug bounty.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: