Cross-site Request forgery

Cross-site Request forgery

• Harm: Customer sessions and cookies may be stolen or manipulated, and they may be used to mimic legitimate users, allowing hackers to view or change user records as that user and perform transactions
• Possible causes: Insufficient authentication method used by the application
  
  
• Technical Analysis: Even properly formatted, valid, and consistent requests may have been sent without the user's knowledge. Therefore, the WEB application should check all requests for indications that it is illegal. The results of this test indicate that the application being scanned does not perform this action. The severity of this vulnerability depends on the functionality of the affected application. For example, a CSRF attack on a search page is less severe than an CSRF attack on a transfer or profile update page. If a WEB server is designed to receive a request from a client without any mechanism to verify that the request is actually sent by the client, it is possible for an attacker to induce the client to send the request to the Web server in error, and the request will be considered a real request. This can be done through URLs, image loading, XMLHttpRequest, and so on, and can result in data exposure or unexpected code execution. If the user is currently logged on to the victim's site, the request will automatically use the user's credentials (including session cookies, IP addresses, and other browser authentication methods). By using this method, an attacker could forge the identity of the victim and commit the action in its capacity
• Revised recommendations:

There are several techniques for mitigating threats:

[1] Strategy: library or framework

Use an audited library or framework that does not allow this vulnerability to occur, or provide constructs that are more prone to avoid this weakness.

For example, use a package that can defend against CSRF, such as OWASP Csrfguard-

Http://www.owasp.org/index.php/Cross-Site_Request_Forgery_ (CSRF) _prevention_cheat_sheet

Another example is the ESAPI session management control, which includes components for CSRF-

Http://www.owasp.org/index.php/ESAPI

[2] Ensure that there are no cross-site scripting issues (CWE-79) in the application because most CSRF defenses can be bypassed by using script that is controlled by the attacker.

[3] Generate a unique current logo for each form, place the current sign on the form, and verify the current logo when the form is received. Please ensure that the current logo is unpredictable (CWE-330)-

Http://www.cgisecurity.com/articles/csrf-faq.shtml

Note that this can be bypassed by using XSS (CWE-79).

[4] Identification of particularly dangerous operations. When a user performs a risky operation, a separate confirmation request is sent to ensure that the user wants to perform the action themselves. Note that this can be bypassed by using XSS (CWE-79).

[5] using the "two-time Cookie" method, as described in Felten and Zeller:

When a user accesses a site, the site should generate pseudo-random values and set it as a cookie on the user's machine. The site should require each form submission to include that value as a form and cookie value. When you send a POST request to a site, the request should be considered valid only if the form and cookie value are the same.

Because of the same-origin policy, an attacker could not read or modify the values stored in the cookie. To successfully submit a form as a user, an attacker would have to correctly guess the pseudo-random value. This is extremely difficult if the pseudo-random values are highly confidential. This technique requires JavaScript, so it might not work for browsers that have JavaScript disabled-

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.1445

Note that it is possible to bypass this by using XSS (CWE-79), or to bypass this when using WEB technologies that support attackers to read raw headers from HTTP requests.

[6] Do not use the GET method for any request that triggers a state change.

[7] Check the HTTP Referer header to see if the request originated from the intended page. This can disrupt legitimate functionality because a user or agent may have banned the sending of Referer for privacy reasons. Note that this can be bypassed by using XSS (CWE-79).

An attacker could use XSS to generate deceptive Referer, or generate a malicious request from a page that allows its Referer to be used.

Cross-site Request forgery