# Security considerations with REST calls **URL:** \ **Category:** Ruby\ **Created:** [September 15, 2009, 2:20am UTC](https://www.ruby-forum.com/t/security-considerations-with-rest-calls/175511 "2009-09-15T02:20:27Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![sktib](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c68b51/32.png) [@sktib](https://www.ruby-forum.com/u/sktib)\ **Post date:** [September 15, 2009, 2:20am UTC](https://www.ruby-forum.com/t/security-considerations-with-rest-calls/175511/1 "2009-09-15T02:20:27Z")
Folks, I have joined a development group where developers have created a “REST” interface that passes username and password as parameters (with every call) though the call is made over https e.g. https://?user=&pwd=. It is not truly a REST interface as they have designed it to make all calls as POST (instead of using the other HTTP verbs like PUT/DELETE/GET). I am not comfortable with the username and pwd being sent in with every HTTPS call - doesn’t feel right - but I don’t know how the data gets transferred over the network (the url parameter data vs. the real posted data) and have couple questions. 1. Even if it is a POST with https can’t someone see the username and password in the url going over the network? I am assuming the network sees the url in deciding where to forward it to. Is it any more/less vulnerable if GET/PUT/DELETE is used with https and the username/pwd is passed in url? 2. The REST API will be used by business partners for now but will be opened up for Apps on iPhone and other PDAs down the road. If every REST call is an https call won’t there be significant processing overheads not only on the server side but also on the PDA client side? 3. What is the best practice security model to be used with REST API when the interface will be opened up to the world for all kinds of apps to be built on top of it? (Not planning on OAuth as the data is not expected to be consumed by other website apps) Thanks for your help or any pointers you can provide. -S ---
**Author:** ![sktib](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c68b51/32.png) [@sktib](https://www.ruby-forum.com/u/sktib)\ **Post date:** [September 15, 2009, 3:38am UTC](https://www.ruby-forum.com/t/security-considerations-with-rest-calls/175511/2 "2009-09-15T03:38:23Z")
On Monday 14 September 2009 07:20:29 pm Sj Tib wrote: > I have joined a development group where developers have created a “REST” > interface that passes username and password as parameters (with every > call) though the call is made over https e.g. > https://?user=&pwd=. Ew. But no real problem there. > It is not truly a REST > interface as they have designed it to make all calls as POST (instead of > using the other HTTP verbs like PUT/DELETE/GET). So they’re using POST _and_ a querystring? > I am not comfortable > with the username and pwd being sent in with every HTTPS call - doesn’t > feel right This is how HTTP Authentication often works. > 1. Even if it is a POST with https can’t someone see the username and > password in the url going over the network? No, unless you’re using a proxy server. > I am assuming the network > sees the url in deciding where to forward it to. Not at all. Basic way this would work, at a low level: - You tell your HTTP library to fetch [https://foo.com/bar/baz?user=smith&pwd=god](https://foo.com/bar/baz?user=smith&pwd=god). - The library asks your dns server what [foo.com](http://foo.com) is. - The dns server returns an IP address, call it 1.2.3.4. - The library opens a secure (encrypted) connection to 1.2.3.4. - The library sends “POST /bar/baz?user=smith&pwd=god HTTP/1.1” over the secure channel. - The library sends a few newlines, then the body of the post. - 1.2.3.4 sends the response over the secure channel. Keep in mind, by “http library”, I mean “code running inside your program”. So, the only thing the network can see is: - You asked for [foo.com](http://foo.com) - [foo.com](http://foo.com) is 1.2.3.4 - You connected to 1.2.3.4 - You had some sort of encrypted communication with 1.2.3.4. (Or maybe it was garbage, who knows?) That’s it. Every part of the URL after the hostname is sent over the same encrypted channel as the POST body. (Again, unless you’re using a proxy.) > Is it any more/less > vulnerable if GET/PUT/DELETE is used with https and the username/pwd is > passed in url? Completely irrelevant. It’s still ludicrously bad design – you should be authenticating with a cookie or with HTTP authentication, not with the URL or the post body. But it’s not particularly insecure inside a REST call, assuming that call is being made deep inside the app. However, there are a few potential vulnerabilities, if you do this in a browser. The most obvious one is, the URL (complete with username and password) is now in your history. Some people won’t care – I click “save password” a lot. But some people don’t save passwords, or would like to be able to use a public computer without the password sticking around. And I certainly wouldn’t want any shoulder-surfer to be able to read my password right out of the URL. > If every REST > call is an https call won’t there be significant processing overheads > not only on the server side but also on the PDA client side? Depends. Do you value your clients’ data? Yes? Use https. On the server side, you can put an https proxy in front of it. You can even get machines which will do this in hardware. It’s pretty much a “throw money at it” kind of problem. Again, ask yourself – do you value your clients’ data? Is your clients’ data worth that expense? Probably. On the client side, it’ll drain slightly more battery on an iPhone, but nothing significant, especially compared to what you’re already doing parsing the HTML, applying styles, doing animations, etc etc. It’s worth mentioning that, depending on the sensitivity of the data involved, you might be able to improve performance by switching to something as basic as HTTP challenge/response, and using straight HTTP. Anyone will be able to intercept/mangle the data itself, but they won’t get your password, and you could always force HTTPS for any destructive operations, or for anything particularly sensitive. But, if you use a session cookie, you’ll want HTTPS again, because any eavesdropper can now hijack your session and use that to login. > 1. What is the best practice security model to be used with REST API > when the interface will be opened up to the world for all kinds of apps > to be built on top of it? (Not planning on OAuth as the data is not > expected to be consumed by other website apps) In my opinion, abstract the authentication away, and never put it in the URL – it’s just bad taste. Once properly abstracted, you should be able to do what Rails does with restful\_authentication – you can transparently support http or https (whichever the client wants) or force one or the other, and you can transparently support HTML form + cookie authentication, HTTP authentication, CAS, or anything else you care to implement. Anyone accessing this from a web browser probably wants to use HTML and cookies, while anyone accessing this as an API would probably find it easier to use HTTP auth. People in the outside world should use HTTPS (and you can force it), while anything inside your network (or on the same machine) could probably use HTTP. ---
**Author:** ![sktib](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c68b51/32.png) [@sktib](https://www.ruby-forum.com/u/sktib)\ **Post date:** [September 15, 2009, 7:07am UTC](https://www.ruby-forum.com/t/security-considerations-with-rest-calls/175511/3 "2009-09-15T07:07:28Z")
David - Thanks for your thoughtful answers. Very helpful and very much appreciated. -S ---
**Author:** ![sktib](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c68b51/32.png) [@sktib](https://www.ruby-forum.com/u/sktib)\ **Post date:** [September 16, 2009, 4:01pm UTC](https://www.ruby-forum.com/t/security-considerations-with-rest-calls/175511/4 "2009-09-16T16:01:47Z")
On Tue, Sep 15, 2009 at 1:20 AM, Sj Tib [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Folks, > > I have joined a development group where developers have created a “REST” > interface that passes username and password as parameters (with every > call) though the call is made over https e.g. > https://?user=&pwd=. It is not truly a REST > interface as they have designed it to make all calls as POST (instead of > using the other HTTP verbs like PUT/DELETE/GET). Okay its unfortunate that your subject line mentions REST, as what you are describing is not RESTful in the slightest. What you are describing is an ad hoc DIY protocol that tunnels over HTTP. None of the RESTful constraints are observed. This is basically the kind of pre-SOAP hacking that passed for programmatic use of HTTP back in the nineties. > 1. The REST API will be used by business partners for now but will be > opened up for Apps on iPhone and other PDAs down the road. If every REST > call is an https call won’t there be significant processing overheads > not only on the server side but also on the PDA client side? I wouldn’t be too concerned about the PDA aspect performance wise. But you will take a hit by having all communication over HTTPS. > 1. What is the best practice security model to be used with REST API > when the interface will be opened up to the world for all kinds of apps > to be built on top of it? (Not planning on OAuth as the data is not > expected to be consumed by other website apps) David has a better summary of the options, I won’t rehash them here. For programmatic use, sessionless HTTP authentication, either Basic or Digest is preferred. Basic is secure over HTTPS and is convenient. Digest may be a bit trickier to support at the server end, but it has the advantage that it offers secure authentication over unsecure connections. I can’t comment on the other programmatic authentication schemes, like OAuth or OpenID. I am not familiar enough with them. regards, Richard.