Define “Safe”…
An article in InformationWeek yesterday exposes the details of what McAfee’s ScanAlert product actually means by “Hacker Safe”. The ScanAlert product issues certifications that websites are safe from attack. However XSSed.com, a website dedicated to exposing Cross-Site Scripting attacks, gave InformationWeek a listing of 60+ Hacker Safe websites with open XSS vulnerabilities. In response to the accusations, ScanAlert representatives assert that ScanAlert certification does not consider XSS vulnerabilities as dangerous. The reason being the XSS attacks are entirely ‘client side’, meaning they do not allow the hacker access to the server, data, or customer information.
The central issue is not whether or not XSS is a “real” threat or not, but rather what level of security is considered “safe”. Products like ScanAlert leverage the creditability of trusted names like McAfee and Symanetic to give consumers a (false) sense of security when conducting business online. The fact that nothing is truly secure is one of the primary lessons of basic computer security. Organizations should not rely on automated tests to feel secure about their sites. Consumers shouldn’t trust a site simply because it has a HackerSafe logo stamped on the front.
For a product to write off an entire genre of attacks as harmless and “client side only” is a naive assumption. There is more to attacks then just data vulnerability. XSS attacks can damage site’s integrity, bypass form validation leading to unpredictable data submission, thieve cookies and other private information from other users and sites, and a plethora of other evil genius attacks that I can’t even imagine.
Interesting links:
Detail of a XSS attack by local white-hat Russ McRee
Comment by Brian
January 20, 2008 @ 6:31 pm
This is indeed disturbing. I’ve always been a little leary of sites that display the “hacker safe” banners and wondered exactly what they signify.
Claiming that sites with open XSS vulnerabilities are safe seems beyond naïve to me. While these vulnerabilities might not allow an adversary to access or modify database data, consider the classic phishing scheme, where an adversary tricks an unsuspecting user into clicking a link, that takes them to a site that *looks* like the one they’re expecting, but is in fact malicious. An XSS vulnerability could allow the adversary to take this a step further: instead of hosting a lookalike page elsewhere, he could use the XSS vulnerability, so the unsuspecting user would be accessing the legitimate page, under the correct domain name, with the proper SSL certificate, but with a bit of JavaScript to modify the page to send its data elsewhere.
Such an attack still requires a somewhat gullible user, but a urlencoded string at the end of a URL (where users are used to seeing session IDs and other code numbers anyway) or even hidden in a POST request, is a lot harder to spot than an incorrect, malicious domain name.
Comment by cbhacking
January 21, 2008 @ 11:21 pm
Incredible – is accessing customer info via impersonation not considered to be a threat? Many sites have XSS vulnerabilities on their login pages that an attacker could use to gain login credentials for that person.
As for attacks against the server, that might technically be true… but XSS can still be used to modify (behind the user’s back) data going to the server, such as the details (like where to ship the item, or how many to buy) of a web purchase.
Comment by Alex
February 24, 2008 @ 9:55 am
It’s true XSS sites are not safe at all and with a little java script and css you can modify about anything.