full-disclosure - (no subject)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3FD1B6D3.4332.859923A5@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: (no subject)

"http-equiv@...ite.com" <1@...ware.com> wrote:

> Quite a nifty email scam:
> 
> <a 
> href="http://www.visa.com                                            
>                                                                  :Use
> rSession=2f6q9uuu88312264trzzz55884495&usersoption=SecurityUpdate&Sta
> teLevel=GetFrom@...252.126.191/verified_by_visa.html">http://www.visa
> .com</a>
> 
> Note the gap, shows only as visa.com in Outlook Express which takes 
> you to visa's site and a rather awkward popup window where the data 
> is supposed to be filled in.

Indeed -- this is a classic exploit of a classic case of several 
_really, really BAD_ design decisions.

First, some genius (or committee thereof) decided that putting 
"userinfo" data into URLs would be a good idea.  This was decided 
despite it generally being agreed -- as the URL RFC authors note _in 
the RFC_ -- to be a bad thing from a security perspective...

Second, and perhaps the largest part of the problem was that the 
specification for doing this was designed by people with _ABSOLUTELY 
ZERO_ clue about user interfaces, as is shown by their decision to put 
userinfo data in front of the target domain.  Normally users will only 
see URLs without userinfo data, so from a UI perspective it was really 
bad design to have a "special case" (that would be rarely used and thus 
rarely seen by users) "disturb" the expectation of the user (in 
general, that is a recipe for problems).  Worse is that the userinfo 
data field has, by its nature, to allow for completely arbitrary data 
(in terms of length and character set).

Third, and increasingly inexcusable, is that no client s/w (that I am 
aware of) that deals with such URLs has _ANY_ kind of sanity checking 
or user warning that "something unexpected" may be about to happen.  I 
would hazard that, because of the general agreement that specifying 
userinfo data in URLs is a really bad thing, historically "most" URLs 
that the have had a userinfo part have had such for nefarious uses.  
Thus, I'd suggest that it is time URL-handling routines stopped 
handling userinfo data, at least without prompting the user, or better 
still, by default be configured to not handle userinfo (which would 
make userinfo handling a candidate for zone-by-zone enabling in IE 
where, _at most_, it would only make sense to be enabled by default in 
the Trusted Sites zone).

Regards,

Nick FitzGerald