[HN Gopher] The original XSS advisory (2000)
       ___________________________________________________________________
        
       The original XSS advisory (2000)
        
       Author : bawolff
       Score  : 19 points
       Date   : 2021-06-04 19:37 UTC (3 hours ago)
        
 (HTM) web link (web.archive.org)
 (TXT) w3m dump (web.archive.org)
        
       | xyzzy123 wrote:
       | In 2000 I completely discounted XSS as a "lame" bug and did not
       | take it seriously at all. I think the feeling was fairly
       | widespread.
       | 
       | There were so many stack overflow type RCEs, bad configuration,
       | default credentials and patching was so bad that you could mostly
       | "look real hard" at any network with a big enough footprint and
       | compromise something. A "hardened" network was one you had to
       | watch and wait, note down the "bug magnet" services and apply a
       | public exploit faster than their time to patch.
       | 
       | 10 years later I got my first pentesting job and had to shift
       | from being network focused to webapp focused; the industry had
       | moved on and the tactics I used as a script kiddie were not
       | nearly as effective. Still usable but not as much from the
       | outside.
       | 
       | I learned to love XSS.
        
       | tptacek wrote:
       | And, 10 years later:
       | 
       | https://lcamtuf.coredump.cx/postxss/
       | 
       | It turned out Michal was a little optimistic with the timeline,
       | though. :)
        
       | smoldesu wrote:
       | > Web Users Should Disable Scripting Languages in Their Browsers
       | 
       | Oh what could have been.
        
         | bawolff wrote:
         | Certainly better than their alternative suggestion:
         | 
         | > Web Users Should Not Engage in Promiscuous Browsing
        
       | billyhoffman wrote:
       | > 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.
        
       ___________________________________________________________________
       (page generated 2021-06-04 23:01 UTC)