Hi, The problem is there, just because one type of browser doesn't parses it in a way that would endanger the end user doesn't mean the server is safe. The checks done by Nessus doesn't take to account the reactions from different end user clients, but rather check for the reactions (the need for proper reaction) of a server. In this case Cross Site Scripting vulnerability is considered by definition (maybe it is just my own): 1) I send a HTML, JavaScript, or any other malicious mobile code to the server. 2) Anywhere in the result received by the end server I can find an unfiltered, unmodified form of my malicious code. Since the test doesn't fall over things like escaping of ' with \', etc, a positive would mean that the server behaved as a cross site scripting vulnerable product. I based the above statement on: "A web site may inadvertently include malicious HTML tags or script in a dynamically generated page based on invalidated input from untrustworthy sources. This can be a problem when a web server does not adequately ensure that generated pages are properly encoded to prevent unintended execution of scripts, and when input is not validated to prevent malicious HTML from being presented to the user. " ( http://www.cert.org/advisories/CA-2000-02.html ) Were a web site in my case is a faulty web server. Thanks Noam Rathaus CTO Beyond Security Ltd http://www.SecurITeam.com http://www.BeyondSecurity.com ----- Original Message ----- From: "Sullo" <sqat_private> To: "Andrew Hintz (Drew)" <mail.drewat_private>; <plugins-writersat_private> Sent: Saturday, March 02, 2002 02:56 Subject: Re: False Positive in cross_site_scripting.nasl > Yes, it would report a positive in the case you mention below. The > question is really is it a false-positive or a real problem? I've been > searching the Neohapsis/BugTraq archives and can't find an > example of CSS in that context. > > However, the server is returning unfiltered/parsed/encoded user- > originated content back, which means in some way trust could be > exploited. Just because the popular browsers are safe to this > doesn't mean all web browsers (agents/bots/code) are. But does > encoding that return break the HTTP rfc? I'm not sure. > > The "fix" for the plugin is to strip (or just ignore) everything up to the > start of the Content-Type header, but.... I'm not sure that's the right > answer. Anyone? > > I'll keep researching, though, it's a good observation & interesting > problem. > > Thanks > Sullo > > > > I think that cross_site_scripting.nasl will report a security hole > when the webserver returns the requested, non-sanitized file > name in the http status field. However, the web browsers I tested > don't treat the http status field as HTML. > > > > Attached is an updated copy of the css nasl. > > > > Here's an example of a session that nessus will false positive > on: > > > > [root@nsd2 plugins]# telnet 10.0.0.211 80 > > Trying 10.0.0.211... > > Connected to 10.0.0.211. > > Escape character is '^]'. > > GET /<SCRIPT>alert('Vulnerable')</SCRIPT> HTTP/1.1 > > > > HTTP/1.1 404 /<SCRIPT>alert('Vulnerable')</SCRIPT> > > Content-Type: text/html > > Date: Fri, 01 Mar 2002 21:34:28 GMT > > Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector) > > Connection: close > > > > <html><head><title>Apache Tomcat/4.0.1 - Error report</title>< > STYLE><!--H1{font-family : sans-serif,Arial,Tahoma;color : > white;background-color : #0086b2;} BODY{font-family : sans- > serif,Arial,Tahooma;color : black;background-color : white;} B{color > : white;background-color : #0086b2;} HR{color : #0086b2;} --></ > STYLE> </head><body><h1>Apache Tomcat/4.0.1 - HTTP Status > 404 - /<SCRIPT>alert('Vulnerable')</SCRIPT></h1><HR > size="1" noshade><p><b>type</b> Status report</p><p><b> > message</b> <u>/<SCRIPT>alert('Vulnerable')</SCRIPT& > gt;</u></p><p><b>description</b> <u>The requested resource (/& > lt;SCRIPT>alert('Vulnerable')</SCRIPT>) is not available.</ > u></p><HR size="1" noshade></body></html>Connection closed > by foreign host. > > > > -- > > ^Drew > > > > http://guh.nu > > > > --Begin PGP Fingerprint-- > > 3C6C F712 0A52 BD33 C518 5798 9014 CA99 2DA0 5E78 > > --End PGP Fingerprint-- >
This archive was generated by hypermail 2b30 : Sat Mar 02 2002 - 01:14:18 PST