CSRF security
Cross-site request forgeries (CSRF) are types of attacks which perform unwanted actions on a web application without the user's intent. This type of vulnerability happens on web applications which use cookies to identify the user. For example, the attacker uses the same cookies to make a fraudulent request, and attempts to lure the user to click a fraudulent link. If the user clicks the link after being authenticated, the fraudulent request performs any actions available to the logged-in user, but without the knowledge of the user.
The forged request works because browser requests automatically include all credentials associated with the web application, such as the logged-in user's session information in cookies. The server cannot distinguish between the forged request from the user and the legitimate request form the user.
CSRF attacks are also known by other names; the main difference is the technique used to perform the attack. The names include XSRF, Sea Surf, Session Riding, and Hostile Liking.
CSRF security in Black Duck
Black Duck now features improved security for attempted cross-site request forgeries (CSRF).
Black Duck uses a Synchronized Token Pattern (STP) to address CSRF. This is a technique where a secret and unique token value is passed along with every request through form data or the header. This token is then verified on the server side. If the tokens do not match, then the request is ignored, and a 403 forbidden error displays. The unique token is generated for each session, not for each request. The same unique token is used for the duration of the session, and a new token is generated for each new session. The token is destroyed when its session is destroyed. The following is an example of the CSRF format:
headerName = X-CSRF-TOKEN parameterName = _csrf token = 484dcea0-82a7-4f3e-9158-f80513ed86f9
When making a REST call to authenticate the user, a POST request (login request) is
made to the URL /j_spring_security_check. The CSRF information is
returned in the response header. The following is an example of the login request
header:
POST /j_spring_security_check HTTP/1.1 Host: qa-hub21.dc1.lan Connection: keep-alive Content-Length: 40 Origin: https: //qa-hub21.dc1.lan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Accept: */* X-Requested-With: XMLHttpRequest X-FirePHP-Version: 0.0.6 Referer: https://qa-hub21.dc1.lan/ Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.8,ja;q=0.6,cs;q=0.4
The following is an example of the returned login response header. The CSRF token is highlighted.
HTTP/1.1 204 Server: nginx/1.10.3 Date: Wed, 14 Jun 2017 16:27:50 GMT Connection: keep-alive X-CSRF-HEADER: X-CSRF-TOKEN X-CSRF-PARAM: _csrf X-CSRF-TOKEN: 484dcea0-82a7-4f3e-9158-f80513ed86f9 Set-Cookie: AUTHORIZATION_BEARER=<token> X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 X-Frame-Options: SAMEORIGIN
To add the CSRF security header to the request:
-
Only if cookies are used, copy the CSRF token from the login response header, and include the CSRF token in each subsequent
POST,PUT,PATCHandDELETErequest headers.
The following is a sample request with the CSRF token passed in using the request header:
POST /api/v1/projects HTTP/1.1 Host: qa-hub21 Connection: keep-alive Content-Length: 180 Origin: https://qa-hub21 X-CSRF-TOKEN: 484dcea0-82a7-4f3e-9158-f80513ed86f9 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Content-Type: application/json Accept: application/json, text/javascript, */*; q=0.01 X-Requested-With: XMLHttpRequest X-FirePHP-Version: 0.0.6 Referer: https://qa-hub21/ui/projects/view:create/action:modal Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.8,ja;q=0.6,cs;q=0.4 Cookie: AUTHORIZATION_BEARER=<token>