Comments on: Define “Safe”… http://cubist.cs.washington.edu/Security/2008/01/18/define-safe/ Mon, 06 Oct 2008 13:36:40 +0000 http://wordpress.org/?v=2.6.2 By: Alex http://cubist.cs.washington.edu/Security/2008/01/18/define-safe/#comment-2314 Alex Sun, 24 Feb 2008 17:55:37 +0000 http://cubist.cs.washington.edu/Security/2008/01/18/define-safe/#comment-2314 It's true XSS sites are not safe at all and with a little java script and css you can modify about anything. It’s true XSS sites are not safe at all and with a little java script and css you can modify about anything.

]]> By: cbhacking http://cubist.cs.washington.edu/Security/2008/01/18/define-safe/#comment-72 cbhacking Tue, 22 Jan 2008 07:21:37 +0000 http://cubist.cs.washington.edu/Security/2008/01/18/define-safe/#comment-72 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. 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.

]]> By: Brian http://cubist.cs.washington.edu/Security/2008/01/18/define-safe/#comment-56 Brian Mon, 21 Jan 2008 02:31:47 +0000 http://cubist.cs.washington.edu/Security/2008/01/18/define-safe/#comment-56 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. 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.

]]>