SPUG: CGI.pm cross site scripting vulnerability

[Fred Morris]

Jay wrote:
>Just in case you haven't heard.
>
>Security advisory for Perl
>SUMMARY   : CGI.pm cross site scripting vulnerability
>DATE      : 2003-07-29 14:53:00
>more Info:      <http://eyeonsecurity.org/advisories/CGI.pm/adv.html>

I wonder what they changed the default behavior to? Somehow, I always
figured that sort of behavior was "by design".

Let's take a close look at the scenario here:

1. Someone creates a page with malware.

The malicious tag could execute a script, directly. Almost any page that
allows (ab)users to create HTMLized markup is by definition such an
accident waiting to happen. (Wikis, anyone?). It might not even need to be
a tag, depending on what kind of markup the site allows, JavaScript (or any
other kind of client script) could be entered and run in the browser,
simply by loading the page. Let's take that a final step further, and what
if the site post-processes the content on the server, think maybe I can get
a little Perl or PHP in there? Indeed.

2. User submits a malicious URL, from a malicious page.

Why? I guess people will just click on any old link, anywhere. Yup, no
guessing about it, they will!

The (ab)user could have manually created a malicious URL. No, that would
never happen.. yeah, right!

3. The server gets the URL and doesn't validate the parameters.

That appeals to SQO cowboys. Doesn't appeal to me. Hey, maybe they do
validate, but not particularly closely. Taint? Formmail?

4. The server creates a page containing the payload from step 1 and sends
it back to the user.

The subtle issue here is not that it's the same site (site A), but some
other site (site B). Furthermore the user "trusts" site B, but not site A.

The trust is the issue here: consequently, they allow site B to do things
they wouldn't allow site A to do. The user is trusting a site which allows,
intentionally or otherwise, unvalidated input to become part of its
content. That's really smart, I'm sure we agree.

Or, could it be that site B is using cookies or other client fluff in maybe
ways that it shouldn't oughta? Is there some dirty underwear in those
cookies, maybe, that site B doesn't want site A (or some other site C) to
get ahold of? Other than somebody legitimate like doubleclick, of course
(gee, I never visited doubleclick.com, why do I have doubleclick cookies?
duuuh).


Several questions and observations need to be made about all of this:

Cookies are just so stupid for persistence of sensitive information.

Most people don't spend a whole lot of time evaluating which sites to
trust... they don't even know how! Even if they did, they don't have much
choice if their idiot bank or online merchant ("A" word, anyone?) ties
identity to cookies or any other mechanism which operates without user
intervention. Even if they do know how, do they know how to adjust the
settings in their browser (presuming it's possible), and is the browser
trustworthy?

Given the above, rationally is the issue really about protecting users, or
protecting sites which do stupid things? Obviously, the user's aren't
running CGI.pm (well, they are in an OO/Smalltalkish/message passing
sense), but that's not their choice. Given that the site made a stupid
decision as a matter of policy to begin with, are they really going to
revisit those decisions, or are they just going to apply a bandaid?

Think there are any sites out there which allow third parties (advertisers)
to place JavaScript on pages where they exchange sensitive information with
the user? I bet there are! Ya think they personally vett that code, and
accept liability for its being there? I bet they don't want to, but it
might be an interesting court case.



ObPerl: Remember a few months ago when I asked about escaping HTML? While
researching this to make sure I wasn't losing my mind, I found the really
obvious answer. Check out Apache::Util::escape_html().

Ingy: I like wikis. The web is not just for passive lusers, it's what we
make of it. Still whom do we trust, why, and are we making good decisions?

--

Fred Morris
m3047 at inwa.net