How Does One-Click Attack Manipulate Anything ?

Cross-Site Request Forgery

Cross-site request forgery colloquially known as one-click attack. It is a type of malicious attack or manipulation by dropping a virus in a victim's network, where unauthorized commands are submitted from a user that the web application trusts. In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.

Other Approaches To CERF

Additionally, while typically described as a static type of attack, CSRF can also be dynamically constructed as part of a payload for a cross-site scripting attack, as demonstrated by the Samy worm, or constructed on the fly from session information leaked via offsite content and sent to a target as a malicious URL. CSRF tokens could also be sent to a client by an attacker due to session fixation or other vulnerabilities, or guessed via a brute-force attack, rendered on a malicious page that generates thousands of failed requests. The attack class of "Dynamic CSRF", or using a per-client payload for session-specific forgery, was described in 2009 by Nathan Hamiel and Shawn Moyer at the BlackHat Briefings, though the taxonomy has yet to gain wider adoption.

Why Do CSRF Vulnerabilities Exist?

1In order to explain why this class of vulnerabilities exist, it is necessary to understand a standard authentication flow. When a user that logs in to www.vulnerablesite.net the user would receive a SESSION_ID cookie. This cookie is used by the application to identify who the request is coming from, and that they are authenticated to the application. Since the HTTP protocol is stateless, session cookies are often used to identify and differentiate between different users. When browsers have session cookies saved for authentication and authorization for a target site, it will include them automatically include them in a cross-site fashion. For example, if a user logs into www.vulnerablesite.net, and then browses to www.attackercontrolled.com, the latter domain would not able to read cookies from the initial website. However, if there is a request on www.attackercontrolled.com that sends a request to www.vulnerablesite.net, any saved SESSION_ID for www.vulnerablesite.net would be sent along with it.

A successful CSRF exploitation of such behaviour requires an attacker to set up a malicious website under their control to send GET or POST requests to www.vulnerablesite.net. Ideally, this would be done without any additional user interaction other than visiting the attacker-controlled page. Given that www.vulnerablesite.net has a section where after users have logged in, allowed them to change their passwords, email address, or shipping address, merely navigating to the attacker-controlled page would effectively change any or all of these values. Please note that this attack can only be carried out if it meets the pre-requisites for a traditional CSRF attack. With the introduction of modern web frameworks, CSRF vulnerabilities are harder to exploit. Sometimes, the requests that make changes to the user’s email address, password, and/or shipping address may be handled by a PUT, DELETE or a PATCH request. While these HTTP methods may not be sent via an HTML form, attackers can still make use of the XHR or fetch API to craft a CSRF attack especially if there is a CORS misconfiguration which will allow an attacker’s website to send these requests to the victim’s origin. Again, this assumes that the pre-requisites for a modern CSRF attack is met.

Pre-requisites for a Traditional CSRF Attack

Pre-requisites for a Modern CSRF Attack

A modern CSRF attack is not carried out through an HTML form and is usually done by utilizing PUT, DELETE, or PATCH methods.
• Content-type for the request is either text/plain, multipart/form-data, or application/x-www-form-urlencoded
• The vulnerable application must not set any custom request headers
• Ability to avoid a CORS preflight request

CSRF Attack Scenario

Let’s walk through a fictitious example of the same grocery store used in the SQL Attack Scenario.
The grocery web application allows users to log in to change their username settings, passwords, and shipping and billing addresses. To discover a CSRF vulnerability, an attacker would replace the process of updating a user’s information to observe whether or not session cookies are being used for authentication and authorization, whether or not the update account flow has any non-predictable parameters, check if there are any CSRF prevention mechanisms and evaluate their effectiveness. Some parameter values that don’t change in most applications include (these fields vary from application to application):
• Email Address
• Password Field
• Shipping
• Account Number
• Transfer Amount
Once this information is obtained, an attacker can host a page that mirrors the real site and craft a form that sends the exact request that the application does in a legitimate account update flow. The screenshot below shows an example where an account’s password change on www.vulnerablesite.net has a predictable parameter of “changepass” for a password change and the logged in user is associated with the “session_id.”

Prevention CSRF Attacks

Cross-site request forgery (CSRF) is a web site vulnerability where a valid user’s browser is used to send a malicious request, possibly via an iFrame. Because the browser sends cookies on a domain basis, if the user is currently logged in to an application, the user’s data may be compromised. For example, consider a scenario where you are logged in to the administration console in a browser. You receive an email message containing a link. You click the link, which opens a new tab in your browser. The page that you opened contains a hidden iFrame that makes a malicious request to the forms server using the cookie from your authenticated AEM forms session. Because User Management receives a valid cookie, it passes the request.

---