Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-262

Specify how OData services can be protected against cross-site request forgery (CSRF or XSRF)

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_WD01
    • Fix Version/s: CN01
    • Component/s: Securing OData
    • Labels:
      None
    • Environment:

      [Proposed]

    • Proposal:
      Hide

      Create a TC Note in order "Securing Open Data" to address security issues and add this to that note.

      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.

      Accepted: https://www.oasis-open.org/committees/download.php/49447/odata-meeting-40_on-20130606-minutes.html#odata-262

      Show
      Create a TC Note in order "Securing Open Data" to address security issues and add this to that note. 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. Accepted: https://www.oasis-open.org/committees/download.php/49447/odata-meeting-40_on-20130606-minutes.html#odata-262

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              handl Ralf Handl
              Reporter:
              handl Ralf Handl
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: