6 ms·

Yeesh. According to this chart: http://nordsc.com/ext/classification_of_http_based_apis.html http://nordsc.com/ext/classification_of_http_based_apis.html Shar

Yeesh. According to this chart: http://nordsc.com/ext/classification_of_http_based_apis.html 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 https://subdomain.sharefile.com/rest/getAuthID.aspx HTTP/1.1 Content-Type: application/x-www-form-urlencoded password: yourpassword username: email@address.com What... I don't even...

alexchamberlain 15y ago
That is spectacularly bad, I wonder if they know RFCs exist.
artanis0 15y ago
As someone just starting to learn about secure restful web services: what is wrong with this security implementation of theirs?
- deleted 15y ago
  [deleted]
- anty 15y ago
  Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.
  - SomeOtherGuy2 15y ago
    No they aren't sent plain-text: >https://subdomain.sharefile.com/rest/getAuthID.aspx https://subdomain.sharefile.com/rest/getAuthID.aspx Notice the https. The facepalm is just that there's no additional security in using POST vs GET.
    - carbocation 15y ago
      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.
      - SomeOtherGuy2 15y ago
        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.
        carbocation 15y ago
        I agree with your concerns. But my comment was talking about "typical server logs" and HTTPS-POST vs HTTP-GET, while yours is addressing different issues.
        SomeOtherGuy2 15y ago
        I addressed why what gets in logs doesn't matter: if their server is compromised you have to assume you are boned anyways. And I don't understand why is your comment would be talking about "HTTP-GET"? The API in question is dealing with HTTPS for both GET and POST requests.
        cristoperb 15y ago
        I don't understand why your comments pointing out details of the http spec and common-sense security considerations are being downvoted. I guess they are coming across as overly 'stident'? Anyway, I've found them helpful. Thanks.
        tptacek 15y ago
- alexchamberlain 15y ago
  It's not compliant with the HTTP standard.
  - SomeOtherGuy2 15y ago
    In what way is it not compliant?
    - alexchamberlain 15y ago
      Custom headers should be prepended with "X-". Also, the top line should read POST rest/getAuthID.aspx HTTP/1.1 Correction: Use of "X-" has been depreciated in a draft resolution. Edit: As mentioned below, it isn't compliant in its use of the verbs (GET/POST etc).
      - SomeOtherGuy2 15y ago
        Custom headers do not REQUIRE a prefix. So the lack of prefix does not make it non-compliant. In fact, the HTTP RFC doesn't even say they SHOULD have a prefix. And RFC822 which defines headers only says that protocol mandated headers MUST NOT be prefixed with "X-". Also, there's a draft proposal to deprecate the "X-" header prefix as it does more harm than good: http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 Second, absolute URIs are perfectly valid, all HTTP/1.1 servers MUST accept them: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1
    - nickyp 15y ago
      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 - Formats -> mime-types + use a HTTP Accept: header - ... They reinvent the wheel on many of the bullet points above: custom operations, custom format handling, custom authentication mechanisms, ... That's why this really is one of the worst implementation of an 'RESTful' API
- stevejalim 15y ago
  If you're learning about REST, do it right and make this book your bible - it's brilliant: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260a http://www.amazon.com/Restful-Web-Services-Leonard-Richardso...
  - dlokshin 15y ago
    Correct link: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260 http://www.amazon.com/Restful-Web-Services-Leonard-Richardso...
    - stevejalim 15y ago
      Whoops, sorry!
  - danellis 15y ago
    Why should that particular book be the bible? I haven't read it, but I've flicked through it and seeing things like the suggestion that clients should "construct" URLs made me doubt its worth. Shouldn't Fielding's original thesis be the bible?
    - stevejalim 15y ago
      Ok, maybe bible was used to loosely. In my experience, I found it a well written, well balanced, useful primer for real-world development of RESTful web services that also has enough depth to make it a reference I've returned to since. That's better.
- peterwwillis 15y ago
  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 http://en.wikipedia.org/wiki/Digest_access_authentication [2] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
danellis 15y ago
I once worked with a major product from a large company that hilariously used these two HTTP headers: passwd: yourpassword quoted-passwd: "yourpassword"

alexchamberlain 15y ago

That is spectacularly bad, I wonder if they know RFCs exist.

artanis0 15y ago

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

deleted 15y ago
[deleted]
anty 15y ago
Username and password are still sent in plain-text. You could use HTTPS to make the communication secure.
- SomeOtherGuy2 15y ago
  No they aren't sent plain-text: >https://subdomain.sharefile.com/rest/getAuthID.aspx https://subdomain.sharefile.com/rest/getAuthID.aspx Notice the https. The facepalm is just that there's no additional security in using POST vs GET.
  - carbocation 15y ago
    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.
    - SomeOtherGuy2 15y ago
      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.
      - carbocation 15y ago
        I agree with your concerns. But my comment was talking about "typical server logs" and HTTPS-POST vs HTTP-GET, while yours is addressing different issues.
        SomeOtherGuy2 15y ago
        I addressed why what gets in logs doesn't matter: if their server is compromised you have to assume you are boned anyways. And I don't understand why is your comment would be talking about "HTTP-GET"? The API in question is dealing with HTTPS for both GET and POST requests.
        cristoperb 15y ago
        I don't understand why your comments pointing out details of the http spec and common-sense security considerations are being downvoted. I guess they are coming across as overly 'stident'? Anyway, I've found them helpful. Thanks.
      - tptacek 15y ago
alexchamberlain 15y ago
It's not compliant with the HTTP standard.
- SomeOtherGuy2 15y ago
  In what way is it not compliant?
  - alexchamberlain 15y ago
    Custom headers should be prepended with "X-". Also, the top line should read POST rest/getAuthID.aspx HTTP/1.1 Correction: Use of "X-" has been depreciated in a draft resolution. Edit: As mentioned below, it isn't compliant in its use of the verbs (GET/POST etc).
    - SomeOtherGuy2 15y ago
      Custom headers do not REQUIRE a prefix. So the lack of prefix does not make it non-compliant. In fact, the HTTP RFC doesn't even say they SHOULD have a prefix. And RFC822 which defines headers only says that protocol mandated headers MUST NOT be prefixed with "X-". Also, there's a draft proposal to deprecate the "X-" header prefix as it does more harm than good: http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02 Second, absolute URIs are perfectly valid, all HTTP/1.1 servers MUST accept them: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1
  - nickyp 15y ago
    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 - Formats -> mime-types + use a HTTP Accept: header - ... They reinvent the wheel on many of the bullet points above: custom operations, custom format handling, custom authentication mechanisms, ... That's why this really is one of the worst implementation of an 'RESTful' API
stevejalim 15y ago
If you're learning about REST, do it right and make this book your bible - it's brilliant: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260a http://www.amazon.com/Restful-Web-Services-Leonard-Richardso...
- dlokshin 15y ago
  Correct link: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260 http://www.amazon.com/Restful-Web-Services-Leonard-Richardso...
  - stevejalim 15y ago
    Whoops, sorry!
- danellis 15y ago
  Why should that particular book be the bible? I haven't read it, but I've flicked through it and seeing things like the suggestion that clients should "construct" URLs made me doubt its worth. Shouldn't Fielding's original thesis be the bible?
  - stevejalim 15y ago
    Ok, maybe bible was used to loosely. In my experience, I found it a well written, well balanced, useful primer for real-world development of RESTful web services that also has enough depth to make it a reference I've returned to since. That's better.
peterwwillis 15y ago
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 http://en.wikipedia.org/wiki/Digest_access_authentication [2] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

danellis 15y ago

I once worked with a major product from a large company that hilariously used these two HTTP headers: passwd: yourpassword quoted-passwd: "yourpassword"