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 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.
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.