What is a CSRF attack: how it works and how to mitigate it as much as possible

A cross-site request attack is a type of obfuscated proxy cyberattack that causes a user to inadvertently use their credentials to trigger state-changing actions such as transferring funds from their account, changing their email address and password, or some other unwanted action.

An obfuscated deputy is a computer program that uses its authority by trickery. This risk associated with this kind of vulnerability is why capability-based security helps mitigate the risks associated with misuse. For example, when installing software, most computers today require the user to log in. This helps prevent unintentional code execution when a user accidentally uses their authorization credentials.

How to prevent cross-site scripting

There is no single cross-site scripting mitigation strategy, and different types of web applications require different levels of protection. A number of protective measures can be taken:

• If possible, avoid HTML in the input. One very effective way to avoid constant cross-site scripting attacks is to prevent users from posting HTML in form inputs. There are other options that allow users to create rich content without using HTML, such as markdown and WYSIWYG editors.
• Input validation. Validation means implementing rules that prevent the user from submitting data to a form that does not meet certain criteria. For example, inputs that ask for the user’s “last name” should have validation rules that allow the user to submit data that consists of only alphanumeric characters. Validation rules can also be configured to reject any tags or characters commonly used in cross site scripting, such as “<script>” tags.
• Data cleaning. Data cleaning is similar to validation, but occurs after the data has already been sent to the web server, but before it is displayed to another user. There are several online tools that can scrape HTML and filter out any malicious code injections.
• Taking Security Measures for Cookies. Web applications can also set specific rules for handling cookies that can mitigate file theft through cross-site scripting. Cookies can be tied to specific IP addresses to prevent attackers using cross-site scripting from gaining access to them. You can also create rules to block JavaScript access to cookies.

Configuring WAF Rules-WAF can also be configured to enforce rules that prevent cross-site scripting from being reflected. These WAF rules use strategies that block strange requests to the server, including cross-site scripting attacks. Cloudflare WAF offers a “rental” installation and protects web applications from cross-site scripting, DDoS attacks, SQL injection, and other common threats.

Cross-site request forgery

While the potential impact on the average user is significant, a successful CSRF attack on an administrative account can compromise the entire server, potentially leading to the complete takeover of a web application, API, or other service.

How cross-site request forgery works

This attack targets state-changing requests, which are the type of request that changes data from one value to another. For example, a target request might make a purchase or change a value in an account. Interestingly, this is a “blind attack” and does not return any data to the attacker, making it a poor choice for stealing data.

Here is an example of the 4th step in a cross-site request forgery attack:

1. The attacker creates a fake request that, when triggered, transfers $10,000 from a specific bank to his account.
2. The attacker inserts a fake request into a hyperlink and sends it in bulk emails and also embeds it in websites.
3. The victim clicks on an email or website link posted by the attacker, which results in the victim contacting the bank to transfer $10,000.
4. The banking server receives the request, and since the victim is properly authorized, it treats the request as legitimate and transfers the funds.

CSRF attacks vary in methodology, but typically have the following characteristics:

• They use websites that rely on the user’s identity;
• They trick the user’s browser into sending HTTP requests to the target site;
• These include the use of HTTP requests, which have side effects and do not have proper CSRF protection on the site.

Different HTTP commands have different vulnerabilities to CSRF attacks, resulting in different security strategies. It has to do with how web browsers process requests.

HTTP GET requests have built-in options such as internal image tags that can be manipulated and used. Generally, GET requests do not change state, making them ineffective as CSRF targets for a properly implemented web application or other resource.

HTTP POST is used to change state, which increases the need for security. To this end, web browsers implement security measures called same-origin policy (SOP) and resource sharing (CORS), which contains the cross-origin security policy. SOP only allows requests from the same origin and CORS only allows certain types of requests to come from a different origin. The combination of these implementations helps prevent CSRF attacks (among others) by limiting the ability of a request or web page to interact with another origin.

Other HTTP commands such as PUT and DELETE can only be fired with SOP and CORS, which reduces cross-site attacks. Although rare, some websites will explicitly disable these security measures, and they can also be disabled from inside the web browser.