

Whitelist Your Routes, "match" is Evil - homakov
http://homakov.blogspot.com/2012/04/whitelist-your-routes-match-is-evil.html
Proposal to make "match" deprecated because it is useless and insecure.
======
jrockway
This reads like one of those ransom notes from the movies where each letter is
cut out of a different magazine, so I don't quite get what he's saying.

Instead of writing:

    
    
        do_thing()
    

He's suggesting you write:

    
    
        if(preconditions_are_met())
            do_thing()
    

?

Sounds good to me.

~~~
homakov
in a nutshell - something like this.

I propose ALWAYS specify HTTP verb for action - because you always know which
way controller#action should be used. If you dont - you are doing it wrong.

~~~
jrockway
Cool. You might want to use less bold text, BTW :)

~~~
homakov
Haha :) +1 I have very poor vocabulary - and use bold to emphasize important
points. Thanks for pointing it out - I will extend my vocab.

~~~
oomkiller
Also, could you tone down the site theme? The scrolling sidebar/topbar etc is
really buggy and keeps getting in the way of your text. I'd suggest just using
jekyll or something with Github pages or maybe just run your own HTTP server
to serve it up.

~~~
homakov
I use blogspot because of slash dot effects. theme is really buggy, shame on
blogger. Changed to simple one.

~~~
oomkiller
Fair enough, that was my biggest gripe anyways.

------
driverdan
They're not new attact vectors but I enjoy Egor's posts and call outs. If
you're a web dev making these mistakes then you need to take the time to learn
about basic web security. You can't count on frameworks to abstract it all
away for you, you have to understand how it works.

The same CSRF rules apply to GET and POST requests. If you're using proper
CSRF protection it doesn't really matter if you do a GET or POST. The only
real difference is that GET requests will be visible to every piece of
hardware between the user and your server whether you're using SSL or not and
will most likely be logged. Also you can upload files via POST.

While it's easier to make users send harmful GET requests by putting the URL
in an image you can simply use JS to POST a hidden form. Thinking POST is
inherently more secure is a false assumption. Both are equally vulnerable to
CSRF.

~~~
jeff18
Just FYI, the entire HTTP request is encrypted with SSL, including the URL.
Otherwise <https://www.google.com/?q=sensitive+query> would be pretty
pointless!

~~~
driverdan
Oops, you're right. The only data exposed would be the hostname and port. Any
query data would be encrypted.

------
yummyfajitas
Egon, any chance you'll take a look at Django and give it the same level of
scrutiny you are giving to rails?

Currently I'm feeling very superior about how my framework is more secure than
yours, but I'd love to see you shoot down that silly notion.

~~~
axiak
I think the fact that Django's url mapper doesn't make it easy to dispatch
based on the method means that Django wouldn't score to highly against this
particular issue. It's easy to put

    
    
        if request.method not in ('POST', 'PUT', 'DELETE', 'PATCH'):
            ...
    

at the top of every method (or use a decorator), but it'd definitely be nice
if this were part of the url dispatcher.

~~~
yummyfajitas
This is true, but at the same time Django doesn't make it easy to mix up get
and post params. Calling request.POST['param'] will raise an exception on a
GET request.

Finding rails issues and then saying "they kinda sorta apply to Django" isn't
as interesting as finding real Django issues.

~~~
axiak
request.REQUEST? Admittedly, people don't use it that much, but it's
definitely there.

~~~
homakov
Thanks for this information! Really, it is $_REQUEST as in PHP.

To yummyfajitas - your message is 50% trolling. Will you allow me to troll a
little bit? I used django and scrapy few years ago and despite the fact it was
better than PHP I would not even dare to compare it with Rails. Rails is that
superior I don't even have words to explain it :D Conclusion: I'm not
interested in Django and its bug because I love rails and wanna make it more
secure anyways. Sorry, but Django is way less convinient to use. Security is
another story though.

~~~
yummyfajitas
Sorry, I didn't intend to sound like I was trolling, my comment "I'm feeling
very superior" was intended to be facetious.

Also, if you ever manage to put into words why you prefer Rails, I'd love to
read it. Django and rails seem pretty similar to me, but I didn't put much
effort into learning rails. But maybe I'm just experiencing the blub paradox.

------
cmwright
Would love to see some more information on best practices for routing. I've
always used <http://guides.rubyonrails.org/routing.html> as a go-to resource
on routing, and it uses 'match' statements throughout. Is the suggestion here
to just change all match statements to the intended REST verb?

~~~
mnutt
The only thing I don't like about the Rails routing guide is how much it talks
about having a default route of `match ':controller/:action/:id'`. I would
still use `match`, but any actions that are meant to be posts should add
`:method => :post` to them. And ideally use `resources` where ever it makes
sense.

~~~
homakov
Fix: not :method but :via :)

And, again! PLEASE use method "data" instead of match :via => method. It's
much better and looks clean.

~~~
tptacek
In exactly what sense do you think that's better?

~~~
homakov
it does absolutely same job(you can read sources) but requires less symbols
and looks RESTful - fair enough, isn't it?

------
there
_But all rails 2.3 apps use map.connect == are vulnerable(holy shi~!)_

Rails 2.3 had "verify :method => :post" which was supposed to be used in
controllers. This is nothing new.

~~~
homakov
call me a bad coder but when I used rails 2.3 I had never seen it in
production code. I was too young though - may be you're right.

Anyways rails 2.3 had no csrf protection

~~~
there
_call me a bad coder but when I used rails 2.3 I had never seen it in
production code._

Ok, then you're a bad coder. All Rails applications I've ever worked on had
those checks and the documentation for Rails made it pretty clear that verify
:method should be used for non-GET requests.

 _Anyways rails 2.3 had no csrf protection_

You really need to check your facts. Rails has had protect_from_forgery since
at least 2.2 and it was enabled by default in ApplicationController. Rails <
2.3.10 did not do the verification for AJAX requests, but this was changed in
2.3.11.

Added in 2007:
[https://github.com/rails/rails/commit/4e3ed5bc44f6cd20c9e353...](https://github.com/rails/rails/commit/4e3ed5bc44f6cd20c9e353ab63fd24b92a7942be)
and made the default shortly after.

~~~
homakov
Appreciate your info! Really, I messed with facts - in 2011 it was made for
AJAX :) You are right!

Ops FIX: you should call bad coder not me but people whom code I had been
reading years ago.

And anyways burke is right: >Supposed to be, but rarely was. Throw a bunch of
new programmers at a framework, and insecure-by-default becomes insecure.

btw verify method: :post is nice to have but obviously uglier than current
routes.rb DSL.

------
gkop
Security aside, the catchall routing directive is a maintenance nightmare. The
router is precisely where you should catch buggy routes, as well as document
valid ones so they come up in rake routes.

------
jopjjjj
blogger and tons of javascript loading wheels.. I just want to read som text,
google how hard can it bee!!!?

~~~
homakov
blogger fail. changed to simple theme

