Mailing List Archive: False Positive in cross_site

False Positive in cross_site_scripting.nasl

Mar 1, 2002, 5:34 PM

Post #1 of 4 (3175 views)

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></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></u></p><p><b>description</b> <u>The requested resource (/<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--

Re: False Positive in cross_site_scripting.nasl [ In reply to ]

sq at cirt

Mar 1, 2002, 5:56 PM

Post #2 of 4 (3086 views)

Permalink

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><
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;} --></
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.</
by foreign host.
>
> --
> ^Drew
>
> http://guh.nu
>
> --Begin PGP Fingerprint--
> 3C6C F712 0A52 BD33 C518 5798 9014 CA99 2DA0 5E78
> --End PGP Fingerprint--

Re: False Positive in cross_site_scripting.nasl [ In reply to ]

noamr at beyondsecurity

Mar 2, 2002, 2:13 AM

Post #3 of 4 (3085 views)

Permalink

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" <sq@cirt.net>
To: "Andrew Hintz (Drew)" <mail.drew@overt.org>;
<plugins-writers@list.nessus.org>
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></
> 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--
>

Re: False Positive in cross_site_scripting.nasl [ In reply to ]

peak at argo

Mar 3, 2002, 9:28 AM

Post #4 of 4 (3085 views)

Permalink

On Fri, 1 Mar 2002, Andrew Hintz (Drew) wrote:

> 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

I don't think this is a false positive per se. At least until all software
vendors (including a certain major one) stop their quest for new and novel
harmful ways how to interpret untrusted data.

Perhaps the plugin should generate two kinds of messages: one for
occurences in the body (hole) and another for occurences in the header
(warning).

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Mailing List Archive

Mailing List Archive

Attached Files: