The original XSS advisory (2000) | Hacker News Reader

The original XSS advisory (2000)

web.archive.org

28 pointsbawolff6 comments

> Web Users Should Disable Scripting Languages in Their Browsers

Oh what could have been.

Certainly better than their alternative suggestion:

> Web Users Should Not Engage in Promiscuous Browsing

In 1998 a buddy and I made a site for ladder style Total Annihilation game matching site, built entirely with ASP 2.0 and VBScript. I honestly thought nothing of security. I was just happy that I got it working. I luckily had a friend who cheesed the entire site showed me several xss and sql injection attacks. At first I was happy that users could use HTML to decorate their messages, then I saw a login box appear where I know it shouldn't be...

Reminds me of the time in my university where all exams were "online". It was nearly completely client side with VBScript carrying the answers to select.

For 4 years I managed to get straight As until a leaky mouth discovered and disclosed it to the IT dept. Me and my friends were never doubted for since we were the top A students with foul mouths. The guy who reported it felt a sense of pride but whatever..

This was late 90s, early 2000s. Was fun times.

> Attempting to remove dangerous meta-characters from the input stream leaves a number of risks unaddressed. We encourage developers to restrict variables used in the construction of pages to those characters that are explicitly allowed and to check those variables during the generation of the output page

Nice to see that allow-list input validation was proscribed as a solution to XSS (and really any injection attack) from the beginning. It even explicitly warns against trying to do deny-list.

Trying to sanitize or defang user supplied input is always very difficult and a handy bad-code-smell indicator during code review. It has a ton of corner cases and edge cases and by its very nature it fails deadly: can an attacker discover an injection using characters that aren’t in the denial list? They win. Oh you’re sanitizing function simply removes the malicious characters? Attacker constructs an injection string that contains an valid injection that is constructor by your sanitizer function removing characters.

Nice also see reference to output e coding as well. Defense in depth is always a good idea. It also protects you from injection through other means that may be are not properly validated.

And, 10 years later:

https://lcamtuf.coredump.cx/postxss/

It turned out Michal was a little optimistic with the timeline, though. :)

Reply on news.ycombinator.com