Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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])

    • 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.
      • 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]

        • 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.
          • 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]

            • I'm not sure there's much to protecting the Wiki

              Very, very, very wrong. Security module of client side scripting is that there is single trust zone per one hostname. If you have, say, properly coded ecommerce shop and wiki with XSS bugs sitting on same domain than ecommerce shop is also vulnerable. Attacker needs only to lure ecommerce shop user on part of wiki with XSS bug and, bummer, user's auth coookie is known to "bad" guy.

              --

              Ilya Martynov (http://martynov.org/ [martynov.org])