OWASP / CheatSheetSeries

The OWASP Cheat Sheet Series was created to provide a concise collection of high value information on specific application security topics.
https://cheatsheetseries.owasp.org
Creative Commons Attribution Share Alike 4.0 International
27.1k stars 3.8k forks source link

Update: CSRF - Form tag clarification #1322

Closed birch-jayton closed 4 months ago

birch-jayton commented 4 months ago

What is missing or needs to be updated?

tl;dr: a small but important distinction must be made between the existence of the <form> tag and the use of the <form> for data submittal. Without this distinction, a web-dev may conclude that they cannot add custom headers to their AJAX requests when they can.

Background

Submission of data via a <form> tag using the action attribute is what causes simple requests to be sent, not the existence of <form> tags themselves. Even when javascript is used to submit form data, it is an industry standard practice to use <form> tags for accessibility reasons. The <form> tags in these cases will not have an action attribute and the event default will be prevented via javascript. This strategy is not an exception to the general rule but rather is becoming an industry-standard practice. This is evidenced by the widespread use of popular form submittal tools (react-hook-form, formik, etc.) that embrace this philosophy and the prevalence of JSON based REST APIs.

Why the current wording can be confusing:

Due to how the Employing Custom Request Header for AJAX/API section is worded, a web developer who uses <form> tags but submits data via javascript may read this section and conclude that they cannot implement custom headers and must use CSRF tokens. In reality, they certainly can implement custom headers because they are using javascript to make the request. This is an important distinction because the custom header approach is likely the cheaper and better solution compared to CSRF tokens. This very cheatsheet says that the CSRF token approach "can be tricky to implement and degrade usability". The cheatsheet should help the reader determine the best solution for their case in the clearest way. I believe re-wording a few sentences can better achieve that.

How should this be resolved?

A distinction should be made between the existence of <form> tags and default form submission. This happens a few times in the cheatsheet. One example:

If you use <form> tags anywhere in your client, you will still need to protect them with alternate approaches described in this document such as tokens.

Might be changed to something like (change underlined):

If you use <form> tags to submit data anywhere in your client, you will still need to protect them with alternate approaches described in this document such as tokens.

Or maybe:

If you use <form> tags to submit data via the default form action anywhere in your client, you will still need to protect them with alternate approaches described in this document such as tokens.

This proposed change is subtle but a web-dev who is unfamiliar with CSRF and security in general may be mislead by the current phrasing

I'd be happy to submit a PR. Thanks!

mackowski commented 4 months ago

@birch-jayton good point! Please create PR for this, it can be part of #1329 :-)