Ohhh I forgot that .pl scripts almost never check for the HTTP method...
That's the thing I was missing. Thanks!
Le 2024-04-13 10:24, Tomas Cohen Arazi a écrit :
The thing is we don't have a spec for each endpoint as we do for the
API.
So people could be tricked to send a GET with a similar
Hi
I'm collecting news for the April 2024 Koha Community Newsletter.
Please send anything noteworthy to:
kohanews (at) gmail (dot) com
News criteria:
* News items can be of any length.
* Images are fine.
* Anything and everything Koha.
* Submit by the 26th of the month.
Text format criteria:
*
The thing is we don't have a spec for each endpoint as we do for the API.
So people could be tricked to send a GET with a similar form, to an
endpoint (the .pl script) and bypass the generic CSRF check we do.
Also, this ways programmers and the QA team have a simpler way to detect
state-changing
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,
