How Not to write a "REST" API • Hacker News Board

Re: How Not to write a "REST" API

#81

Post by tptacek » Wed, Feb 01, 2012, 6:17 PM UTC

SomeOtherGuy2 wrote: post #20

carbocation wrote: post #18

Earlier quoted context omitted.

POSTed values won't show up in typical server logs, whereas with GET their plaintext password would normally be logged on every request. And POST over HTTPS keeps the POSTed values hidden from those who might listen, whereas with GET over HTTP it would just be out there in the URL.

You have no way of knowing what they log and don't log. If their server logs are compromised, you should be assuming their username/password database was as well. And HTTPS requests are encrypted. The whole request, including the "GET /someurl&password=s33krit HTTP/1.1" part. As I said, using POST doesn't add any additional security to this.

I don't understand the point you're trying to make here, or the stridency with which you're making it. You in fact do know that the most popular web servers do log the URL, and do not log POST parameters or individual headers.

That's why professional security audits will ding you for putting anything sensitive in a URL.

Re: How Not to write a "REST" API

#82

Post by alexchamberlain » Wed, Feb 01, 2012, 6:19 PM UTC

SomeOtherGuy2 wrote: post #73

nickyp wrote: post #44

Earlier quoted context omitted.

It's not 'compliancy' as much as they're reinventing the wheel. REST was born out of a philosophy that the HTTP protocol already solved much of what you wanted to do. HTTP not only solved this, but solved this a long time ago and with 'great success' (aka The Interwebs ;-) - Authentication mechanism - Operations (CRUD) -> GET, PUT, POST, DELETE, ... - Caching -> Use HTTP caching mechanisms... - Resources -> URL's - F…

I'm not saying it is a nice API, or that it is in any way a REST API. Just that unless I am missing something, it is HTTP compliant.

It isn't compliant, it doesn't use the verbs properly.

Re: How Not to write a "REST" API

#83

Post by eli » Wed, Feb 01, 2012, 6:21 PM UTC

bryanh wrote: post #40

eli wrote: post #4

Most of the proprietary APIs I've had to work with were just as bad. Sometimes I wonder if the NDA they make you sign before seeing the API documentation is so that you won't be able to show anyone else how bad it is.

Poignant observation. I'm currently working with an unnamed credit API and all calls, regardless of status, return 200. Options can be strung together in single GET parameter. All calls resolve to a single URL and the method is chosen get a GET param (which variant of that method is yet another param). And a person's information can be passed in via any slew GET params, or as POST'd XML. Its a mess... anyone up for a…

I once spent weeks writing a wrapper for a particular service provider's API (which they charge a premium to access). Every request was a POST and every response was 200. In one function, timestamps were represented by a unix epoch, but others had the same field encoded as ISO 8601. The XML returned was not guaranteed to be well formed. Etc.

The kicker is that they declined permission to open source my wrapper because "the API is proprietary."

Re: How Not to write a "REST" API

#84

Post by csears » Wed, Feb 01, 2012, 6:24 PM UTC

padobson wrote: post #38

euroclydon wrote: post #19

Earlier quoted context omitted.

The query string and headers ARE encrypted in https. And forms auth, that's just a post and a cookie. You can't require API clients to support cookies.

But, and excuse me if I'm wrong on this I'm looking for clarification, you should be forcing API clients to sign their requests with some sort of token - which might as well be a cookie. The difference being that a browser keeps track of the cookies for you, and any other client will have to keep track of any auth info itself (in a sqlite DB, xml file, held in memory, etc)

> sign their requests with some sort of token - which might as well be a cookie

Using a token to sign requests is certainly a good idea, but you probably don't want to pass the token around using a cookie, even over HTTPS. Many browsers don't enforce good cookie security and will transmit cookies in the clear if an attacker can redirect the browser to a non-HTTPS URL on the same domain.

Re: How Not to write a "REST" API

#85

Post by baddox » Wed, Feb 01, 2012, 6:32 PM UTC

mootothemax wrote: post #77

SomeOtherGuy2 wrote: post #37

Earlier quoted context omitted.

>If you're using SSL then form data in a POST request will be encrypted So will everything else, including the URI being requested, and thus the query string in it. Which is why it makes no difference using GET or POST.

So will everything else, including the URI being requested I disagree from the data I'm seeing in the access logs from my SSL-hosted site running nginx. In the logs I can see lines such as: GET /path/script?variable=blahblah&another_variable=123 EDIT since I appear to have lost the ability to reply to comments: I disagree with SomeOtherGuy2 that The fact that it may get logged is a red-herring . Ignoring how secure a…

It's all encrypted over the network. Obviously, your servers have to be able decrypt URL strings (and everything else), or they wouldn't be able to respond correctly. I think the assumption is just that servers may by default log decrypted URLs for GET requests, but not POST requests. But, as people have noted, that's not exactly reassuring, since you have no idea how their logging is set up.

Re: How Not to write a "REST" API

#86

Post by SomeOtherGuy2 » Wed, Feb 01, 2012, 6:34 PM UTC

mootothemax wrote: post #77

SomeOtherGuy2 wrote: post #37

Earlier quoted context omitted.

>If you're using SSL then form data in a POST request will be encrypted So will everything else, including the URI being requested, and thus the query string in it. Which is why it makes no difference using GET or POST.

So will everything else, including the URI being requested I disagree from the data I'm seeing in the access logs from my SSL-hosted site running nginx. In the logs I can see lines such as: GET /path/script?variable=blahblah&another_variable=123 EDIT since I appear to have lost the ability to reply to comments: I disagree with SomeOtherGuy2 that The fact that it may get logged is a red-herring . Ignoring how secure a…

You are very confused. SSL is used to encrypt transmission between the browser and web server. Of course the web server decrypts the data it receives, otherwise it wouldn't be able to use it. I am saying you can not sniff someone's HTTPS traffic and see the urls they are requesting, so sensitive information being in the url is not a problem. The fact that it may get logged is a red-herring, as if someone has compromised the server to gain access to the logs, they can access whatever they want, your username and password included.

Re: How Not to write a "REST" API

#87

Post by peterwwillis » Wed, Feb 01, 2012, 6:35 PM UTC

artanis0 wrote: post #9

adamjernst wrote: post #2

Yeesh. According to this chart: http://nordsc.com/ext/classification_of_http_based_apis.html Sharefile is not even a HTTP API (since it doesn't use HTTP methods correctly). For security purposes, authentication can be further increased by a POST of the "username" and "password" through the HTTP Headers as individual headers instead of the query string. POST https://subdomain.sharefile.com/rest/getAuthID.aspx HTTP/1.1…

As someone just starting to learn about secure restful web services: what is wrong with this security implementation of theirs?

It's wrong because:

1. Passing creds via GET will show up in server logs. 2. The way REST works, you don't want to put anything in a GET which will change anything on the server (which includes generating an auth token). POST is the standard here.

edit It's better that they support POST for the auth creds in a header, but they should still be using HTTP standard authentication methods and return a 401 if unauthorized.

Also, look for already complete solutions for what you want. The whole point of REST is that you don't need to create all these query string parameters or put stuff in headers - the HTTP specs already include most of this functionality. For example HTTP already includes several authentication mechanisms[1], as does TLS[2], which are more secure (and standard!) than a form-based login.

[1] http://en.wikipedia.org/wiki/Digest_access_authentication [2] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Re: How Not to write a "REST" API

#88

Post by SomeOtherGuy2 » Wed, Feb 01, 2012, 6:38 PM UTC

alexchamberlain wrote: post #82

SomeOtherGuy2 wrote: post #73

Earlier quoted context omitted.

I'm not saying it is a nice API, or that it is in any way a REST API. Just that unless I am missing something, it is HTTP compliant.

It isn't compliant, it doesn't use the verbs properly.

Would you care to point out where in the HTTP RFCs it requires the use of certain methods for certain operations? The reality is, you can do whatever you like as far as HTTP is concerned. In fact, only GET and HEAD are required to be implemented, all the other methods are optional.

HTTP does not have "verbs". That is REST. Just because they aren't using a REST API, doesn't mean they are not HTTP compliant.

Re: How Not to write a "REST" API

#89

Post by SomeOtherGuy2 » Wed, Feb 01, 2012, 6:47 PM UTC

tptacek wrote: post #81

SomeOtherGuy2 wrote: post #20

Earlier quoted context omitted.

You have no way of knowing what they log and don't log. If their server logs are compromised, you should be assuming their username/password database was as well. And HTTPS requests are encrypted. The whole request, including the "GET /someurl&password=s33krit HTTP/1.1" part. As I said, using POST doesn't add any additional security to this.

I don't understand the point you're trying to make here, or the stridency with which you're making it. You in fact do know that the most popular web servers do log the URL, and do not log POST parameters or individual headers. That's why professional security audits will ding you for putting anything sensitive in a URL.

Actually, we ding you for putting sensitive information in URLs that are used in a browser. The reason is that it will then be sent to other sites in the referrer header. When it is used for an API it doesn't matter. A security audit will check that logs are not logging sensitive information or that they are properly secured and encrypted if they do contain such information. The combination of telling users to put their password into the url and logging the url would be a problem, but not either thing on its own.

Re: How Not to write a "REST" API

#90

Post by SomeOtherGuy2 » Wed, Feb 01, 2012, 6:52 PM UTC

SimHacker wrote: post #76

SomeOtherGuy2 wrote: post #37

Earlier quoted context omitted.

>If you're using SSL then form data in a POST request will be encrypted So will everything else, including the URI being requested, and thus the query string in it. Which is why it makes no difference using GET or POST.

But you can be 99.994% sure they're writing your plan text user name and password into their logs if you're using get, and if somebody breaks in and gets them, then they have your password, even if those passwords are properly hashed in the user database.

No, I wouldn't be 99.994% sure of that at all. In fact, I would assume that if they are suggesting that people use GET, that they are in fact not logging the query params, as any security audit would catch that.

And again, if they are compromised, then they are compromised. It doesn't matter if they have logging disabled, someone who would have access to the logs also has access to either the httpd account or the root account. Either way, they can already read your plaintext usernames and passwords directly when they are being submitted. Of course, they don't need your username and password anyways, as they already have full access to the system.