Closed
Bug 1249450
Opened 9 years ago
Closed 9 years ago
Audit SetScheme() calls and use HttpBaseChannel::GetSecureUpgradedURI for HTTP->HTTPS conversions where appropriate
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla48
People
(Reporter: dholbert, Assigned: dholbert)
References
Details
(Whiteboard: [necko-would-take])
Attachments
(2 files)
(deleted),
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
We still have several bits of code that call
SetScheme(NS_LITERAL_CSTRING("https"));
on an http-flavored nsIURI, to upgrade it to HTTPS.
Depending on how these URIs are used, they're all potentially at risk of failing equality comparisons against other URIs that they should really be equal to. (More things like bug 1247733, basically.)
Really, we shouldn't have any hardcoded SetScheme calls -- we should use the newly-improved HttpBaseChannel::GetSecureUpgradedURI function. (improved in bug 1247733)
Based on an MXR search[1], I think there are two places that need this treatment:
http://mxr.mozilla.org/mozilla-central/source/dom/html/HTMLFormElement.cpp?rev=0a5df57a56e4#1753
http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpHandler.cpp?rev=28069d20b125#2178
The MXR search I used for this audit was:
http://mxr.mozilla.org/mozilla-central/search?string=SetScheme.*https®exp=1&find=&findi=&filter=^[^\0]*%24
...which turns up 4 hits -- the above-linked 2 places, plus the SetScheme call in HttpBaseChannel::GetSecureUpgradedURI (which is now OK), plus one websocket SetScheme call which only happens for "wss" URIs (which should also be OK from the perspective of this bug -- they should already have the correct mDefaultPort I believe).
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(dholbert)
Updated•9 years ago
|
Whiteboard: [necko-would-take]
Assignee | ||
Comment 1•9 years ago
|
||
This first patch just moves this upgrade-URI-to-https function from its current location to nsNetUtil, for broader availability.
(It only lives in HttpBaseChannel for historical reasons, I think.)
(We need this part because we can't #include HttpBaseChannel.h at the dom/html/HTMLFormElement.cpp callsite, because HttpBaseChannel.h itself has an #include for some other header which is not exported.)
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
Flags: needinfo?(dholbert)
Assignee | ||
Updated•9 years ago
|
Attachment #8728660 -
Flags: review?(mcmanus)
Assignee | ||
Comment 2•9 years ago
|
||
Attachment #8728668 -
Flags: review?(mcmanus)
Assignee | ||
Updated•9 years ago
|
Attachment #8728660 -
Attachment description: part 1: move GetSecureUpgradedURI to nsNetUtil → part 1: move GetSecureUpgradedURI to nsNetUtil (no functional changes)
Comment 3•9 years ago
|
||
Comment on attachment 8728660 [details] [diff] [review]
part 1: move GetSecureUpgradedURI to nsNetUtil (no functional changes)
Review of attachment 8728660 [details] [diff] [review]:
-----------------------------------------------------------------
thanks for this. lgtm
Attachment #8728660 -
Flags: review?(mcmanus) → review+
Updated•9 years ago
|
Attachment #8728668 -
Flags: review?(mcmanus) → review+
Comment 5•9 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9782ea9f33da
https://hg.mozilla.org/mozilla-central/rev/0c1e74f83b41
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in
before you can comment on or make changes to this bug.
Description
•