Skip to content

Cross-Site Request Forgery Mitigation Mechanism

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 follow this link.

To mitigate this kind of attacks, OData provider use a Double Submit Cookie pattern based security mechanism. Following image depicts design of the aforementioned CSRF mitigation mechanism.

Design

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"
    • First 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 as in JSESSIONID cookie -> Cookie will be shared among related deployments. (Cookie created in 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.