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 We have a framapad where issues can be reported/found: 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 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 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>
Congrats team! El vie, 1 mar 2024 a las 10:26, Nick Clemens via Koha-devel (< koha-devel@lists.koha-community.org>) escribió:
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
We have a framapad where issues can be reported/found: 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
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 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@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/
-- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
Great work! From: Koha-devel <koha-devel-bounces@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@lists.koha-community.org>; Koha <koha@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 We have a framapad where issues can be reported/found: 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 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 [https://docs.google.com/uc?export=download&id=1eLlHaKRZxg0CP6nlW7rG0J4qdtoIuoNr&revid=0B0ga69kSs543QWlEa3V4aGI4dFlXMlVQd0ZEbVY5dFBXQUk0PQ] Follow us: [https://docs.google.com/uc?export=download&id=1UU2Vj_xX_WgcBojhYbea9ck0TaLwoLky&revid=0B0ga69kSs543R2xUajk5MnF0VE9EcjhtSjZBc1R0YVpSL0NFPQ]<https://www.facebook.com/ByWaterSolutions/> [https://docs.google.com/uc?export=download&id=1SCTJQAzf1zB5c7NmTLQwtexAgNl4_jPC&revid=0B0ga69kSs543N0tKSG9ZRk55MXk2Qmt3TXJ2TE1Ca1g4T1hFPQ] <https://www.instagram.com/bywatersolutions/> [https://docs.google.com/uc?export=download&id=1zVkZyWeLDKyDM5RhOLMRHigl4VYN5j43&revid=0B0ga69kSs543eU9ZUVVyalFqNlVodEtZTmRSNElrQlV2MlhJPQ] <https://www.youtube.com/user/bywatersolutions> [https://docs.google.com/uc?export=download&id=1b9EkTbJHwpA_Lf4iKYdoSyIlxwyasLPq&revid=0B0ga69kSs543WWFieW52VkRpZEhkdGRjcXVBejBTZUltS0hrPQ] <https://twitter.com/ByWaterSolution>
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@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@lists.koha-community.org>; Koha <koha@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@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/
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@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@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@lists.koha-community.org>; Koha <koha@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@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@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/
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@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@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@lists.koha-community.org>; Koha <koha@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@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@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/
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 workflows that are unprotected: changes something? It needs to be a POST with cus-, otherwise Koha will let you know you missed something. Hope it clarifies. El sáb, 13 abr 2024 10:18, Julian Maurice via Koha-devel < koha-devel@lists.koha-community.org> escribió:
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@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@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@lists.koha-community.org>; Koha <koha@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@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@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@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/
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 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 workflows that are unprotected: changes something? It needs to be a POST with cus-, otherwise Koha will let you know you missed something.
Hope it clarifies.
El sáb, 13 abr 2024 10:18, Julian Maurice via Koha-devel < koha-devel@lists.koha-community.org> escribió:
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@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@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@lists.koha-community.org>; Koha <koha@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@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@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@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/
participants (5)
-
Jonathan Druart -
Julian Maurice -
Marcel de Rooy -
Nick Clemens -
Tomas Cohen Arazi