What is CSRF

 

Hello! And welcome to this blog post!

 

I’m excited to say that today, we are going to dive into the first vulnerability type that I learned CSRF, or Cross-Site Request Forgery.

 

Cross site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.

 

A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft—including stolen session cookies.

 

CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.

 

 

CSRF example

 

Before executing an assault, a perpetrator typically studies an application in order to make a forged request appear as legitimate as possible.

 

For example, a typical GET request for a $100 bank transfer might look like:

 

 

A hacker can modify this script so it results in a $100 transfer to their own account. Now the malicious request might look like:

 

 

A bad actor can embed the request into an innocent looking hyperlink:

 

 

Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer.

 

Note that if the bank’s website is only using POST requests, it’s impossible to frame malicious requests using a <a> href tag. However, the attack could be delivered in a <form> tag with automatic execution of the embedded JavaScript.

 

This is how such a form may look like:

 

 

Another example of CSRF attack:

 

A CSRF attack works as follows. While accessing the bank account, the user simultaneously browses some other websites. One of the sites ‘www.somesite.com’, contains a hidden form and a piece of JavaScript. As soon as the user visits the webpage, the browser silently submits the hidden form to ‘fictitiousbank.com’. The format and content of the request are exactly the same as the request triggered by the user clicking the submit button in the “pay bill” form provided by the bank. On sending the request, the user’s browser automatically attaches the authentication cookies to the request. Since the session is still active on the server, the request will be processed by the server as issued by the user.

 

 

Methods of CSRF mitigation

 

A number of effective methods exist for both prevention and mitigation of CSRF attacks. From a user’s perspective, prevention is a matter of safeguarding login credentials and denying unauthorized actors access to applications.

 

Best practices include:

 

• Logging off web applications when not in use
• Securing usernames and passwords
• Not allowing browsers to remember passwords
• Avoiding simultaneously browsing while logged into an application

 

For web applications, multiple solutions exist to block malicious traffic and prevent attacks. Among the most common mitigation methods is to generate unique random tokens for every session request or ID. These are subsequently checked and verified by the server. Session requests having either duplicate tokens or missing values are blocked. Alternatively, a request that doesn’t match its session ID token is prevented from reaching an application.

 

Double submission of cookies is another well-known method to block CSRF. Similar to using unique tokens, random tokens are assigned to both a cookie and a request parameter. The server then verifies that the tokens match before granting access to the application.

 

While effective, tokens can be exposed at a number of points, including in browser history, HTTP log files, network appliances logging the first line of an HTTP request and referrer headers, if the protected site links to an external URL. These potential weak spots make tokens a less than full-proof solution.

 

CsrfSecurityFilter

 

CsrfSecurityFilter checks the HTTP referer header to ensure that the request is not a cross-site request forgery attack. When a possible CSRF attack is detected, the browser returns a 400 Bad Request error and Magnolia logs a security warning to the audit log.

 

CsrfSecurityFilter causes a request to fail if:

 

• The referer header is empty

 

 

• The host part of the referer header does not match the requested host

 

 

Important Note: If you access Magnolia with a script, set the referer header in your script to ensure the script can access Magnolia. Similarly, if you embed Magnolia content into a different website, disable CsrfSecurityFilter or add a voter that bypasses the CSRF filter for any requests coming from the trusted URL.

 

Bypassing CsrfSecurityFilter

 

You can bypass the CSRF security filter via a voter. By default, CsrfSecurityFilter is bypassed if:

 

• The requested URL does not start with /.magnolia. Only Admincentral URLs are vulnerable to CSRF attacks; other URLs are not checked.
• The user is not authenticated for Admincentral access. Only authenticated requests are vulnerable to CSRF attacks.
• The request does not have query parameters.
• The requested resource is somewhere in Admincentral. Vaadin has its own CSRF protection, so Magnolia hands the responsibility over to Vaadin.

 

You can create your own whitelist of referrer domains or URIs using a voter. The filter is bypassed for the whitelisted referers. In the following example, the filter is bypassed for any requests referred by https://www.example.com.
/server/filters/csrfSecurity/

 

 

Bypassing CsrfCookieTokenFilter and CsrfSessionTokenFilter

 

You can bypass the CSRF security filter via a voter. By default, both CsrfCookieTokenFilter and CsrfSessionTokenFilter are bypassed if:

 

• In REST, the URL starts with /.rest
• In Activation, the URL starts with /.magnolia/activation
• In Vaadin heartbeat, the URL starts with /.magnolia/admincentral/HEARTBEAT
• In Vaadin, the URL starts with /.magnolia/admincentral/UIDL
• In Vaadin on Magnolia 5 Admincentral, the URL starts with /.magnolia/admincentral-m5/UIDL
• In DAM, the URL starts with /.dam
• In Imaging, the URL starts with /.imaging
• In Resources, the URL starts with /.resources
• In GraphQL, the URL starts with /.graphql

 

In addition, CsrfSessionTokenFilter is bypassed by default if:

• In Admincentral, the URL starts with /.magnolia/admincentral.

 

Conclusion:

 

CSRF attacks can be used on a huge array of sites. If a site allows data to be altered on the user side, then it is a potential target for an attacker. With some of the suggestions that I have listed, above, your website can guarantee a much higher level of security.