I've been active within web application security world for many years now. Well before it was called "web application security", back when we called it "CGI security". Remember the name for a web application was originally CGI (common gateway interface). Anyway in the mid-90's, when I was still a teenager, the Web was just first starting to take off. These were the days of old Netscape, Yahoo, the blink tag, when every page was "under construction" with the same little yellow street sign. Before Microsoft even acknowledge the Internet. All the cool web pages used frames. One for the menu and another for the main content body, and some had a dozen of them because they could. Then JavaScript hit the scene and became all the rage.
JavaScript enabled web developers to do all sorts of crazy things like image rollovers, mouse followers, and pop-up windows. Sure it wasn't the slick AJAX stuff like today, but neat enough at the time. What was soon discovered was that a malicious website could load another website into an adjacent frame or window, then use JavaScript to read into it. One website could cross a boundry and script into another page. Pull data from forms, re-write the page, etc. Hence the name cross-site scripting (CSS). Notice the use of "CSS". Netscape fired back with the "same-origin policy", designed to prevent such behavior. And the browser hackers took this as a challenge and began finding what seems like hundreds of ways to circumvent the security.
As more became familiar with CSS, people confused the terms with Cascading Style Sheets. Another newly born web browser technology in the 90's. Then a couple of years ago, via the webappsec mailing list, someone made the suggestion of changing cross-site scripting to XSS to avoid confusion. And just like that it stuck. XSS had an identity and dozens of newly minted white papers and thousands of advisories were released. Over time the original meaning of XSS changed, from one of reading across domains to anytime you can get a website to display user-supplied content laced with HTML/JavaScript. Thats why so many people are still confused by the name cross-site scripting, because it really doesn't describe what its become.
Such is the nature of things.
In a few short days we're going into the next evolutionary step. Hacking intranets with JavaScript Malware.
3 comments:
If memory serves me 1997 was my first
Is there a way to find out WHO the cross scripting is coming from? Like who/where are the hackers?
@HP First, all XSS attacks have an entry point. A piece of malicious code was initially posted to the site, which is classifiable as persistent XSS. In this case, the site owner should have the IP address of who posted it, or you can probably visibly see the username or profile name of the permission.
If the attack happens by user link click, whatever page the malicious URL is posted on, tell you a lot as well.
Secondly, when an XSS attack happens, there is usually a JavaScript payload that is SRC'ed in from somewhere. On what hostname does it resided? That could be an attacker own domain/machine.
Lastly, XSS attacks usually have a call-back system that instructs the victims browser where to send stolen data or where to receive further instructions. This can all be found in the JavaScript payload.
All these bits give additional information to uncover the identity of the attacker.
Secondly,
Post a Comment