Talk:REST Security Cheat Sheet - Revision history

Jmanico: removed but saved stateless text

2017-11-14T02:41:42Z

removed but saved stateless text

Jmanico: removing statelessness

2017-11-14T02:39:49Z

removing statelessness

Yo: /* Protect Session State */

2017-11-13T20:15:09Z

‎Protect Session State

Yo: /* Authentication in Header */

2017-11-13T20:14:30Z

‎Authentication in Header

Yo: /* Resource protection */

2017-11-13T20:13:15Z

‎Resource protection

Yo: /* REST short definition */

2017-11-13T20:12:33Z

‎REST short definition

Jmanico at 18:42, 13 November 2017

2017-11-13T18:42:32Z

Yo: /* Authentication in Header */

2016-12-13T16:27:18Z

‎Authentication in Header

Jfalken: add author to 'protect session state'

2014-12-08T17:57:11Z

add author to 'protect session state'

Jfalken: add 'protect session state' section considerations

2014-12-08T17:55:37Z

add 'protect session state' section considerations

@@ Line 1: / Line 1: @@
 == Stateless controversy ==
- Each of these REST calls is stateless and the endpoint should check whether the caller is authorized to perform the requested operation.
+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.
 == TODO's from the latest working group (11/2017) ==

← Older revision		Revision as of 02:39, 14 November 2017
Line 1:		Line 1:
		+	== Stateless controversy ==
		+
		+	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) ==		== 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

← Older revision		Revision as of 20:15, 13 November 2017
Line 33:		Line 33:
	[[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.
−
−	~~== Protect Session State ==~~
−
−	~~[[User:jfalken\|Chris Sandulow]]<br />~~
−	Under 'Protect Session State" I think there should be a short discussion of HMAC'ing anything sent to the client. For stateless applications this especially important; many will encrypted (AES-CBC for example), but not use authenticated encrypted or HMAC the blob. I also posted this on reddit /r/netsec and there is some additional points in that thread --> http://www.reddit.com/r/netsec/comments/2ogjkv/rest_security_cheat_sheet/

@@ Line 33: / Line 33: @@
 [[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.
 == Protect Session State ==

@@ Line 29: / Line 29: @@
 [[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?
 == Authentication in Header ==

@@ Line 25: / Line 25: @@
 [[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]
 == Payload Attacks ==

← Older revision		Revision as of 18:42, 13 November 2017
Line 1:		Line 1:
		+	== 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 ==		== Avoiding DOR ==
	[[User:Will Stranathan\|Will]]<br />		[[User:Will Stranathan\|Will]]<br />

← Older revision		Revision as of 17:57, 8 December 2014
Line 31:		Line 31:
	== Protect Session State ==		== Protect Session State ==

		+	[[User:jfalken\|Chris Sandulow]]<br />
	Under 'Protect Session State" I think there should be a short discussion of HMAC'ing anything sent to the client. For stateless applications this especially important; many will encrypted (AES-CBC for example), but not use authenticated encrypted or HMAC the blob. I also posted this on reddit /r/netsec and there is some additional points in that thread --> http://www.reddit.com/r/netsec/comments/2ogjkv/rest_security_cheat_sheet/		Under 'Protect Session State" I think there should be a short discussion of HMAC'ing anything sent to the client. For stateless applications this especially important; many will encrypted (AES-CBC for example), but not use authenticated encrypted or HMAC the blob. I also posted this on reddit /r/netsec and there is some additional points in that thread --> http://www.reddit.com/r/netsec/comments/2ogjkv/rest_security_cheat_sheet/

← Older revision		Revision as of 17:55, 8 December 2014
Line 28:		Line 28:
	[[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.
		+
		+	== Protect Session State ==
		+
		+	Under 'Protect Session State" I think there should be a short discussion of HMAC'ing anything sent to the client. For stateless applications this especially important; many will encrypted (AES-CBC for example), but not use authenticated encrypted or HMAC the blob. I also posted this on reddit /r/netsec and there is some additional points in that thread --> http://www.reddit.com/r/netsec/comments/2ogjkv/rest_security_cheat_sheet/