Cross-Site Request Forgery Mitigation Mechanism

Introduction

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. For more information, see here.

To mitigate these kind of attacks, OData provider uses a Double Submit Cookie pattern-based security mechanism. The following image depicts the design of the aforementioned CSRF mitigation mechanism.

Implementation Details

• CSRF-Header Name: X-XSRF-TOKEN

• CSRF-Cookie Name: XSRF-TOKEN

• Protected HTTP Requests

  • Requests using HTTP method other than GET, OPTIONS, HEAD

• The GET request is used to return CSRF cookie.

  • XSRF-TOKEN: {WEYX-SUMQ-ZGBR-9MGL-LOFX-U4LK-5AX5-UPB0}

• Properties of CSRF-Cookie

  • Session Cookie - Cookie only expires when browser session is destroyed
  • Secured - It will be passed to server only through https
  • Path is set with the JSESSIONID cookie - Cookie will be shared among related deployments. The cookie created in the main will also be sent to main-extensions.
  • Will be updated only by protected requests if refresh is enabled

• CSRF attack detection

  • Protected Request (POST, DELETE, PUT, PATCH)
  • CSRF-Header and/or CSRF-Cookie is not present || CSRF-Header and CSRF-Cookie value mismatch

• Response for CSRF attack

  • HTTP status: 403 Forbidden
  • Error Code: " CSRF\_ERROR
  • Error Message: " A security error occurred while processing the request.

• CSRF protected ODP deployments by Default

  • main, main-extensions, b2b, b2b-extensions

• CSRF unprotected ODP deployments by Default

  • Integration

• IFS Console Arguments for enabling CSRF protection

  • -D odp.csrf.protection.enabled = true/false - Default is true
  • -D odp.csrf.token.refresh.enabled = true/false - Default is false

Connecting through third party Apps

Refer this link for information on implementing the above for Microsoft Power Apps and Logic Apps.