Recently one of my customers rang into the nice problem of logging onto
yahoo mail to find another person's mailbox coming up. They,
surprisingly, notified yahoo about this, and received the following:
: Hello Yahoo! Mail User,
: Thank you for reporting this problem to us. We are very concerned about
: the security of our users' mail, and are glad you brought this issue to
: our attention. We investigated the problem and believe is is caused by
: a faulty proxy server belonging to your Internet Service Provider (ISP)
<snippity snip, more about what is a proxy server etc, blame the ISP>
Now, they've quoted one of my proxies as being the culprit, which is
squid 1.2b24 and a pretty standard installation.
Looking at the actual requests (thankfully still in the logs), I see:
906427853.047 3029 203.143.227.27 TCP_MISS/302 239 GET http://yahoo.com/
- TIMEOUT_FIRST_PARENT_MISS/proxy1.mel.connect.com.au -
906427856.077 0 203.143.227.27 TCP_IMS_HIT/200 11018 GET
http://www.yahoo.com/ - NONE/- text/html
normal behaviour.
When they actually login:
906427874.267 1009 203.143.227.27 TCP_MISS/302 416 GET
http://mail.yahoo.com/py/ymGo.py? - DIRECT/mail.yahoo.com text/html
Yup, we're going direct by rule (cgi-bin and ? characters go direct), and
we're going direct up until:
906428128.787 2020 203.143.227.27 TCP_MISS/000 0 GET
http://f1.mail.yahoo.com/help/ym/i/DECISIONTREE=622.html -
FIRST_PARENT_MISS/proxy1.mel.connect.com.au -
Which seems to be our client going through the yahoo mail help pages, and
getting it off proxy1.mel.connect is perfectly valid (one of our parents)
My first thought was that our client was accessing all of our
proxies and running into differences there. Nope, only one proxy was
accessed.
It very much looks like yahoo can't write an authentication system for
nuts ;)
--==--
Bruce.
Systems Administrator
Hub Communications.
Received on Tue Sep 22 1998 - 19:50:06 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:10 MST