Closed
Bug 354180
Opened 18 years ago
Closed 18 years ago
cookie implementation ignores rfc 2965, section 3.3.6 on sending/accepting cookies from foreign sites
Categories
(Firefox :: Security, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 200716
People
(Reporter: garbandi66-mozilla, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060921 Ubuntu/dapper-security Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.7) Gecko/20060921 Ubuntu/dapper-security Firefox/1.5.0.7
i've send this bugreport via email to security@mozilla.org about a week ago. but i've got no response till today, so i'll give it a try on bugzilla:
after some checks, it seems, that current browsers (including firefox 1.5.0.5) have a huge security leak for all websites, that depend on modern ajax-frameworks which use javascript as data-transport-language. but event for old-school-html-based appliations, session theft for requests is easly possible.
the problem seems to be, that the browser ignores section 3.3.6 of rfc 2965 for the script tag (and others). according to the rfc (if i unterstand it right), it should be impossible, that a request to host B contains a B-host cookie, when the request is automaticaly initiated from a page delivered from host A.
unfortunalely (according to the livehttpheaders plugin) firefox ignores this rule in several places.
a short example shows the security problem:
assume you have a request-url for host B, which, depending on the a user's session (managed via a session-cookie), creates some java-script-code. the java-script puts some personal data of the current user in variable x (which is a typical scenario for many modern ajax-frameworks that use java-script as "data-transfer-language")
assume now a page on host A, with the following code:
<html>
<head>
<script src="http://hostB.yyy.zz/dynamic/data/request.js" />
</head>
<body>
<script>
alert("personal data from hostB:"+x);
</script>
</body>
</html>
if a user who has an open and valid session on host B, visits this page on host A, his personal data is visible in the context of A's page, as long as the browser creates a http-request for the script tag, that includes the user's session-cookie.
there is no need for the attacker, to change anything on host B. it's sufficient, that there is an open session.
i haven't tried yet, but i expect that this should even happen when the request to host B is protected via https.
from my point of view, this is a major security bug. it should be fixed as soon as possible, since it allows external sites to interact with other ajax-based applications in other peoples session. it easily allows both:
- retransmitting personal data from host B to host A, and
- execution of arbitrary requests on host B.
the second case is not limited to ajax-based applications.
because more and more websites use these technologies and nobody seems to have knowledge of this problem, this is of high risk for many current and upcoming applications.
i have checked some html-tags to see whether the problem is limited to the script-tag implementation. "img" and "iframe" work correct, but others share the problem: "link", "meta http-equiv="refresh". even if in these cases, there is no way for the attacker to read the response-data, unauthorized request in the other session-context through these tags are possible too!
special care has to be taken with plugins like flash/shockwave that allow the creation of internal http-requests. if these requests are processed through the browser, it has to be ensured, that they don't contain the browser's cookies, if the requested host is different from that of the page (or that of the flash-movie???)
if i understand the rfc intention right, even using javascript to change the url of the current window to another host, has to prevent the transfer of the cookie (but doesn't)! without, it's easy to bypass the correct behaviour of the iframe-tag.
please keep me updated -- especially if i im wrong, or just misunderstood the rfc. because then, it would be my responsiblity to find a solution for solving this kind of cookie/session-theft for a secure application.
Reproducible: Always
Steps to Reproduce:
1. create a html-page that includes some java-script of an external site that uses cookies
2. visit the external site with your browser to receive a cookie
3. open the live-http-headers view
4. open your new created html-page in a new browser-window to load the java-script from the external site
Actual Results:
you'll see how your local html-page uses the cookie of the site in the other open window
Expected Results:
accoring to the rfc: neither send, nor accept cookies from the foreign site.
from my point of view, an implementation according to the rfc is secure, but would prevent many reasonable opportunities.
i would prefer some kind of "origin-local-cookies", that are only valid within request of pages, that match with the "same-origin-policy". that way a page would include java-script code from foreign pages AND use cookies of that site. but these cookies would not interfer with cookie, that i receive, when i visit the foreign site's html-pages.
|
||
Updated•18 years ago
|
Group: security
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•