Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: Preventing Cross-site Scripting Attacks

by converter (Priest)
on Feb 23, 2002 at 00:15 UTC ( #147002=note: print w/ replies, xml ) Need Help??


in reply to Preventing Cross-site Scripting Attacks

I enjoyed the article, but I wish it would have addressed sites (like this one) that allow users to input markup.

Is parsing out script tag sections enough to close the hole, or are there other mechanisms that have to be addressed?


Comment on Re: Preventing Cross-site Scripting Attacks
•Re: Re: Preventing Cross-site Scripting Attacks
by merlyn (Sage) on Feb 23, 2002 at 01:56 UTC
    I was pointing out the dangers of user-permitted HTML markup many years ago when I talked about how I was including Barney the Dinosaur into guestbooks on my home page.

    I don't think there's a completely secure solution. tilly wrote a fairly nice strongbox solution that permits very carefully a subset of HTML, but it's more in the "only permitted things allowed" realm than the "look for bad things and prevent them" realm. Given the risk, I'd say this is the right approach.

    -- Randal L. Schwartz, Perl hacker


    update: Thanks to mdillon for the link for tilly's node.
Re: Re: Preventing Cross-site Scripting Attacks
by Dog and Pony (Priest) on Feb 23, 2002 at 10:40 UTC
    Reminds me of a community I used to be a part of, when I played the online game Utopia. Over at www.avidgamers.com they provide basic types of communities for alliances and stuff like that, in different games.

    Anyhow, those sites do clean out certain markup in a pretty good way - the administrator can choose which tags are allowed - scripting is never, and from what I can tell, the engine that strips such is pretty good.

    But they had allowed the <table> and the <div> tags. So me and a friend started impersonating other friends in the forums, mostly for fun, but also to enlighten this problem. We basically did this by creating posts that contained closing </td></tr></table> that were the same as the forums, and then built up a new post "after ours" within our own post, having those guys saying really funny stuff. It took almost two days before the HTML illiterates (no wrong with that, mind you) figured out what the *** happened.

    With <div>, we created signature boxes that hung under the menu - something like "This thread contains a post by XXX!" with lots of colors and stuff.

    Most people laughed their heads off while we were rummaging around like that, but some did take offense - none that we impersonated though. And it was really funny to see people saying " I did not say that!" when everybody could "see" they did.

    Then, of course, we told them which tags to turn off, and no more problems.

    Personally, I think that scripts should be filterd out in places like these. I know that I can, and I have, turned them off in the browser for this place, but all it really takes is someone malicious posting, and someone not so careful browsing. I didn't have it turned off in the beginning, and for all I know, someone may already have my password. And javascript in general is not the problem, just when you can post whatever and on a site with login cookies or similar.


    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
      Although I'm fairly new to PerlMonks I HAVE noticed that several of the more seasoned monks have warnings about having Javascript enabled but none really explains what the possible dangers/exploits are that can arise from surfing w/JS-enabled. Have any monks written a node explaining the problem in detail? *Click "Preferences"* JavaScript off... Paranoia on...

      MarkMoon
        I think tye has a good warning at his home node, where he says that someone can steal your password if you have javascript enabled.

        In short, the problem is this: Javascript can access the cookies you have for the current site. Without going into too much detail, it only take a few lines of javascript to grab your login cookie and send it to a script at some site, and it only takes a few lines of for example perl to craft a cookie for a browser that will allow anyone to log in as you. Notice that with this method, you don't even need to decode the password!

        I haven't tried it at this site, nor will I, so I am not 100% that there aren't any safeguards against it that I am unaware of. But I have, as an experiment, crafted just such a thing on above mentioned http://www.avidgamers.com. I was able to steal my own password and log in with a crafted cookie at a computer that I never had went there with before. I am a curious soul.

        It is quite possible that one shouldn't be talking about this, so as to not give anyone any ideas. But I do this anyways, for two purposes. If you are aware of how easy this would be to accomplish, you will hopefully protect yourself. And maybe scripts and event handlers will be stripped out from user-provided HTML. As a sidenote, I wonder if our moves are tracked via IP or something at this site, so it would be sufficiently easy to prove you didn't do a certain thing, and also to track the thief if needs would be?

        Again, note that this is only a risk where you have both these things; session-cookies which identify you, and the possibility for users to add arbitrary javascript to a page you will be viewing.

        Does that explain the matter?


        You have moved into a dark place.
        It is pitch black. You are likely to be eaten by a grue.
Re: Re: Preventing Cross-site Scripting Attacks
by gellyfish (Monsignor) on Feb 23, 2002 at 14:54 UTC

    are there other mechanisms that have to be addressed

    Of course you can have event attributes such as onClick in certain HTML tags which could have malicious script in. On the whole the best approach as merlyn points out is to only allow a safe subset of HTML rather than attempting to remove potentially bad things.

    /J\

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://147002]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2014-08-02 10:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (55 votes), past polls