Secure Programming of Web Applications: Cross-Site Request Forgery (CSRF)

Added at 11/20/2020 by Frank Hissen

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.

This is an excerpt from the book "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers", also available as eBook
A corresponding online (video) training course exists: Online Course 'Web Application Security', also available on Udemy, and on request as HTML5/SCORM/Audio comment version

Description

Browsers allow the definition of HTML forms that address other destinations than the current URL or domain. This can be utilized by malicious web sites to trick users and trigger actions on other pages where they might be logged in (CSRF).

This scenario does not include actions which solely query or read data because an attacker cannot gain information this way. Affected are all actions that trigger data modifications or status changes.

Example including Security Vulnerability:

A simplified example of a CSRF attack would be a web application that enables users to perform money transfer among each other. Such a transfer shall be performed using this HTTP-GET request:

Since this request only needs the user to be logged in but does not contain additional security measures, an arbitrary web site can trigger this event/request when the user interacts with it. The attacker can perform any creative way to mislead the user to trigger the malicious request. For instance, the attacker could simply use an HTML image tag which means that the simple visit of the malicious web site triggers the event:

When calling the malicious page, the browser automatically uses the current session ID for "example.com" and the corresponding transaction is executed. "365884666885" shall be the "account number" of the attacker.
Of course, no image is displayed (the browser might show an error space) but the only goal - to trigger the event - has already happened, because it is a simple HTTP-GET request.

Secure Programming:

1)

Important transactions (especially data/status alterations) must not be executable through HTTP-GET.

2)

To secure HTTP-POST based web forms against CSRF they need to be "one time forms". The most common technique to realize this are CSRF tokens which are placed in hidden form fields (text field using attribute "hidden") and are validated on the server-side along with the form reception. Alternatively, for JavaScript or AJAX based requests corresponding parameters are defined in code or set as HTTP header to be processed in the server application.

Some programming frameworks or middlewares (e.g., Apache) offer configurable CSRF tokens. However, these might be problematic for certain custom-made application scenarios, but are worth a look.

CSRF tokens must have the following features:

• Random character string with adequate length (or Base64 encoded binary random number - like a session ID)
• Non-predictable (wrong: simple combination of username and counter)
• Has to be refreshed at least corresponding to every new user session or better: each individual form gets its own token
• Every request processing has to verify the currently valid CSRF token

In a simple way, one can think about a CSRF token as a TAN (transaction authentication number) that is bounded to the current user session at the server-side. It will be transmitted together with web forms or JavaScripts to the respective user when s/he visits the own web site. This way, only the requests can be executed successfully that originate from the own web application. Other requests are dismissed.

Similar to TANs used in online banking, their are two ways to use CSRF tokens. Using an individual new token per transaction (here: web form) which means a high degree of security. Alternatively, a single session token is used that is valid for a whole session - but invalidated as soon as the session is. Depending on the application, the desired level of security has to be found correspondingly.

A session token must not be the session ID!

Keywords

Secure Programming, Web Applications, Web Application Security, Software Developing, Project Management, Security Awareness

Categories: IT Security Background articles Development/Java

---

Comments

Post your comment

Share

If you like this page, it would be a great thing if you share it with others:

reddit Digg StumbleUpon XING
WhatsApp Telegram