This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:REST Security Cheat Sheet"
(removed but saved stateless text) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | == Stateless controversy == | ||
| + | |||
| + | The following text was removed. Putting it here because it was a controversial removal since some folks think that REST MUST be Stateless, which I do not agree with. | ||
| + | |||
| + | <i>REST APIs are stateless. Stateful APIs do not adhere to the REST architectural style. State in the REST acronym refers to the state of the resource which the API accesses, not the state of a session within which the API is called. While there may be good reasons for building a stateful API, it is important to realize that managing sessions is complex and difficult to do securely. Stateful services are out of scope of this Cheat Sheet. Passing state from client to backend, while making the service technically stateless, is an anti-pattern that should also be avoided as it is prone to replay and impersonation attacks. Each of these REST calls is stateless and the endpoint should check whether the caller is authorized to perform the requested operation.</i> | ||
| + | |||
== TODO's from the latest working group (11/2017) == | == TODO's from the latest working group (11/2017) == | ||
* describe the scope of the cheat sheet more clearly | * describe the scope of the cheat sheet more clearly | ||
| Line 25: | Line 31: | ||
[[User:Michael Hidalgo|Michael]]<br /> | [[User:Michael Hidalgo|Michael]]<br /> | ||
I was researching between the most popular JavaScript frameworks in order to find a JSON schema validation but it seems that this topic is still immature. But apart from XML and JSON, REST approaches uses syndication feed formats including Atom and RSS.The W3C has a tool for validating those syndication formats.[http://validator.w3.org/feed/#validate_by_uri] | I was researching between the most popular JavaScript frameworks in order to find a JSON schema validation but it seems that this topic is still immature. But apart from XML and JSON, REST approaches uses syndication feed formats including Atom and RSS.The W3C has a tool for validating those syndication formats.[http://validator.w3.org/feed/#validate_by_uri] | ||
| − | |||
| − | |||
| − | |||
| − | |||
== Payload Attacks == | == Payload Attacks == | ||
[[User:Michael Hidalgo|Michael]]<br /> | [[User:Michael Hidalgo|Michael]]<br /> | ||
On top of REST based services,there is a protocol called OData(The Open Data Protocol), OData follows the architectural style of the Web, and allows the HTTP Content negotiation using standard media formats, including XML, JSON, Atom, RSS. Serving data in this formats also increment the risk of payloads attacks. Do you think we should include payloads attacks in this section? | On top of REST based services,there is a protocol called OData(The Open Data Protocol), OData follows the architectural style of the Web, and allows the HTTP Content negotiation using standard media formats, including XML, JSON, Atom, RSS. Serving data in this formats also increment the risk of payloads attacks. Do you think we should include payloads attacks in this section? | ||
| − | |||
| − | |||
| − | |||
| − | |||
== Authentication in Header == | == Authentication in Header == | ||
[[User:Chris Harland|Chris H]]<br /> | [[User:Chris Harland|Chris H]]<br /> | ||
I've seen quite a few examples of REST services available over HTTPS where the authentication mechanism (API key or the Username and Password) are added to the Headers of a GET rather than send via cookie or POST, this is TLS encrypted and doesn't suffer the exposure problems of having this information in the URI. I wondered if anyone had an opinion on this method, good or bad, how could it be exploited? Could you add something about it to this cheat sheet stating if it is acceptable practice. | I've seen quite a few examples of REST services available over HTTPS where the authentication mechanism (API key or the Username and Password) are added to the Headers of a GET rather than send via cookie or POST, this is TLS encrypted and doesn't suffer the exposure problems of having this information in the URI. I wondered if anyone had an opinion on this method, good or bad, how could it be exploited? Could you add something about it to this cheat sheet stating if it is acceptable practice. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 02:41, 14 November 2017
Stateless controversy
The following text was removed. Putting it here because it was a controversial removal since some folks think that REST MUST be Stateless, which I do not agree with.
REST APIs are stateless. Stateful APIs do not adhere to the REST architectural style. State in the REST acronym refers to the state of the resource which the API accesses, not the state of a session within which the API is called. While there may be good reasons for building a stateful API, it is important to realize that managing sessions is complex and difficult to do securely. Stateful services are out of scope of this Cheat Sheet. Passing state from client to backend, while making the service technically stateless, is an anti-pattern that should also be avoided as it is prone to replay and impersonation attacks. Each of these REST calls is stateless and the endpoint should check whether the caller is authorized to perform the requested operation.
TODO's from the latest working group (11/2017)
- describe the scope of the cheat sheet more clearly
- server to server calls is a special case
- coarse- vs fine-grained authZ
- token usage scenario's
- short lived
- bearer
- limitations and mitigations of bearer tokens
- secrets mgmt
- JWK
- key management
- a client can obtain security tokens by doing an OAuth or OIDC dance with an authZ server
Avoiding DOR
Will
My point with the Check Authorization for User-Specific Entities section is to avoid Direct Object Reference. There are really two underlying potential pitfalls here:
- Giving access to objects simply by the key value in the URL rather than checking proper authorization for that entity. (i.e., this user doesn't have access to object 1235, but we allow the method simply because 1235 was in the URL rather than checking to see if this user is allowed to modify/view it)
- Giving away sensitive information simply by including the object ID in the URL. Users tend to copy/paste URL's and they get cached in many different places and included in the history (even if the response gives the right Expires, Cache-control, and Pragma headers), so the URL shouldn't directly include anything sensitive like account number. http://some.service/account/128420482 should be a no-no.
Type Validation
Will
I would love to add a section on validating incoming entity definitions via XML or JSON. In XML, you have to deal first with entity expansion (death by a million laughs) because entities are expanded before the XML itself is validated, then need to validate against a DTD, XML-Schema, etc.
I'm just now finding out that there is a loose definition of a JSON validation scheme [1], but I'm not sure if any of the popular server-side JSON frameworks support this built-in, or what the maturity is of any of the implementations at [2]. Anybody have any knowledge on this?
Michael
I was researching between the most popular JavaScript frameworks in order to find a JSON schema validation but it seems that this topic is still immature. But apart from XML and JSON, REST approaches uses syndication feed formats including Atom and RSS.The W3C has a tool for validating those syndication formats.[3]
Payload Attacks
Michael
On top of REST based services,there is a protocol called OData(The Open Data Protocol), OData follows the architectural style of the Web, and allows the HTTP Content negotiation using standard media formats, including XML, JSON, Atom, RSS. Serving data in this formats also increment the risk of payloads attacks. Do you think we should include payloads attacks in this section?
Authentication in Header
Chris H
I've seen quite a few examples of REST services available over HTTPS where the authentication mechanism (API key or the Username and Password) are added to the Headers of a GET rather than send via cookie or POST, this is TLS encrypted and doesn't suffer the exposure problems of having this information in the URI. I wondered if anyone had an opinion on this method, good or bad, how could it be exploited? Could you add something about it to this cheat sheet stating if it is acceptable practice.
