6

i'm a newbie to server-side programming, so please forgive me if this gets messy. i've been contracted to create a web service to allow authenticated users to access a database. users have to enter a login and password. been reading and reading about REST vs SOAP, and i thought i'd settled on a RESTful design when i came across this statement: "Data that needs to be secure should not be sent as parameters in URIs." this seems like a major demerit against a RESTful approach. i'm aware that with https the password would be encrypted to prevent man-in-the-middle interception, but that leaves the server logs and client history as possible exposure points. is there a RESTful solution out there for this problem, or do i need to go SOAPy? any advice appreciated.

adam
  • 61
  • 1
  • 2
  • 1
    Why would you want to pass the password through on the URI, which is clearly unencrypted plain text? If this is the case then why even bother with a password in the first place? –  Apr 26 '10 at 18:56
  • like i said, i'm a newbie. in researching web services and REST vs SOAP, the consensus that seems to be emerging is that REST is much simpler and is appropriate for most scenarios. in trying to determine what falls under "most scenarios" and what doesn't, i thought i found an exception with authentication; namely, that in a RESTful design, everything was passed either in the URI or in headers, which are both vulnerable. so i'm just trying to find out if this is true, or if there is a safe and RESTful way to authenticate with username and password. – adam Apr 28 '10 at 16:28

3 Answers3

1

Use POST-type requests to transmit the necessary data and include the sensitive portion as a posted field so that it is part of the request body instead of a parameter within the URI.

Amber
  • 507,862
  • 82
  • 626
  • 550
  • I'm not sure how this helps. Could you elaborate? POST won't pass the data through the URI, but it will still be passed. HTTPS takes care of encrypting the data end-to-end, but doesn't do much if you are storing the password anywhere in plain text. – Krisc Apr 26 '10 at 17:16
  • 1
    The OP's question deals with the transmission of the data, not with the storage of it on the server. The main reason for not passing secure data in a URI is that URIs are often logged by things *other* than your individual application, such as web server request logs and browser history. By contrast, these logs and histories generally do *not* record POST fields. – Amber Apr 26 '10 at 17:32
  • If you do need to log the POST field, you could [encrypt the log file](http://stackoverflow.com/questions/629755/creating-an-encrypted-log-file) – Tom Howard Dec 01 '11 at 02:25
1

This is a problem with configuration of your web server not with your application. Mis-configurations can lead to vulnerabilities and this is a good example of that. Web servers can also log POST requests and this is common if your Web Application Firewall detects an attack. I would make sure that logging is turned off in apache because this is probably not required for your application to run properly.

Another more common approach is to use a cookie to maintain the session. The cookie still has to be guarded with https for its entire life.

rook
  • 66,304
  • 38
  • 162
  • 239
1

I think that, to be really RESTful, you should use HTTP authentication (basic or digest), since being forced to log in first isn't in the spirit of REST.

I would like this to be confirmed (or refuted) by someone who knows REST well, though.

Woody Zenfell III
  • 1,905
  • 17
  • 31
p4bl0
  • 3,846
  • 1
  • 22
  • 21
  • 1
    Actually with REST anything goes it isn't strict like soap, this would fix his problem. Just make sure to use https. – rook Apr 26 '10 at 18:53
  • 1
    Another option is to use client-side certificates. You configure your server to only accept requests that are made with certificates you approve or are issued by certificate authorities that you approve. This may not be practical in situations where public access is required, but in those situations where you want to control the client list, it is quite secure. – stand Apr 25 '11 at 20:05
  • @stand true. Ideally it is *the* solution. But, as you say, it's not very "real world" for public access. – p4bl0 Apr 25 '11 at 20:35