[vox-tech] OT: one of the most pernicious spams i've ever seen.

[Rob Rogers]

On Thu, Sep 25, 2003 at 11:04:54AM -0700, Michael J Wenk wrote:
> On Thu, Sep 25, 2003 at 10:23:11AM -0700, Mitch Patenaude wrote:
> > On Thu, Sep 25, 2003 at 06:30:32AM -0700, p@dirac.org wrote:
> > >http:// 
> > >www.citibank.com:ac=VybznNffNxknAUxPrfE2jYaQUptJ@a3ksd.PiSeM.NeT/3/ 
> > >?IYTEw
> > >4eVTtbH1w6CpDrT
> > 
> > Maybe a way for places like Citibank, Paypal and other fraud prone sites
> > to help prevent this would be to check the referer, and if it's a  
> > strangely
> > formed url that looks like it might be fraudulent (uses username, lots  
> > of
> > encoded characters, etc), put up a fraud warning instead of the main  
> > page.
> > 
> > What do you guys think?
> 
> My only question/concern would be... What controls the referrer?  Is it
> mutable?  If so, its just another layer for a cracker to hit.  I guess
> for every layer added, some lazy crackers stop doing it is probably a
> good enough reason... 

The referrer is controlled by the browser (and is definitely not
required). It was brought up at a LUGOD meeting a while back (the Don
Marti DMCA meeting) that doing a 302 redirect (page has temporarily
moved) was one way of avoiding sending a referer. I don't know if that
was specific to any certain browser, but it wouldn't be hard to test for
anyone who is running a webserver.

I see a couple other problems with this idea too. First, this is the
first phishing scheme I've seen that loaded the actual homepage. Most
just steal their logos. Secondly, I'm almost potitive that your browser
wouldn't send encoded characters in the referer. Your browser would have
already decoded them, and it would send them unencoded. As for
usernames, I don't think your browser would EVER send that as part of
the referer. That would be a MAJOR security flaw.