Closed Bug 155768 Opened 22 years ago Closed 22 years ago

solo.nordea.fi - unable to login to service (problem with cookies)

Categories

(Tech Evangelism Graveyard :: Other, defect)

Product:
Tech Evangelism Graveyard
Component:
Other
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: emaijala+moz, Assigned: tristan)

References

(
URL
)

Details

Solo banking service worked fine using the trunk build from 2nd July, but is
broken in 20020703. Complains about temporary cookies not working. The english
version is available at
https://solo3.nordea.fi/cgi-bin/SOLO0001?A01Y_LANF=3&A01Y_MASTER=1. Can be
tested using customer number 123456 and password 1111.
linux trunk cvs 2002-07-04:

"Http error 404: Session control information missing. Temporary session Cookie
usage is required." (error web page)

Same result if accepting all cookies or only from originating site.

wfm with 2002-06-21-08-trunk.
OS: Windows 2000 → All
Also works with 20020702, so it has been broken between these two builds. There
seems to be a checkin of some cookie fix yesterday.
Yes. bug #155114 unfortunately not accessible
It's accessible to me.  I'll investigate.
Status: NEW → ASSIGNED
The RFC2109 cookie spec section 4.3.2 states the conditions under which a 
set-cookie request shall be rejected.  Namely:

> 4.3.2 Rejecting Cookies

> To prevent possible security or privacy violations, a user agent rejects
> a cookie (shall not store its information) if any of the following is true: 
>
>   * The value for the Path attribute is not a prefix of the request-URI.

This particular site is attempting to set the cookie SoloSessionMac with a path 
attribute and requesting URI as follows:

   path attribute: /cgi-bin/S4zRggxhEm
   requesting URI: /cgi-bin

So the site is attempting to set a cookie for a path that it does not control, 
and the browser is wise to reject it.  That is one part of the patch for the 
security bug 155114 that you cannot see.

Unfortunately, this rule has never been enforced before by any version of 
mozilla, nor by N4.x, nor by IE.  So suddenly we are breaking sites that are 
setting bad cookies and, IMO, deserve to be broken.  Depending on the number and 
importance of the sites broken, we might either (1) consider this as an 
evengalism issue and tell the sites to fix their cookies, or (2) back off part 
of the security patch and allow sites to set such potentionally-hostile 
cookies.  I will raise this issue in bug 155114.
Marking this as a security-sensitive bug since it involves other bugs that are 
security-sensitive.
Group: security?
Considering this particular service (I think there might be others broken too)
this is a serious problem for Finnish users (and possibly also Swedish etc.) as
I believe the amount of Solo users is hundreds of thousands in many countries.
If it's not possible to back out this part of the patch, I'd give the user a
possibility to accept the cookie (a dialog perhaps). 
In bug 155114 you said IE was not vulnerable to the attack, but this site
clearly works with IE. What would we have to relax to get this site working,
while still preventing the attack as IE does? If we can do that it might be good
enough, and be guaranteed compatibility with most of the web.
Dan, see my comments in bug 155114 comment 15.

As I explained there, there are issues with both setting of cookies and the 
getting of cookies.  The attack in bug 155114 was based on the getting of 
cookies.  The breaking of this website is based on the setting of cookies.

IE is not respecting RFC 2109 regarding the setting of cookies, which is why 
they are not breaking this site.  They are respecting it regardig the getting of 
cookies, which is why they are not vulnerable to the attack in bug 155114.
Is there any progress regarding this in bug 155114? I'm asking because I can't
access that one and this problem is a blocker bug for me.
That bug report is currently concerned with what we land on the branch (which 
will be the Netscape 7 product) and is leaning toward landing the part of the 
patch for the getting of cookies only.  That way we will plug the security hole 
in the Netscape product while not breaking any more sites that we don't know 
about.

However the feeling is that we keep the full patch on the trunk since that 
brings us into conformance with the standard, and see if we get reports of any 
other broken sites.  If it is only this one site that is broken, then this is 
probably best handled as an evangelism issue -- i.e., explain to the site 
webmaster that there is an error on his site and ask him to correct it. 
The decision was made to back out part of the bug 155114 patch on the branch 
only.  Actually that patch was a composite patch for two bugs (the other being 
bug 155083), and it was the 155083 part that was backed out.

This will remain on the trunk however, and is now an evangelism issue.  
Reassigning.
Component: Cookies → Europe: Central
Product: Browser → Tech Evangelism
Version: other → unspecified
Really reassigning this time.
Assignee: morse → piskozub
Status: ASSIGNED → NEW
QA Contact: tever → pali
Hmm.. does this still need to be security-sensitive?

I've sent a query to Nordea about the issue. They don't seem to publish email
addresses, but feedback can be given through their web pages. 
Note: while the RFC says this is a security issue, it certainly isn't a major
one, if it's really one at all.  Setting a path in the cookie that's deeper than
the current URL isn't actually dangerous; setting it with a shallower one could
also be dangerous (think about setting a cookie for my.hosting.service/ from
my.hosting.service/~evil_user/index.html - if my.hosting.service/~good_user keys
off the cookie for the wrong things, someone accessing ~good_user might cause
~good_user's page to mis-behave or even send data to the wrong person).

What I imagine they were worried about was my.hosting.service setting the cookie
for my.hosting.service/~someones_dir.  However, generally someone who has access
to parent directories of URL's has more control, not less, so I don't see this
as a true security issue.

In the example from bug 155114, if mywebpage.netscape.com/stephen sets a cookie
for path mywebpage.netscape.com/stephen/pictures, it really isn't any form of
security hole that I can see.  It only would be a security hole if it let you
set a cookie for mywebpage.netscape.com/stephenmpmorse.  So I think the RFC is
overly paranoid.  (BTW, if IE and NS4 allowed this, what about the attack I just
mentioned?  Do they allow it, or do they require deeper paths to have a '/'
after the current path?)

Is this really true, BTW?

   path attribute: /cgi-bin/S4zRggxhEm
   requesting URI: /cgi-bin

Requesting URI seems unlikely to be just "/cgi-bin".  I'd think it was more
likely /cgi-bin/something, and the /something was stripped before
cookie_pathOK() was called.  This makes me wonder if the requesting URI was
actually /cgi-bin/S4zRggxhEm, and because of the stripping we're getting it wrong.

i.e. someone should verify that this really is a non-implemented RFC issue, and
not a bug.



Part of me hopes that this is a bug in Mozilla, and the other part would be
ashamed if it is ;/ Though, if it's a bug where something is stripped from the
uri, why wouldn't it bite other sites?
I can no longer access this site -- it appears to be down.

However I just made a checkin for bug 155114 which I believe will fix this 
problem.  So I'm marking this as wfm.  If I'm mistaken and it is still a 
problem, then please reopen.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
The site is up and still doesn't work for me (build from cvs done after seeing
that comment). Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The service works again using the latest nightly (2002072008). Tested after I
noticed the changes were backed out. Is this temporary? Anyway, resolving at
least for now.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
Addressing the question in comment 15, my posting in comment 5 was in error, 
(although the bottom line was the same).  The correct values for this site are:

 path attribute: /cgi-bin/S0LDzy3yj2/

 requestin URI /cgi-bin/SOLO0001

So this site will be broken once the patch for bug 155114 is put back in because 
it violates the RFC2109 spec.  That will have to be addressed as an evangelism 
issue (unless this site is considered so important that we have to abandon out 
spec-checking because of it).

Reoponing this bug report because we know it will break, unless we want to be 
more conservative in our patch for bug 155114.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Great :( I've sent a message to Nordea about it.

Repeating myself: Does this still need to be security-sensitive?
Patch for bug 155114 has been subdivided into two patches.  The part of that 
patch that will break the finish site is now in bug 155083
Group: security?
Stephen, could you cc me on those bugs?
*** Bug 158261 has been marked as a duplicate of this bug. ***
-> Europe: West (Finland belongs there in Mozilla tech evangelism)
Assignee: piskozub → nitot
Status: REOPENED → NEW
Component: Europe: Central → Europe: West
QA Contact: pali → brantgurganus2001
*** Bug 167654 has been marked as a duplicate of this bug. ***
Received a message from Nordea today. They are going to try to fix it, but also
say that they feel Mozilla is too strict in this case.  
*** Bug 168673 has been marked as a duplicate of this bug. ***
*** Bug 169538 has been marked as a duplicate of this bug. ***
*** Bug 170347 has been marked as a duplicate of this bug. ***
*** Bug 171641 has been marked as a duplicate of this bug. ***
Patch for bug 155083 has been backed out.  This site should now be working
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Incidentally, solo.nordea.fi was also fixed this morning. 
VERIFIED FIXED 2002120508
URL: http://solo.nordea.fi → http://solo.nordea.fi/
Status: RESOLVED → VERIFIED
Summary: Unable to login to service as of 3rd July (problem with cookies) → solo.nordea.fi - unable to login to service (problem with cookies)
resolved euro west non-.com url bugs to other
Component: Europe: West → Other
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.