Symantec Blogs: Security ResponseSyndicate content

Silas Barnes | January 25th, 2008
0 comments

We all know that there is a certain amountof risk we have to accept when we place personal information on a Website, including the possibility that someone may use that informationwithout our explicit permission. We also know that social networkingsites are becoming increasingly popular as more and more people enjoythe convenience with which to re-establish and maintain contact withlong lost friends, distant relatives, and work colleagues. Well, now itseems as though you don't even have to go to the trouble of signing upfor a profile with one social networking site or even provide content -they can do it for you!

Douglas Rushkoff, an author and documentarian from the UnitedStates, was momentarily confused when he started receiving a suddenburst of NDR (non-delivery report) emails informing him that a numberof emails he had previously sent could not be delivered - particularlywhen he did not remember sending any such emails. And these particularemails all...

Andrea DelMiglio | January 10th, 2008
0 comments

The "referer" [sic] header is generallyused to track back-links in order to understand how a certain Web siteis being reached by its visitors (hyperlinks on other Web sites, searchengines, etc.) According to the RFC2616,“...the Referer request-header field allows the client to specify, forthe server's benefit, the address (URI) of the resource from which theRequest-URI was obtained (the "referrer", although the header field ismisspelled).”

In the online fraud arena, the referrer field can also be used todetect new phishing Web sites. Let’s use as an example the followingphishing site (which also happens to be a Rock Phish attack):

...

Andrea DelMiglio | January 8th, 2008
0 comments

As discussed in the past,cross site scripting (XSS) can be exploited by phishers to build reallyeffective attacks. Today we have analyzed another similar attack thatincludes some enhanced features. The attack was exploiting an injectionflaw in an Internet banking application, specifically located in themodule used to display warning messages to users.

The function took a single GET parameter:

https://www.well-known-bank.com/popup.asp?msg=[ASCII_encoded_message_to_display]

And then returned a page with the following in the body:

document.writeln([decoded_messages]);

Obviously the aim here is to have a single page display warningsthat are available to every module in the application. Because theinput was not properly sanitized the attackers used...