Secure by default? about hanami HOT 19 CLOSED

@thegcat Thanks for asking, security is the next step once the default stack will be stable.

As now we're developing features like Params Whitelisting, which prevents memory exhaustion via the abuse of Symbol. We avoid to accept SQL snippets for queries, so that will make harder to forge an injection attack. We also avoid YAML, because it caused a lot of security issues in the last couple of years.

Speaking of templates: the default engine is ERB, which is unsafe by default. I was thinking to encourage people to use Erubis and when loaded to use EscapedRuby by default.

Erubis::EscapedEruby(*1) class handle '<%= %>' as escaped and '<%== %>' as not escaped.

source

But the problem needs to be dug for all the supported engines.

Also, because the framework still lacks of form facilities, we'll think about forgery request when we will build those features.

What do you think?

from hanami.

Sounds like a plan :-)

Adding rack-protection by default seems like a low-hanging fruit to me though, and the defaults of rack-protection are quite sane. Unless you're completely opposed I'll see about making a pull request and will have a look at the rest.

from hanami.

@thegcat The problem with rack-protection is perf and that features aren't strictly required.

If you have an internal API, or a trusted environment (eg. only you and your coworkers), that overhead isn't necessary.

My original plan about rack-protection was to:

1. to not have it as dependency in the gemspec
2. enable it on demand by uncommenting a configuration.

Let me clarify the last point. We are developing code generators ( #29 ), I'd like to introduce an new setting in Lotus::Configuration to enable that gem as middleware, but to keep that configuration commented.

module Bookshelf
  class Application < Lotus::Application
    configure do
      # If you are exposing your application into an untrusted environment (eg. the internet),
      # you may want to enable this feature.
      #
      # advanced_security true
    end
  end
end

If that feature is turned on, when the application is loaded (see Lotus::Loader) it will require that gem and mount that middleware. The mechanism should be smart enough to return a meaningful error message in case of missing gem.

Do you mind to take care of it? Thanks.

from hanami.

The problem with rack-protection is perf

Do you have numbers on that? (I don't, so maybe the impact is higher than I think).

and that features aren't strictly required.

By that rationale Lotus should not even talk to rack but open a socket itself directly. Who needs the ability to add Middleware anyway? And should you need a reverse proxy or queue system, you can still talk to the socket, easy.

To make a bad car analogy™: ABS and ESP are on by default. I know those techs, but I'd be pretty pissed if someone told me over my car wreck: "you should have activated the turbo-fazer (fictional), that would have shaved 20m off of the braking distance and your car would have come to a stop 10m before hitting the wall".

My point is: "insecure by default is insecure".

If you have an internal API, or a trusted environment (eg. only you and your coworkers), that overhead isn't necessary.

I'd only partially agree to that (imagine another machine of your network is compromised and the hop on the machine hosting that app is that much easier because you can do a path traversal attack to fetch the /etc/passwd and /etc/shadow files…), but for the sake of argument let's discuss this case.

People developing for a trusted environment (which include internal APIs) and with performance considerations in the range of the last few percentiles should be knowledgeable and skilled enough to disable the security they deem unnecessary.

Not including rack-protection to make life easier for those 5% (probably much less) people and making everyone else insecure if one forgets or doesn't know about it is not worth it.

I still stick to my original proposal to add rack-protection and to add an option to disable it (partially or completely). It would add one dependency and about 18KB of required space. If you need to deactivate it, you still can and would have 18KB of used space, which by today's standards I wouldn't consider to be a problem.

from hanami.

Do you have numbers on that? (I don't, so maybe the impact is higher than I think).

https://twitter.com/_brianknapp/status/489115316086001664

I think security should be an opt-out, not an opt-in. Otherwise it's de facto non-existent. But that's just my two cents. (Note that security could be provided by other means besides rack-protection if you see a problem with that particular gem.)

from hanami.

Do you have numbers on that? (I don't, so maybe the impact is higher than I think).

Lotus

Router                 (router.ru)                 7036.45 req/s
Action                 (action.ru)                 6225.49 req/s
Tiny                   (tiny.ru)                   6631.06 req/s
Tiny Action            (tiny_action.ru)            4948.72 req/s
View                   (view.ru)                   4310.54 req/s
Template               (template.ru)               4175.52 req/s
Template Interpolation (template_interpolation.ru) 4075.00 req/s

Lotus + Rack::Protection

Router                 (router_protection.ru)                 3224.94 req/s
Action                 (action_protection.ru)                 2926.06 req/s
Tiny                   (tiny_protection.ru)                   2224.42 req/s
Tiny Action            (tiny_action_protection.ru)            1206.49 req/s
View                   (view_protection.ru)                   1216.94 req/s
Template               (template_protection.ru)               1207.28 req/s
Template Interpolation (template_interpolation_protection.ru) 1213.31 req/s

Source code

from hanami.

I'm also having security concerns as my only reason not to use Lotus for anything serious (yet). I had a look at rack-protection, which seems promising, but it would be great to have something tailored to and shipped with Lotus.

Great work, looking forward to spend more time with Lotus.

from hanami.

Interesting thread - I'm curious to see how Lotus addresses the performance issues that apparently come with the additional security features.

As a detour @jodosha mentioned form integration. Perhaps the wheel should not be reinvented, since Jeremy Evans developed Forme - the plugin for Sequel integration makes it appealing for use with Lotus::Model. If you like a more Class based approach, there is also Reform

from hanami.

I agree that rack-protection should be opt-out, since all public-facing apps are going to need it, and it's a good idea even for internal apps. The performance hit is negligible for anything more than a "hello world" app.

See how Sinatra handles it.

from hanami.

Gents, to clarify: I'm not against rack-protection, I'm just saying that we should probably cherry pick its features for what's useful at this point for Lotus.

from hanami.

Subscribing + saying that security should be opt out, because imo most of the time you do want security protection only if you really know what you're doing you don't want to have

This has an impact on the performance metrics for lotus you show (as seen before) for instance when comparing to rails/sinatra.

Anyhow, interested in how this plays out (if it is rack-protection, something else, or whatever)

Maybe catch you later, and thanks for lotus - looks good so far! :-)

from hanami.

I was investigating a bit why rack-protection was slow, to see if I can speed it up. Since it's composed of many Rack middlewares, I was testing each one to see which ones are the slowest. And it turned out that the ones which are the slowest are the ones that use sessions. And ruby-prof reported that all the time indeed is spent in Rack::Session::Cookie. I will investigate this further.

from hanami.

<3 patches to rack-protection would be more than welcome. In Sinatra, we
disable all session protection middleware automatically if sessions aren't
used.

On Tue, Oct 28, 2014 at 1:10 PM, Janko Marohnić [email protected]
wrote:

I was investigating a bit why rack-protection was so slow, to see if I
can speed it up. Since it's composed of many Rack middlewares, I was
testing each one to see which ones are the slowest. And it turned out that
the ones which are the slowest are the ones that use sessions. And
ruby-prof reported that all the time indeed is spent in
Rack::Session::Cookie. I will investigate this further.

—
Reply to this email directly or view it on GitHub
#64 (comment).

from hanami.

@rkh When I'll introduce security mechanism in Lotus, I'll send PRs to you. Thanks for that gem!

from hanami.

I'm sorry if it sounded wrong, I would love to submit patches to rack-protection, but there isn't anything there that needs to be patched. I will try to get a better understanding of Rack::Session::Cookie, and see if it could maybe be faster (I know it's probably a big bite). Thanks a lot for rack-protection, we need to find a way to use it.

from hanami.

@thegcat @rkh @lasseebert @activestylus @emptyflask @PragTob @janko-m Folks, I've carefully listened and considered your advices: Lotus will adopt a secure by default policy.

Security is an important aspect of web apps, but it's often underestimated. In my career I've seen companies only allocate budget for features, without a serious investment in security.

Having a framework that educates and protects against the top vulnerabilities would limit the attack surface for those companies.

For instance CSRF is still in the top 10 of OWASP, and it's a low hanging fruit to fix for frameworks.

However, I'm not sure if we'll use rack-protection. The first reason is that, security is a complex topic and we can't claim that Lotus is serious about it, by only blindly using that library. We want to evaluate case by case, and where we can reuse components, we'll be happy to include them.

My second concern about rack-protection is still about perf. Because it's a generic tool, each middleware is designed to run in isolation. For instance, in different middleware, it instantiate a Rack::Request to check params. Because Lotus::Controller, already has a in instantiated set of params, we can directly check them and save CPU cycles.

I'm closing this as it was a question and not a specific technical issue. I hope my explanation addressed to all your concerns. As usual, I'm open to any further discussion.

from hanami.

+1 I'm totally fine with people not using rack-protection as long as there
is some means of protection. I'm also open to refactoring rack-protection
(which I have on my Sinatra 2 roadmap, anyway) to address your issues. I do
believe that there is value in sharing such critical code between projects.

On Mon, Jan 5, 2015 at 11:31 AM, Luca Guidi [email protected]
wrote:

Closed #64 #64.

—
Reply to this email directly or view it on GitHub
#64 (comment).

from hanami.

Yay! 👍 Sounds good, thanks @jodosha - will be interesting to see what the solution looks like in the end.

Happy new year and a good way forward for lotus!

from hanami.

Here are the security mechanisms that we want to ship with Lotus v0.3.0: Automatic markup escape, Content-Security-Policy and X-Frame-Options headers, HttpOnly cookies https://discuss.lotusrb.org/t/security-features-for-v0-3-0/34

from hanami.