[Koha-devel] Koha CSRF protection

Julian Maurice julian.maurice at biblibre.com
Sat Apr 13 10:17:31 CEST 2024


My point is: since all POST (and other unsafe methods) requests are 
protected and require a CSRF token, why does Koha have a requirement on 
the 'op' parameter for those requests ? It seems redundant and can cause 
unnecessary failure (I can't POST with 'op=search' even with a valid 
CSRF token, I don't understand why)

And for safe methods (GET, HEAD, OPTIONS, TRACE), if someone identifies 
that it's doing a CUD operation, why modify the 'op' parameter since you 
need to also change the method to POST anyway ?
This can be reworded as: How can we end up in a situation where 'op' has 
been fixed ("cud-" prefix added) but not the HTTP method ?

Le 2024-04-12 20:41, Jonathan Druart a écrit :
> We want to know which requests to protect (ie. Requiring a csrf token):
> those having a op starting with cud-
> Otherwise you could GET something that should be POSTed.
> I've tried to describe this change as best as I could on the wiki, 
> please
> adjust if it's not clear enough.
> https://wiki.koha-community.org/wiki/Coding_Guidelines#CSRF_protection
> 
> On Fri, 12 Apr 2024, 15:00 Julian Maurice via Koha-devel, <
> koha-devel at lists.koha-community.org> wrote:
> 
>> Hi,
>> 
>> I'm a bit late on the topic but I had a look at the different bugs and
>> patches during hackfest (mainly because it didn't work for me, I will
>> open a new bug report for that).
>> 
>> There is something in it that seems to cause bugs and I don't see a
>> reason for it: it's the "cud-" thing.
>> 
>> As I understand it, now every request that create/update/delete
>> something should be POST (or PUT/DELETE/PATCH) requests and have an 
>> 'op'
>> parameter whose value start with 'cud-' and all other requests should 
>> be
>> GET (or OPTIONS/TRACE/HEAD) requests and if they have an 'op' 
>> parameter
>> it should not start with "cud-".
>> Why do we need the "cud-" prefix if we can use the HTTP method for
>> detecting which requests need to be protected ?
>> 
>> What seems strange is that the current implementation will allow a 
>> POST
>> request without an 'op' parameter, but will block a POST request with 
>> an
>> 'op' parameter that does not start with 'cud-'.
>> It looks like we could get rid of this prefix check without losing
>> anything. What did I miss ?
>> 
>> Le 04/03/2024 à 08:37, Marcel de Rooy via Koha-devel a écrit :
>> > Great work!
>> >
>> > *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org> *On
>> > Behalf Of *Nick Clemens via Koha-devel
>> > *Sent:* Friday, March 1, 2024 2:26 PM
>> > *To:* Koha Devel <koha-devel at lists.koha-community.org>; Koha
>> > <koha at lists.katipo.co.nz>
>> > *Subject:* [Koha-devel] Koha CSRF protection
>> >
>> > Hello all!
>> >
>> > We have pushed the CSRF work from 34478 and related bugs today. We know
>> > there are more follow-ups needed, and have filed a series of bugs under
>> > an omnibus:
>> >
>> > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192
>> > <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192>
>> >
>> > We have a framapad where issues can be reported/found:
>> >
>> > https://annuel.framapad.org/p/koha_34478_remaining
>> > <https://annuel.framapad.org/p/koha_34478_remaining>
>> >
>> > And we have bugs for each of the sections of the document. We need all
>> > developers to submit patches when they encounter issues, and for other
>> > users testing master to report found issues on the pad. Testers can
>> > report issues on the pad as well.
>> >
>> > There is a new coding guideline - all POSTs to forms in Koha will need
>> > to include a csrf token:
>> >
>> > https://wiki.koha-community.org/wiki/Coding_Guidelines#Security
>> > <https://wiki.koha-community.org/wiki/Coding_Guidelines#Security>
>> >
>> > This has been a big work, many thanks to all involved, and there is
>> > still work to be done, but this is an important fix that we must do.
>> >
>> > You can reach out to me on IRC (kidclamp) or via email and I will do my
>> > best to help anyone contribute.
>> >
>> > Thanks,
>> >
>> > Nick
>> >
>> >
>> > --
>> >
>> > Nick Clemens
>> >
>> > ByWater Solutions
>> >
>> > bywatersolutions.com <http://bywatersolutions.com/>
>> >
>> > Phone: (888) 900-8944
>> >
>> > Pronouns: (he/him/his)
>> > Timezone: Eastern
>> >
>> > Follow us:
>> >
>> > <https://www.facebook.com/ByWaterSolutions/>
>> > <https://www.instagram.com/bywatersolutions/>
>> > <https://www.youtube.com/user/bywatersolutions>
>> > <https://twitter.com/ByWaterSolution>
>> >
>> >
>> > _______________________________________________
>> > Koha-devel mailing list
>> > Koha-devel at lists.koha-community.org
>> > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> > website : https://www.koha-community.org/
>> > git : https://git.koha-community.org/
>> > bugs : https://bugs.koha-community.org/
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : https://www.koha-community.org/
>> git : https://git.koha-community.org/
>> bugs : https://bugs.koha-community.org/
>> 


More information about the Koha-devel mailing list