If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Corrupted Content Error should allow access to the page anyway if possible.

RESOLVED WONTFIX

Status

()

Core
Networking: HTTP
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: Peep Chaintreuil, Assigned: jduell)

Tracking

7 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [evang-wanted])

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20111017182456

Steps to reproduce:

Go to a page that will issue a corrupted content error.  See bug #690202 or #681140 for possible examples.


Actual results:

I get a Corrupted Content Error error instead of the page.


Expected results:

I should get the error, but be able to say, "I understand, but I want that page anyway."

I cannot fix other people's servers, but I may need access to the content they provide and know that the error is harmless.  (Like self-signed certificate warnings.)

For instance, I am currently getting this from one of Apple's webservers.  And they're not going to care too much: they're just going to tell me to use Safari.
> "I understand, but I want that page anyway."

The problem is that the corrupted content error only happens for pages that look like they're subject to an active MITM.

If we allowed people to just click through they would be more or less automatically screwed.

The self-signed cert warning _might_ be the right level, but since there are no legitimate use cases for responses that the corrupted content error shows up for, the bar should arguable be higher....

> I am currently getting this from one of Apple's webservers. 

Which one?
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
(Reporter)

Comment 2

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #1)
> The problem is that the corrupted content error only happens for pages that
> look like they're subject to an active MITM.

  But that's not the case, both of the previous mentioned bugs are because a webserver is sending non-standard headers.  One that repeated a header and one that had a semi-colon on the end.  Neither of them are Man-in-the-middle attacks, they're bugs.

> > I am currently getting this from one of Apple's webservers. 
> Which one?

https://developer.apple.com/appstore/resources/submission/  But you'll need a developer account to log in to see the actual page.
(Assignee)

Comment 3

6 years ago
@peep,

Right, but from the browser's perspective, seeing duplicate, non-identical HTTP headers like Content-Length or Content-Disposition is indistinguishable from an injection attack.  I.e. it's a server bug that we can't distinguish from a real attack.  So servers are going to have to fix their bugs.  

I could have been persuaded to allow the semicolon after Content-Length, but now that's it shipped, we might as well enforce the spec.
(Reporter)

Comment 4

6 years ago
(In reply to Jason Duell (:jduell) from comment #3)
> [...] from the browser's perspective [...]

    Which is exactly my point: I know more than the browser, so let me say so.

    I'm not saying that the browser shouldn't warn and complain, I'm just saying that I should be able to say, "I understand, but continue anyway."

    https://secure.wikimedia.org/wikipedia/en/wiki/Robustness_Principle
Some causes of corrupted-content are not recoverable anyway, e.g. duplicate headers with different values that are clearly violation or potential MITM.  Imagine that situation for two values of Content-Length.  You cannot just ignore them, you manually have to decide which header to use and tell the browser explicitly.

That would be overkill and no one working on the necko code would work on something that complex and disputable.  Also it is not protecting inexperienced users from allowing just the bad header to go through.

If you believe there are things we should allow that are not against specs and break page loads, then create concrete bugs with concrete test cases and arguments.  Then we can fix them if confirmed as issues.

I suggest to close this as WONTFIX or, better, INVALID.

Comment 6

6 years ago
I will not be very helpful about how to fix this issue as I'm not aware of all the problems that it implies, however, as a user, I'd like to say that keeping this behavior seems not user friendly to me:

I also had the issue on the Apple Developer website, thinking the website was down. I got back the day after and still got the issue. I wanted to send an issue report to Apple but first I tried with Safari and Chrome and it worked.

Still as a user, this makes me think about using Safari or Chrome as my preferred web browser instead of Firefox (but I don't want it as I want to stay on a full free software) and I guess some other users may think the same way by simply thinking that Firefox is not working.
(Reporter)

Comment 7

6 years ago
(In reply to Honza Bambas (:mayhemer) from comment #5)
> That would be overkill and no one working on the necko code would work on
> something that complex and disputable.  Also it is not protecting
> inexperienced users from allowing just the bad header to go through.

I am not requested that any additional logic be added to do anything more than what worked with version 6.

By analogy, I am saying that I can see that the yellow lines on the road are not precisely #EED202, but that they are more orange in tinge.  A reasonable person can understand that thing may not go just right and request to continue at their risk.  I feel that you are saying, "I cannot allow you to drive down this road, the color of the line isn't to spec so it has to be closed.  I know you do not own this road, and that you need to travel down it, but that's too bad."

I still say this is similar to many cert warnings.  A self-signed cert or a cert that doesn't mention the current domain are cert warnings, but Firefox allows people to continue to those sites after warning them.  Both of these may indicate MITM issues, but I -- as a human -- can inspect the information and decide if it is a MITM issue or if it's just that I used a strange URL to get to this site and it's safe to continue.

I'm not saying that such a warning shouldn't be scary, and should require a few clicks (like the cert error bypass), I'm just saying that I should be able to ask to continue anyway, even if there's an extra semicolon or some other minor issue.  If Firefox crashes because of the semicolon: I understand the reason, you tried your best, I asked to do something sketchy, so be it.

Comment 8

6 years ago
At the moment the "Corrupted Content error" doesn't tell you anything.
When this error happens, I can't get the post request from the 'live http headers' addon,  so it's hard to quickly duplicate it on the server.

It should at least say, the header 'content-length:....' is incorrect, duplicate, etc.  Or dump the header on the screen/logs or something.

Press ctrl-shift-j, go to 'warnings'.  Go to any website.  There're lots of things out there that don't comply with the spec.  At one point does it become a crippling 'you can't go into this page no matter what error' instead of going into the warnings/errors logs?

Comment 9

6 years ago
https://developer.apple.com/library/prerelease/ios/navigation/ also gives the corrupted content warning...

It's getting annoying having to launch Safari to check iOS API stuff. As Mozilla have an app in the Apple AppStore (Mozilla Home) it's not very reassuring to see that even Mozilla don't use Firefox as their browser...

I too would like an equivalent warning like the certificates. A dodgy certificate can be a sign of an attack yet we can still accept the risks and enter the site. What's the difference with the corrupted content 'error'?

MaFt

Comment 10

6 years ago
I am having actually this error when connecting to a web interface built on Oracle's PeopleSoft from an updated nightly version (all plugins disabled, tested on Debian Squeeze x64). I don't have this problem when using FF version 9 (nor IE).

As people mentioned before me, there is no help on the error (no returned headers) to identify it clearly or bypass it if it is a simple warning.

Comment 11

6 years ago
Looks like chrome are also doing the same thing, blocking pages with faulty headers...
http://www.google.com/support/forum/p/Chrome/thread?tid=1e87c7cc5c85b8b1&hl=en

Comment 12

6 years ago
Similar to ronan, I'm getting this error for a web interface built on PeopleSoft (using FF nightly).  PLEASE add an option to "Ignore this warning".  FF isn't being helpful at all when I just open Chrome then to get to the page and go about my business.  It's the employee record database for my university....I'm not concerned that it's an attack server.
@thegizmoguy can you paste in the response headers (even if you have to use an older version in conjunction with livehttpheaders or something)?

I want to see if this is an exploitable case or not. If it is, then I won't want to change any behavior. Relying on user's assessment of security context is not reliable. But if we're over reaching, then let's make a change.

for that we need to see the data - not just the error message.
(Reporter)

Comment 14

6 years ago
Hey Patrick: Thanks for working with us on this instead of just dismissing us.  I appreciate it.  I'll see if I can still get this to happen with the Apple pages too for a second case.
(Reporter)

Comment 15

6 years ago
Nuts, Apple changed their page redirect so I can't reproduce the bug there anymore.

Comment 16

6 years ago
@Patrick McManus

I sent an email to thegizmoguy and it appears that we are using the same system. Using Firefox 10, there is no error. For the page that seems to cause the error under 12.0a1 the header response for FF10 is : 

Connection:close
Content-Encoding:gzip
Content-Length:2406
Content-Type:text/html; 
CHARSET=UTF-8
Date:Wed, 01 Feb 2012 18:36:46 GMT
Expires:Wed, 01 Feb 2012 18:56:46 GMT
Last-Modified:Wed, 01 Feb 2012 18:36:46 GMT
Set-Cookie:sa-rserver=R11111111111; path=/
https%3a%2f%2fstudent851.uaccess.arizona.edu%2fpsp%2fuazsaprd%2fua_student%2fhrms%2frefresh=list:%20|; domain=.uaccess.arizona.edu; expires=Wednesday, 01-Feb-2012 18:56:46 GMT; path=/; secure
PS_TOKENEXPIRE=1_Feb_2012_18:36:46_GMT; domain=.uaccess.arizona.edu; path=/; secure
X-Powered-By:Servlet/2.5 JSP/2.1ignoreportalregisteredurl:1
portalregisteredurl:https://student851.uaccess.arizona.edu/psc/uazsaprd/UA_STUDENT/HRMS/s/WEBLIB_PORTAL.PORTAL_HOMEPAGE.FieldFormula.IScript_HPPoweredBy
usesportalrelativeurl:true
@ronan.kerviche@free.fr

first, I apologize for the delay. I've been traveling and stuff queues up.

second, the advice I gave to use "livehttpheaders or something" was bad advice. I do indeed need to see those headers, but those mechanisms show me the parsed headers not the raw ones. So for example in comment 16 it shows me that FF10 interpreted the headers to mean it had a content-length of 2406.. but the raw headers could have been:
"Content-Length: 2406
 Content-Length: 1200"

in which case rejecting this as a security problem is the right thing to do.. but they could have also said something like:
"Content-Length: 2406;" in which case the CORRUPTED_CONTENT throw is, imo, an overstep.

do you have experience with something like wireshark to get an outside view into the data?

another option would be redbot.org if the url is reachable by a public service.

if neither of those works for you, how about http logging? https://developer.mozilla.org/en/HTTP_Logging

Again, my sincerest apologies for the extra round trip here. I know it takes time to provide the input and I really appreciate it.

Comment 18

6 years ago
Thank you Patrick for following this! 

The page is not public, so I tried the logging process, on the same machine for the two versions (Debian x64)... and it's the jungle there, the page is lost into dozens of redirections... But I think I found the correct one in the log file :

1649407744[7faa73f549d0]: http response [
1649407744[7faa73f549d0]:   HTTP/1.1 200 OK
1649407744[7faa73f549d0]:   Set-Cookie: sa-rserver=R11111111111; path=/
https%3a%2f%2fstudent851.uaccess.arizona.edu%2fpsp%2fuazsaprd%2fua_student%2fhrms%2frefresh=list:%20|%3frefresh_all_pagelets%3ddefault; domain=.uaccess.arizona.edu; expires=Tuesday, 07-Feb-2012 03:13:39 GMT; path=/; secure
PS_TOKENEXPIRE=7_Feb_2012_02:53:39_GMT; domain=.uaccess.arizona.edu; path=/; secure
1649407744[7faa73f549d0]:   Date: Tue, 07 Feb 2012 02:53:38 GMT
1649407744[7faa73f549d0]:   Content-Length: 2409
1649407744[7faa73f549d0]:   Content-Type: text/html; CHARSET=UTF-8
1649407744[7faa73f549d0]:   Expires: Tue, 07 Feb 2012 03:13:39 GMT
1649407744[7faa73f549d0]:   Last-Modified: Tue, 07 Feb 2012 02:53:39 GMT
1649407744[7faa73f549d0]:   ignoreportalregisteredurl: 1
1649407744[7faa73f549d0]:   Content-Encoding: gzip
1649407744[7faa73f549d0]:   portalregisteredurl: https://student851.uaccess.arizona.edu/psc/uazsaprd/UA_STUDENT/HRMS/s/WEBLIB_PORTAL.PORTAL_HOMEPAGE.FieldFormula.IScript_HPPoweredBy
1649407744[7faa73f549d0]:   X-Powered-By: Servlet/2.5 JSP/2.1
1649407744[7faa73f549d0]:   usesportalrelativeurl: true
1649407744[7faa73f549d0]:   Connection: close
1649407744[7faa73f549d0]: ] 

Other informations I found (I hope they are correct)

The corresponding request on FF9 (lead to success)
1964693280[7faa73f54150]: http request [
1964693280[7faa73f54150]:   GET /psp/uazsaprd/UA_STUDENT/HRMS/h/?tab=DEFAULT HTTP/1.1
1964693280[7faa73f54150]:   Host: student851.uaccess.arizona.edu
1964693280[7faa73f54150]:   User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110923 Firefox/9.0a1
1964693280[7faa73f54150]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
1964693280[7faa73f54150]:   Accept-Language: en-us,en;q=0.5
1964693280[7faa73f54150]:   Accept-Encoding: gzip, deflate
1964693280[7faa73f54150]:   Connection: keep-alive
1964693280[7faa73f54150]:   Referer: https://shibboleth.arizona.edu/idp/Authn/RemoteUser?ticket=ST-3077579-Kpqst4bjngNFszfa3DfH-vincent.uits.arizona.edu
1964693280[7faa73f54150]:   Cookie: SOME_COOKIE
1964693280[7faa73f54150]: ]

The corresponding request on FF13 (lead to failure)
-2085619936[7fa982854150]: http request [
-2085619936[7fa982854150]:   GET /psp/uazsaprd/UA_STUDENT/HRMS/h/?tab=DEFAULT HTTP/1.1
-2085619936[7fa982854150]:   Host: student851.uaccess.arizona.edu
-2085619936[7fa982854150]:   User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120206 Firefox/13.0a1
-2085619936[7fa982854150]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-2085619936[7fa982854150]:   Accept-Language: en-us,en;q=0.5
-2085619936[7fa982854150]:   Accept-Encoding: gzip, deflate
-2085619936[7fa982854150]:   Connection: keep-alive
-2085619936[7fa982854150]:   Referer: http://uaccess.arizona.edu/
-2085619936[7fa982854150]:   Cookie: SOME_COOKIE
-2085619936[7fa982854150]: ]

On FF13 : there is no http response visible in the log, but following the request, I found this part :
1897920256[7fa9828548c0]: nsHttpTransaction::ProcessData [this=5e2ee120 count=1391]
1897920256[7fa9828548c0]: nsHttpTransaction::ParseHead [count=1391]
1897920256[7fa9828548c0]: nsHttpTransaction::ParseLine [HTTP/1.1 200 OK]
1897920256[7fa9828548c0]: nsHttpResponseHead::ParseVersion [version=HTTP/1.1 200 OK]
1897920256[7fa9828548c0]: Have status line [version=11 status=200 statusText=OK]
1897920256[7fa9828548c0]: nsHttpTransaction::ParseLine [Set-Cookie: sa-rserver=R1111111111; path=/]
1897920256[7fa9828548c0]: nsHttpTransaction::ParseLine [Date: Tue, 07 Feb 2012 03:11:05 GMT]
1897920256[7fa9828548c0]: nsHttpTransaction::ParseLine [Location: ]
1897920256[7fa9828548c0]: nsHttpTransaction::Close [this=5e2ee120 reason=804b001d]
1897920256[7fa9828548c0]: nsHttpConnectionMgr::ReclaimConnection [conn=5d40b320]
1897920256[7fa9828548c0]: STS dispatch [7fa95d4bd340]
1897920256[7fa9828548c0]: nsHttpConnection::CloseTransaction[this=5d40b320 trans=5e2ee120 reason=804b001d]
1897920256[7fa9828548c0]: nsHttpTransaction::Close [this=5e2ee120 reason=804b001d]
1897920256[7fa9828548c0]:   already closed

Which makes me think that the response is really truncated but I don't know why...
(In reply to ronan.kerviche from comment #18)
> 1897920256[7fa9828548c0]: nsHttpTransaction::ParseLine [Location: ]

That's an empty Location response header. Thanks for the logs.

I need to consider whether or not that is something we can tolerate. It might smack of CRLF injections, which are a legitimate problem, but there is no reason to think Location is a special case of them compared to any other respone header.

boris, jason, honza, opinions specifically on empty non-duplicated location header?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
I think allowing (and ignoring) empty non-duplicated Location headers should be fine...
(In reply to Boris Zbarsky (:bz) from comment #20)
> I think allowing (and ignoring) empty non-duplicated Location headers should
> be fine...

actually, it turns out not so much now that I research it again. We've got a security bug, still waiting for disclosure, involving a XSS exploit with it. so this will stay wontfix.
(Assignee)

Comment 22

6 years ago
mcpherrin tells me that PeopleSoft servers at U Waterloo send empty Location headers.  PeopleSoft is a big one to break...
As Jason mentioned, I've seen this on Waterloo's Quest and Jobmine services (both custom peoplesoft monstrosities). 

It seems fairly rare; I haven't figured out STR yet. Hopefully can just be fixed in PeopleSoft stuff.
(In reply to Jason Duell (:jduell) from comment #22)
> mcpherrin tells me that PeopleSoft servers at U Waterloo send empty Location
> headers.  PeopleSoft is a big one to break...

the problem is this particular case has a confirmed xss associated with it (as well as being out of spec). evang is probably the right route.
Component: Networking → Networking: HTTP
QA Contact: networking → networking.http
Whiteboard: [evang-wanted]

Comment 25

6 years ago
Can an about:config option be added to disable checking for these errors?  Don't really care about there being "security" issues with it and an about:config option isn't something that an average user would come across.
Duplicate of this bug: 727495

Updated

6 years ago
Duplicate of this bug: 738122
(Assignee)

Comment 28

6 years ago
I'm going to investigate whether we're being stricter here than chrome.  My understanding has been that both Firefox/Chrome are cracking down on empty/duplicate Location headers.
Assignee: nobody → jduell.mcbugs

Comment 29

6 years ago
I can tell you that I can login no problem using Chrome 17 (release) but get a corrupted content error with FF 13a2.
(Assignee)

Comment 30

6 years ago
@thegizmoguy: if you could provide a URL (and ideally, a wireshark log showing the HTTP headers the server sent) that would be useful.

Comment 31

6 years ago
@Jason Duell

They are the same as mine : see comment 18.

Comment 32

6 years ago
(In reply to thegizmoguy from comment #29)
> I can tell you that I can login no problem using Chrome 17 (release) but get
> a corrupted content error with FF 13a2.

Can someone test with the newly stable Chrome 18?
A side note: the error page for cases we still want to block should say why exactly we block (what headers are invalid or dupped and with what values) to let more experienced users potentially decide and override..  Similar to cert error page with "technical details".
I can test if someone points me to a public url... I tried recreating the empty Location nit, and Apache simply won't let me do that with a CGI script.  :(
http://pex.jp/ (via Bug 738122)
Thanks.  Chrome 19 dev happily loads that URI.

I wonder whether it makes sense to ignore the Location header altogether on non-3xx response, actually...
Re-opening since Jason is investigating this.

(In reply to Boris Zbarsky (:bz) from comment #36)
> I wonder whether it makes sense to ignore the Location header altogether on
> non-3xx response, actually...

That seems reasonable to me, if you change it to "gnore the Location header altogether on all responses where we would ignore it anyway." There are non-3xx responses where Location is relevant, e.g. 201 for a POST; I am not sure we do anything with them though. Then, we would just need to ignore the Location header unless the (request method, response status) is in some kind of whitelist. We could do this in some new method; e.g. nsresult nsHttpResponseHead::GetLocation(nsHttpAtom requestMethod, nsCString & value) that would be responsible for checking the response status code and request method against a whitelist.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Jason is dealing with this in a another bug (742174).
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.