FYI: CSRF Problem

We got the following from our security guide who was checking our app:

Weakness in Cross-Site Request Forgery (CSRF) Protection
Risk Level - MODERATE Severity

While the MEBN application implemented a CSRF token - "csrf_test_name" POST parameter, it was not implemented properly, and as a result the application was not properly protected from CSRF attacks.

Weakness identified with the CSRF token:

The application did not verify server-side whether the value submitted as the CSRF token was a valid value generated by the application for that specific active session. In fact, the value could be left blank and the application allowed the request to execute.

CSRF is possible when the application is unable to identify whether a request originated in the same session that it was being executed in or not.

A malicious user may create a request and through social engineering trick an unsuspecting user into executing this request in his or her active session. These are usually state-changing (insert, update, delete) requests, such as changing email address, changing password.

For example, it was possible to create a POST request to update a MEBN user's password, which if an unsuspecting user was tricked into executing would change that user's password to a value set by the malicious user.

However, the scope of a CSRF attack was limited in this instance due to an attribute configured on the application's session identifier. The ci_session cookie was configured with the "SameSite=Lax" attribute, which prevents the cookie being sent automatically in any POST requests that did not originate from the same site.
Most modern browsers appeared to support this cookie attribute, limiting a successful CSRF attack to a minority of older browser versions and lesser used browsers. For example, Internet Explorer 11 appeared to not support this attribute and allowed a CSRF request to include the session identifier, and the attack succeeded. IE 11 will be retired and go out of support in June 2022.

This reduced the risk level.
REMEDIATION:
Implement security best practices to protect against application weaknesses.
The CSRF token should have the following properties:
be a large unguessable value generated by a secure random generator
be validated server-side by the application in each request it was submitted
be present in (at least) all state-changing requests
be valid for the duration of a single active session. When the session expires, the token should expire
be valid only for the active session it was initially associated with. A token associated with user A's session should not work in user B's session.

Please refer to the OWASP Cheatsheet for guidance:
https://cheatsheetseries.owasp.org/cheat...Sheet.html


Apparently it is just a problem with IE 11. So it is probably not worth fixing.

Simpler is always better

i've had some false +ve's with zap from owasp

CMS CI4     I use Arch Linux by the way 

Thanks for sharing.

Since v4.1.5, CI4 has Session based CSRF Protection.
https://codeigniter.com/user_guide/libra...on-methods

If you could, change your app config and confirm the security guide.

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper