Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Mojolicious vs Dancer (security-wise)?

by Anonymous Monk
on Sep 19, 2012 at 07:30 UTC ( #994418=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

We're evaluating Mojolicious vs Dancer (Catalyst might still come back into the picture but currently the project is small and we prefer simpler and smaller framework).

Our main concern is more with security instead of speed or other factors. Would be nice if someone can compare the two, security-wise, for example:

  • Track record of incidents?
  • Coding style (in relation to robustness)?
  • Size of code base (with/without dependencies)?
  • Which framework advocates more defensive/secure programming and stricter default template language?
  • Which framework encodes/escapes input and output more, by default?
  • Does the framework work under strict, warnings, strictures, taint mode, setuid setup?
  • (By default?) protection against: XSS, XSRF, SQL injection?
  • Other difference in security practice (default URL, default admin user/password, and so on)?

Comment on Mojolicious vs Dancer (security-wise)?
Re: Mojolicious vs Dancer (security-wise)?
by Anonymous Monk on Sep 19, 2012 at 08:34 UTC

    :)

    The first three questions require a good bit of research

    The rest border on nonsensical, as nearly everything is a plugin, and there are multiple, and ...

    Broad question, it would be nice if developers provided this kind of thing, I wish you luck

Re: Mojolicious vs Dancer (security-wise)?
by ww (Bishop) on Sep 19, 2012 at 10:15 UTC

    Specific request:

    "Would be nice if someone...."

    That "someone" is you. Please feel free to publish your findings here.

Re: Mojolicious vs Dancer (security-wise)?
by moritz (Cardinal) on Sep 19, 2012 at 17:09 UTC
    Track record of incidents?

    Dancer: none, mojolicious: five in the CVE database. But that might just mean that somebody tracks the mojolicious bugs and nobody tracks the Dancer bugs in CVE.

    Which framework advocates more defensive/secure programming and stricter default template language?

    Both allow you to use arbitrary template engines. Mojo::Template makes it easier to interpolate escaped strings <%= ... %> than unescaped strings <%== ... %>. I don't know much about Dancer in this regard.

    Does the framework work under strict, warnings, strictures, taint mode, setuid setup?

    Both work with strinctures. In fact Mojolicious::Lite enables them by default.

    (By default?) protection against: XSS, XSRF, SQL injection?

    Mojolicious doesn't generate HTML for you by default, so there are neither vulnerabilities nor safeguards against XSRF.

    default admin user/password

    You're kidding, aren't you?

      Dancer had the exact same directory traversal bug as Mojolicious (CVE-2011-1589).
Re: Mojolicious vs Dancer (security-wise)?
by davido (Archbishop) on Sep 19, 2012 at 21:06 UTC

    Some of those are good questions, and some are kind of the wrong questions to be asking.

    Dependencies and size of distribution Mojolicious consists of a single distribution with a zipped tarball of just over 500KB in size. It has no non-core dependencies. It installs on most modern systems in under a minute, including the execution of its high-coverage test-suite. When I execute the tests in parallel, I get a full installation in about fifteen seconds. There are a few helper modules you can install if you need some more advanced functionality, but they're optional. And it's up to you to decide on what resources to use in establishing a database connection; it's completely neutral on the model layer.

    Track record of incidents? You should probably instead be asking if the cultural infrastructure of a given framework facilitates reporting of incidents, if the reaction time to incidents is quick, and if the solutions are on target. There are a few incidents in Mojolicious' history, and all of them were dealt with quickly, transparently, and accurately. Something as complex as a scalable web framework that has no incidents could be an indication of poor reporting, or opaque practices. It is to be expected that problems will turn up in any project. It's how the problems are handled that matters most. I would say that Mojolicious's track record is quite good; there is a substantial user base, only a few known issues that were resolved transparently, quickly, and correctly.

    Coding style (in relation to robustness)? I don't see coding style and robustness at odds with each other. As a matter of fact, coding style can contribute to robustness. Mojolicious's coding style is intentionally minimalistic, both in appearance and in "action at a distance" (magic). Furthermore, Mojolicious has something like 19000 tests for 11000 lines of code (going from memory here). The design policy is that a feature is only a feature if it is supported by tests. New features are not added if they break tests, except after a documented deprecation cycle, and even then, usually other means of achieving the goal are used that don't break existing tests. Breaking existing tests goes heavily against the Mojolicious team's philosophy.

    Advocacy for defensive/secure programming, strict template language As moritz suggested, Mojolicious templates escape output from embedded Perl by default. You have to intentionally use the <%== .....%> to get un-escaped output. Mojolicious's templates run under strictures. Stash values that aren't reserved words become variables accessible in your template. If you attempt to access a variable that hasn't been declared, or passed in via the stash or flash, you'll get a strictures violation. But the templates are embedded Perl. However, Mojolicious doesn't force you to use its templates (as good as they are, you may have another preference). The Mojolicious documentation demonstrates how to use a different templating system if you wish.

    encoding/escaping of input/output While you (the developer) are permitted to access raw input, the normal means of dealing with input in Mojolicious handles encoding/decoding for you. What you do with the input is up to you, and safety can only go so far as you don't misuse user input.

    Strictures and warnings Any class that inherits from Mojo::Base has strict enabled by default. I can't remember if warnings are enabled by default or not, because I always enable them explicitly anyway. In development mode, strict violations (and other fatal errors) will route you to an error page in your browser that displays some of the surrounding code. In production mode, you get a sanitized failure that doesn't give away any information.

    XSS, XSRF, SQL Injection Mojolicious doesn't manage your database interactions for you, and has no say over how you craft your interaction. So asking if Mojolicious prevents SQL injection attacks is like asking if the car's seat belt mechanism has a means of preventing flat tires. XSS: The fact that Mojolicious's templates default to escaping Perl output is a design feature intended to prevent XSS attacks. Mojolicious's session cookies are signed with a SHA1 digest based on the cookie's content, an "application secret", and the cookie's credentials. This prevents Mojolicious from accepting a session that has been forged in any way. By default, Mojolicious session cookies expire after two hours. Any cookie that doesn't match the SHA1 hash will be ignored (as in, won't be allowed to be used), and the corresponding session becomes invalid. I don't know if this prevents all XSRF vectors, but it seems pretty secure.

    The application secret (used in signing cookies) can be set by the app itself at any time. Whenever the secret changes, the signature on the cookies will no longer match, and all sessions will be invalidated. This can be a quick-and-dirty way to force all users to log in anew.

    Mojolicious's routing allows for 'bridges'. A bridge facilitates a request being routed through a callback function before arriving at its destination. The callback has to return a true value or the destination won't be available. So it's easy to put your auth checks in a bridge. Users who don't meet the requirement won't be routed to their requested destination.

    You should visit the Mojolicious website to read for yourself what features are documented, what precautions are taken, and so on. If, after reading all that, you have additional questions, I encourage you to check out the Mojolicious mailing list, as well as the #mojo channel on irc.perl.org. There is always someone listening at those two locations who can answer specific questions.


    Dave

      I don't know if this prevents all XSRF vectors, but it seems pretty secure.

      It prevents zero XSRF vectors because XSRF is session riding , the request comes from the users browser, using the existing session cookie

        You're correct.

        Maybe either Mojolicious::Plugin::CSRFProtect or Mojolicious::Plugin::CSRFDefender would be reasonable steps in the right direction. The former looks to be more thorough, while the latter looks a little more foolproof.

        Mojolicious::Plugin::CSRFProtect adds a hidden input field to forms, adds a token to ajax requests, rejects all non-GET/HEAD requests without the token, and simplifies the safeguarding of GET/HEAD requests and side-effect links.

        This seems to provide the mechanism needed to implement one of the prevention measures mentioned in the Wikipedia article to which you linked: "Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions."

        I'm using Mojolicious::Plugin::CSRFProtect in a project. It's convenient. All I have to do is make sure my routes for forms only respond to POST requests, and that my forms use the "form_for" helper. pretty slick.


        Dave

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://994418]
Approved by McDarren
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (8)
As of 2014-12-27 06:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls