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"
From OWASP
(Added discussion about Direct Object Reference details) |
(Added section on Type Validation) |
||
| Line 1: | Line 1: | ||
== Avoiding DOR == | == Avoiding DOR == | ||
| + | [[User:Will Stranathan|Will]]<br /> | ||
My point with the [[{{PAGENAME}}#Check Authorization for User-Specific Entities|Check Authorization for User-Specific Entities]] section is to avoid Direct Object Reference. There are really two underlying potential pitfalls here: | My point with the [[{{PAGENAME}}#Check Authorization for User-Specific Entities|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 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 <tt>Expires</tt>, <tt>Cache-control</tt>, and <tt>Pragma</tt> headers), so the URL shouldn't directly include anything sensitive like account number. http://some.service/account/128420482 should be a no-no. | * 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 <tt>Expires</tt>, <tt>Cache-control</tt>, and <tt>Pragma</tt> 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 == | ||
| + | [[User:Will Stranathan|Will]]<br /> | ||
| + | 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 [http://en.wikipedia.org/wiki/JSON#Schema], 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 [http://json-schema.org/implementations.html]. Anybody have any knowledge on this? | ||
Revision as of 01:22, 20 December 2011
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?
