RE: Phishing

["Rohrer, Mark E" <mark.e.rohrer () lmco com>]

While not necessarily phishing in the "classical" sense, a corollary
issue is the poor construct of financial (or other institutions or
industry) pages implementing client-side executables, particularly with
forms where a nefarious user can simply modify any bounds- or
string-checking to pass otherwise restricted characters and thus
compromise accounts.

View the source code, make the minor mods, save to the local drive, and
launch the modded page from the local drive, and now the hacker can
manipulate the host to reveal sensitive and private data not authorized
to the hacker.  I'd expect most, if not all, major institutions to guard
against serving up client-side forms, but how many of us deal with
myriad small-businesses that may not have the same wherewithall?


-----Original Message-----
From: Jordan Dimov [mailto:jdimov () nsegcorp com] 
Sent: Wednesday, May 12, 2004 7:51 AM
To: webappsec () securityfocus com
Subject: Re: Phishing


These are good starting points, Rogan.  I'd love to see further
discussion on this topic.  

> Make the site name as short as possible, and as obvious as possible, 
> to
> reduce confusion. Rather than
"www{1,2,3,4,5,6,7,8,9}.encrypt.bank.com", 
> try to use something short and simple like "secure.bank.com", and use
it 
> consistently for all servers supporting a particular application. That

> way there is less confusion for users, and less likelihood that a 
> scammer will get away with using a slightly different domain name.

This doesn't really protect against typographical domain name scams
(e.g. paypai.com vs. paypal.com)

Additionally, there are several known security vulnerabilities in MSIE
and other browsers that make it much easier for attackers to hide the
true identity of their fake site and mislead the user.  

  -- Jordan 

Association for Information Security (www.iseca.org)