Hacker News Reader

Comment by ge0rg | Hacker News Reader

Many intermediate systems such as proxies, load balancers, caches, and firewalls, however, do only support GET and POST. This means that HTTP requests with DELETE and PUT are simply blocked. To circumvent this restriction many REST-based APIs or web frameworks such as the Play Framework 1, provide headers such as X-HTTP-Method-Override, X-HTTP-Method or X-Method-Override for tunnel blocked HTTP methods

This is so f*ing scary. Who in their right mind invents such crazy tricks that absolutely circumvent all we know about web API security, implements them in frameworks, and leaves them enabled by default?

View on HN

People who have to deal with end users behind overly restrictive corporate firewall. After you get a few hundred bad reviews telling you your website is broken, it looks very tempting to just fix it on your end.

Maybe don't fix it and just accept that organization X doesn't want it's users to access your resource?

Seems more reasonable than trying circumvent a legitimate restriction. Not every block is an adversary which needs defeating.

Businesses in fact, like money.

Right, and mine likes productivity. I'm sure the business that's expending resources to try and circumvent my firewalls has a firewall and a usage policy that their employees adhere too also.

So if you circumvent my original blocks, as an administrator, I will use my home-field advantage to just start targeting your individual users and remote resources. Suddenly your users can't even get on Google. Then they'll have to come to me for "the talk."

So the decision quickly becomes a) circumvent enough firewalls that you blacklist yourself or b) get all your users blacklisted for using your service.

You're assuming those blocks are there for a reason. But blocking PUT makes no sense. Getting blacklisted here requires a very special mix of incompetence and pettiness that is thankfully rare.

Hah! I see that you've never been on the customer side of these issues. Try explaining "we can't fix cuz it's not our problem" or "we can't fix cuz our moral compass is just and we shouldn't do things that compromise security over usability"

How about; "It appears our services are blocked by some sort of company firewall or security policy on your end. This is an issue that you should bring up with your IT department. If you can advocate to get them to lift the block against our platform we can offer you XXX"

You have to balance it against expecting to receive: "That's funny, because we tried a similar product from Slightly Unjust Moral Compasses, LLC and it worked fine. We'll just switch to them. Goodbye."

Guess you haven't worked with any large companies... They're always the ones that cause these kinds of problems, not the small flexible ones. Those large companies are also the ones that will pay the most to solve their problems via external services (both due to number of users and how slow it would be to deal with internally).

"That is managed by X department, we can put in a change request and we'll probably get a timeline for the fix at the beginning of next quarter. We'll re-evaluate if you can help with our issue once they get back to us."

... and you'll never hear from them again.

What is the legitimate restriction? You'll let "users" POST but not PUT? In what Mordacian fever-dream is that reasonable?

Guess what? Browsers still work this way.

https://caniuse.com/#feat=mdn-api_xmlhttprequest

The PUT and DELETE methods can't be used with HTML forms.

https://softwareengineering.stackexchange.com/q/114156

Forms aren't the only sources of HTTP requests.

They should at least put appropriate Vary header in the response, or make it non-cacheable altogether (you probably don't want to cache DELETE or POST anyway). Whoever implemented that functionality and didn't include that screwed up.

First of all, when using HTTPS isn't the method encrypted? That should prevent proxies from messing with things and make this less of an issue over time, I'd imagine.

But more to your point, one consideration is CORS performance. If you want to allow non "simple" requests and still avoid CORS preflight requests, you pretty much have to tunnel everything through POSTs, and handle cross-origin security on the server side. Yes this bad for security, but the spec folks haven't given us a performant alternative that I'm aware of.

> when using HTTPS isn't the method encrypted?

We're talking about caching proxies run by sites. These terminate SSL and work in the clear, because their whole job is to take the response one user got and efficiently distribute it to all the other users who want the same thing.

It's only "dangerous" because the cache server does not care about headers. I don't see how this could affect security without broken cache server in place. If you are using the framework you should know how the dispatching works. I agree it could be disabled by default tough.

It's just an information for the routing system to dispatch a different method on a controller. You could implement a way to use a query string to pass this override too. An API framework does not have to be RESTful. It could work with POST requests only and simulate deletes with something like ?method=delete.

Edit: I saw a GitHub comment that actually says it is possible to use query string to override the method in Play 1.

https://github.com/playframework/play1/issues/1300#issuecomm...

> We've found that although the header is disabled, its still possible to use X-HTTP-Method-Override by passing as a query string

This is why I've struggled to understand why CORS is implemented the way it is. It's so easy for developers to circumvent, but the solution is always hacky and/or semantically diluted, so you're worse off in the end.

Some platforms have really terrible HTTP apis. Your choices usually end up as:

a) don't support that platform and lose out on that audience

b) embed your own HTTP library with your client

c) do everything with POST and always return HTTP 200, because every http library supports that.

Or I guess

d) use C, but with headers to pretend that you're seeing an action other than POST.

Unity's built in web requests were like that a few years ago, they only supported GET (with no payload) or POST, so I and many other game platform developers had to implement (d). Most famously, Parse did it too.

It's been my job since 2005 to evaluate deployments of applications like these and I'm not sure I can call to mind any application I've ever seen that would have been insecure but for a perimeter filter on methods. URL-space, yes; I've seen things where "/admin" was perimeter-filtered. Methods, no: I've never seen an application where "PUT" was allowed on the internal network but perimeter-filtered so it wasn't allowed on the public network.

It's clearly happened, though; you can search for vulnerabilities tied to it. I just don't think it's all that common. Someone got a bounty from Google for a cloud.google.com service that used an internal proxy where XMO got them control over a PUT.

That doesn't make sense. Why would an ALB only support GET and POST and not the entire REST protocol?

Also a firewall usually operates at layer 4 not 7.

You are right many firewalls operate on layer 4, but there are also Web Application Firewalls like ModSecurity which inspect HTTP messages on Layer 7.

Because it's old or has a whitelisted set of verbs that hasn't been updated since 1999.

Reply on news.ycombinator.com