use Perl

• I hate to be pessimistic but ... (Score:1)

  by IlyaM (2933)

  Do I get it right that with AxKit it is impossible to inject new tags into output? If yes, then it makes making XSS holes much harder but not impossible cause XSS it is not just injection of dangerous tags into output. Imagine for example public web service that let's people to exchange URL's (let's call it "Shared bookmarks"). Obvious possible XSS hole is not verifying schema part of submited URL to be clear from dangerous schemas like 'javascript'. I doubt AxKit can automatically protect from this kind of

  --
  

  Ilya Martynov (http://martynov.org/ [martynov.org])
  • Re:I hate to be pessimistic but ... (Score:2)

    by Matts (1087)

    You're absolutely right, and I'm no security expert, so just how much damage can you do with the javascript: scheme? Is it limited to one function call, or can you chain lots of javascript into one method.
    • Re:I hate to be pessimistic but ... (Score:2)

      by darobin (1316)

      I don't think it's limited to one call, but even if it is you always have Good Ol' eval() there so it don't make much of a diff I'm afraid.

      --
      

      -- Robin Berjon [berjon.com]
      • Re:I hate to be pessimistic but ... (Score:2)

        by Matts (1087)

        OK, so given any link you have to check it starts with /^(https?|ftp):/. Sounds fairly straightforward (though I don't do any checking in the AxKit wiki I don't think).
        
        Still, I think overall that means you've got a lot less coding to do with AxKit than with other (inferior ;-) solutions.
        • Re:I hate to be pessimistic but ... (Score:2)

          by darobin (1316)

          AxKit has the pro re XSS that it will be more likely to blow up given some treacherous charset than other solutions will be, especially if you charconv from UTF-8 to Latin-X at the end. Apart from that, it's prolly just as open as anything that deals with user-provided content.

          I'm not sure there's much to protecting the Wiki. A Wiki is, by definition, well, XSS enabled :) It pretty much works based on trusting other people. At any rate if you want to protect against javascript URLs, I'd check on !/

          --
          

          -- Robin Berjon [berjon.com]
          • Re:I hate to be pessimistic but ... (Score:1)

            by IlyaM (2933)

            I'd explicitly list "good" schemas and reject all others. Various browsers used to support various dangerous schemas in addition to javascript. For example I recall some versions of MSIE had a bug which allowed to run javascript via about: schema.

            --
            

            Ilya Martynov (http://martynov.org/ [martynov.org])
            • Re:I hate to be pessimistic but ... (Score:2)

              by darobin (1316) on 2003.01.28 6:10 (#16448) Homepage Journal

              Depends on what kind of security you want. For axkit.org's Wiki I'd allow everything, including javascript:, so that we can have bookmarklets in there. For a site that has sensitive information I wouldn't use a Wiki.

              --
              

              -- Robin Berjon [berjon.com]

              Reply to This

              Parent

              • Re:I hate to be pessimistic but ... (Score:2)

                by Matts (1087)

                Too late. Pod::SAX now explicitly only allows (https?|ftp|mailto|s?news|nntp).
                
                Javascript is just too dangerous.
                
                There's probably still bugs in the wiki in that it allows XML input, so you may be able to sneak something by that way, but hopefully the XSLT should disallow anything but known tags (and filter attributes sanely).