[OASIS Issue Tracker] Updated: (ODATA-262) Specify how OData services can be protected against cross-site request forgery (CSRF or XSRF)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/ODATA-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Zurmuehl updated ODATA-262:
----------------------------------

    Proposal: 
The client adds the header 

    X-CSRF-Token: Fetch

to a GET request. The header value "Fetch" is case-insensitive. 

The server adds the same header to the response. The header value is generated by the server. It is opaque, i.e. the client has to copy it verbatim without alteration. As a consequence it is case-sensitive.

The client adds this header with the copied, unaltered value to subsequent POST, PUT, PATCH, or DELETE requests.

The server accepts the modifying request if and only if the provided CSRF token is still valid. 

If the token is invalid, the server responds with 403 Forbidden and includes the response header

    X-CSRF-Token: Required


If a server requires a CSRF token for modifying requests, it MUST issue a CSRF token in responses to GET requests to the service document as this is the only well-known and small resource of a service. To guarantee freshness of the CSRF token the server MUST include cache control headers that advise intermediaries and clients to refresh their caches. The refresh period or point in time MUST be chosen to guarantee that the caches are refreshed before the CSRF token expires.

The service SHOULD issue a CSRF token in responses to GET requests to other resources whose cache residence period is sufficiently shorter than the CSRF token validity period.

The client MUST NOT assume to get a CSRF token in responses to GET requests to the metadata document, as this is typically not small and SHOULD be cached anyway, so there's no guarantee to get a fresh CSRF token.

For $Batch the X-CSRF-Token MUST be provided as a header. It's not allowed to specifiy any X-CSRF-Token in the "inner" requests.

  was:
The client adds the header 

    X-CSRF-Token: Fetch

to a GET request. The header value "Fetch" is case-insensitive. 

The server adds the same header to the response. The header value is generated by the server. It is opaque, i.e. the client has to copy it verbatim without alteration. As a consequence it is case-sensitive.

The client adds this header with the copied, unaltered value to subsequent POST, PUT, PATCH, or DELETE requests.

The server accepts the modifying request if and only if the provided CSRF token is still valid. 

If the token is invalid, the server responds with 403 Forbidden and includes the response header

    X-CSRF-Token: Required


If a server requires a CSRF token for modifying requests, it MUST issue a CSRF token in responses to GET requests to the service document as this is the only well-known and small resource of a service. To guarantee freshness of the CSRF token the server MUST include cache control headers that advise intermediaries and clients to refresh their caches. The refresh period or point in time MUST be chosen to guarantee that the caches are refreshed before the CSRF token expires.

The service SHOULD issue a CSRF token in responses to GET requests to other resources whose cache residence period is sufficiently shorter than the CSRF token validity period.

The client MUST NOT assume to get a CSRF token in responses to GET requests to the metadata document, as this is typically not small and SHOULD be cached anyway, so there's no guarantee to get a fresh CSRF token.

Note that, for batch, the header should be on the batch, not a statement within the batch.


> Specify how OData services can be protected against cross-site request forgery (CSRF or XSRF)
> ---------------------------------------------------------------------------------------------
>
>                 Key: ODATA-262
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-262
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>          Components: OData Protocol 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_WD01
>
>
> A good CSRF protection pattern is that the server issues a CSRF token that is communicated to the in a special header in responses to GET requests.
> This CSRF token must be included in a special header in subsequent modifying requests.
> To guarantee interoperability between different OData implementations the choreography, header names, and header formats must be standardized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira