CORS OriginHeaderScrutiny - Revision history

Collin Sauve: That's really all you need to know - don't trust the origin header, do your own authentication. Full stop. This additional rambling about having to manage users and passwords is muddying the waters, and isn't neces. true (not all auth is password auth)

2019-02-25T20:05:22Z

That's really all you need to know - don't trust the origin header, do your own authentication. Full stop. This additional rambling about having to manage users and passwords is muddying the waters, and isn't neces. true (not all auth is password auth)

Collin Sauve: Countermeasure B does not help AT ALL. Main recommendation here should be: Don't use the Origin header to validate the sender, as it is not reliable. Why are we recommending adding some overly-complicated mechanism that doesn't actually work?

2019-02-25T20:00:20Z

Countermeasure B does not help AT ALL. Main recommendation here should be: Don't use the Origin header to validate the sender, as it is not reliable. Why are we recommending adding some overly-complicated mechanism that doesn't actually work?

Show changes

Jweiler: syntax corrections

2018-05-30T01:45:37Z

syntax corrections

Jweiler: more syntax corrections

2018-05-30T01:43:29Z

more syntax corrections

Jweiler at 01:36, 30 May 2018

2018-05-30T01:36:13Z

Imifos at 11:58, 20 January 2016

2016-01-20T11:58:50Z

Dominique RIGHETTO at 06:05, 17 August 2013

2013-08-17T06:05:39Z

Dominique RIGHETTO: Complete review of the article and linked code sample in order to fix a critical bug.

2013-08-16T17:35:23Z

Complete review of the article and linked code sample in order to fix a critical bug.

Show changes

Peter Mosmans at 09:30, 18 March 2013

2013-03-18T09:30:17Z

Dominique RIGHETTO at 17:11, 30 January 2013

2013-01-30T17:11:31Z

@@ Line 2: / Line 2: @@
 | type=pls_review
 }}
 == Introduction ==
@@ Line 10: / Line 7: @@
 '''CORS''' stands for '''C'''ross-'''O'''rigin '''R'''esource '''S'''haring.
-Is a feature offering the possbility for:
+Is a feature offering the possibility for:
 * A web application to expose resources to all or restricted domain,
 * A web client to make AJAX request for resource on other domain than is source domain.
@@ Line 16: / Line 13: @@
 This article will focus on the role of the '''Origin''' header in the exchange between web client and web application.
-The basic process is composed of the steps below (sample HTTP resquest/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):
+The basic process is composed of the steps below (sample HTTP request/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):
 * '''Step 1 : Web client sends a request to get a resource from a different domain.'''
@@ Line 71: / Line 68: @@
 Enable authentication on the resources accessed and require that the user/application credentials be passed with the [https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Requests_with_credentials CORS requests].
-If the CORS resources exposed are classified as sensitive (and CORS exposition is mandatory) it's a good option but if the objective is only to ensure that the request originator is really
+It is not possible to be 100% certain that any request comes from an expected client application, since all information of a HTTP request can be faked.
 == Informations links ==

@@ Line 35: / Line 35: @@
 </pre>
-The web client tell the server its source domain using the HTTP request header "'''Origin'''".
+The web client tells the server its source domain using the HTTP request header "'''Origin'''".
 * '''Step 2 : Web application response to request.'''
@@ Line 52: / Line 52: @@
 </pre>
-The web application informs web client of the allowed domain using the HTTP response header '''Access-Control-Allow-Origin'''.
+The web application informs the web client of the allowed domains using the HTTP response header '''Access-Control-Allow-Origin'''.
-The header can contains a '*' to indicate that all domain are allowed OR a specified domain to indicate the specified allowed domain.
+The header can contains either a '*' to indicate that all domains are allowed OR a specified domain to indicate the specified allowed domain.
 * '''Step 3 : Web client process web application response.'''

@@ Line 14: / Line 14: @@
 * A web client to make AJAX request for resource on other domain than is source domain.
-This article will focus on role of the '''Origin''' header in exchange between web client and web application.
+This article will focus on the role of the '''Origin''' header in the exchange between web client and web application.
-The basic process is composed by steps below (sample HTTP resquest/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):
+The basic process is composed of the steps below (sample HTTP resquest/response has been taken from [https://developer.mozilla.org/en-US/docs/HTTP_access_control Mozilla Wiki]):
-* '''Step 1 : Web client send request to get resource from a different domain.'''
+* '''Step 1 : Web client sends a request to get a resource from a different domain.'''
 <pre>
@@ Line 35: / Line 35: @@
 </pre>
-The web client inform is source domain using the HTTP request header "'''Origin'''".
+The web client tell the server its source domain using the HTTP request header "'''Origin'''".
-* '''Step 2 : Web application respond to request.'''
+* '''Step 2 : Web application response to request.'''
 <pre>
@@ Line 62: / Line 62: @@
 == Risk ==
-''A reminder : Into this article we focus on web application side because it's the only part in which we have the maximum of control.''
+''A reminder : This article will focus on the web application side because it's the only part in which we have the maximum of control.''
 The risk here is that a web client can put any value into the '''Origin''' request HTTP header in order to force web application to provide it the target resource content.

@@ Line 81: / Line 81: @@
 '''Option B: We can scrutiny the Origin header value on server side'''
-In this option, the objective is to work between the step 1 and 2 of the CORS HTTP requests/responses exchange process (see above).
+In this option, the objective is to work between steps 1 and 2 of the CORS HTTP requests/responses exchange process (see above).
 To achieve it, we will use JEE Web Filter that will ensure the following points for each incoming HTTP CORS requests:
-# Have only one and non empty instance of the '''origin''' header,
+# Have only one non empty instance of the '''origin''' header,
-# Have only one and non empty instance of the '''host''' header,
+# Have only one non empty instance of the '''host''' header,
-# The value of the origin header is present in a internal allowed domains list (white list). As we act before the step 2 of the CORS HTTP requests/responses exchange process, allowed domains list is yet provided to client,
+# The value of the origin header is present in an internal allowed domains list (white list). This check is done before step 2 of the CORS HTTP requests/responses exchange process, and the allowed domains list will be provided to the client,
-# Cache IP of the sender for 1 hour. If the sender send one time a origin domain that is not in the white list then all is requests will return an HTTP 403 response (protract allowed domain guessing).
+# Cache IP of the sender for 1 hour. If the sender sends any requests with an origin domain that is not in the white list then all requests will return an HTTP 403 response (protract allowed domain guessing).
-We use the method above because it's not possible to identify up to 100% that the request come from one expected client application, since:
+We use the method above because it's not possible to be 100% certain that any request comes from an expected client application, since:
 * All information of a HTTP request can be faked,
 * It's the browser (or others tools) that send the HTTP request then the IP address that we have access to is the client IP address.

@@ Line 1: / Line 1: @@
 Last revision (mm/dd/yy): '''08/16/2013'''
@@ Line 306: / Line 311: @@
-[[Category:OWASP Java Project]]
+[[Category:Java]]
 [[Category:Attack]]
 [[Category:Injection Attack]]

@@ Line 78: / Line 78: @@
 In this option, the objective is to work between the step 1 and 2 of the CORS HTTP requests/responses exchange process (see above).
-To achieve it, we will use JEE Web Filter that will ensure the following points for earch incoming HTTP CORS requests:
+To achieve it, we will use JEE Web Filter that will ensure the following points for each incoming HTTP CORS requests:
 # Have only one and non empty instance of the '''origin''' header,
 # Have only one and non empty instance of the '''host''' header,
@@ Line 89: / Line 89: @@
 <pre style="color:#88421D">In a Enterprise inter application communication it's possible to add a check on the client IP range.
-"Business to business" communication offer possbility to for each part to indicate to others parts the IP range that it will be used by its applications.</pre>
+"Business to business" communication offer possibility to for each part to indicate to others parts the IP range that it will
 '''Sample implementation: Filter class'''
@@ Line 185: / Line 186: @@
 	 */
 	@Override
-	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
+	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
 		HttpServletRequest httpRequest = ((HttpServletRequest) request);
 		HttpServletResponse httpResponse = ((HttpServletResponse) response);

@@ Line 213: / Line 213: @@
 '''Note:'''
 [[Automated Audit using W3AF|W3AF]] audit tools (http://w3af.org) contains plugins to automatically audit web
-application to check if they implement this type of countermeasure.
+application to check if they implements this type of countermeasure.
 <pre style="color:#088A08">