Bug 37040 - ErrorDocument accidentally setting off CSRF
Summary: ErrorDocument accidentally setting off CSRF
Status: Pushed to main
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: David Cook
QA Contact: Matt Blenkinsop
URL:
Keywords:
: 37064 (view as bug list)
Depends on:
Blocks: 34478
  Show dependency treegraph
 
Reported: 2024-06-06 00:53 UTC by David Cook
Modified: 2024-06-13 17:10 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.11.00


Attachments
Bug 37040: Prevent ErrorDocument subrequests from activating CSRF (2.37 KB, patch)
2024-06-06 01:38 UTC, David Cook
Details | Diff | Splinter Review
Bug 37040: Prevent ErrorDocument subrequests from activating CSRF (2.41 KB, patch)
2024-06-06 22:12 UTC, David Nind
Details | Diff | Splinter Review
Bug 37040: Prevent ErrorDocument subrequests from activating CSRF (2.49 KB, patch)
2024-06-07 12:34 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 37040: (QA follow-up) Tidy file (961 bytes, patch)
2024-06-07 12:34 UTC, Matt Blenkinsop
Details | Diff | Splinter Review
Bug 37040: (RMaint follow-up) Restore passing CSRF error (1.05 KB, patch)
2024-06-11 10:37 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2024-06-06 00:53:27 UTC
As Michal Kula noted on Mattermost, trying to log into http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=9908 in main will yield a bizarre HTTP response that includes headers for a 403 response and a 200 response...

This is due to a bug in addbiblio.pl, but it's also causing the CSRF to fire for the ErrorDocument, so we need to fix that. I have an idea for it...
Comment 1 David Cook 2024-06-06 01:38:03 UTC
Created attachment 167521 [details] [review]
Bug 37040: Prevent ErrorDocument subrequests from activating CSRF

This change improves the mechanism for preventing the CSRF middleware
being activated by ErrorDocument subrequests.

This change was necessary due to a subtle issue identified by
Bug 37041.

Test plan:
0. Apply the patch
1. Restart Koha
koha-plack --restart kohadev
2. Go to http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=9908
3. Log in
4. Note that you get a pretty 403 and not an ugly plain text error
5. Go to http://localhost:8081
6. Fill in the login details, but use the HTML inspector to delete
the csrf_token from the hidden inputs
7. Submit the login
8. Note a pretty 403 page
Comment 2 David Nind 2024-06-06 22:12:31 UTC
Created attachment 167560 [details] [review]
Bug 37040: Prevent ErrorDocument subrequests from activating CSRF

This change improves the mechanism for preventing the CSRF middleware
being activated by ErrorDocument subrequests.

This change was necessary due to a subtle issue identified by
Bug 37041.

Test plan:
0. Apply the patch
1. Restart Koha
koha-plack --restart kohadev
2. Go to http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=9908
3. Log in
4. Note that you get a pretty 403 and not an ugly plain text error
5. Go to http://localhost:8081
6. Fill in the login details, but use the HTML inspector to delete
the csrf_token from the hidden inputs
7. Submit the login
8. Note a pretty 403 page

Signed-off-by: David Nind <david@davidnind.com>
Comment 3 Matt Blenkinsop 2024-06-07 12:34:52 UTC
Created attachment 167571 [details] [review]
Bug 37040: Prevent ErrorDocument subrequests from activating CSRF

This change improves the mechanism for preventing the CSRF middleware
being activated by ErrorDocument subrequests.

This change was necessary due to a subtle issue identified by
Bug 37041.

Test plan:
0. Apply the patch
1. Restart Koha
koha-plack --restart kohadev
2. Go to http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=9908
3. Log in
4. Note that you get a pretty 403 and not an ugly plain text error
5. Go to http://localhost:8081
6. Fill in the login details, but use the HTML inspector to delete
the csrf_token from the hidden inputs
7. Submit the login
8. Note a pretty 403 page

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Comment 4 Matt Blenkinsop 2024-06-07 12:34:54 UTC
Created attachment 167572 [details] [review]
Bug 37040: (QA follow-up) Tidy file

QA tests were failing for tidyness so this patch addresses that

Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Comment 5 Martin Renvoize 2024-06-10 11:04:12 UTC
Thanks for all the hard work!

Pushed to main for the next 24.11.00 release as RM Assistant
Comment 6 Martin Renvoize 2024-06-10 16:33:34 UTC
I think this one causes the current failure in Jenkins regards cypress tests: https://jenkins.koha-community.org/job/Koha_Main/lastCompletedBuild/testReport/
Comment 7 David Cook 2024-06-11 01:17:24 UTC
(In reply to Martin Renvoize from comment #6)
> I think this one causes the current failure in Jenkins regards cypress
> tests:
> https://jenkins.koha-community.org/job/Koha_Main/lastCompletedBuild/
> testReport/

Ah nuts.

We should've grepped for "plack.middleware.Koha.CSRF" in the code. I can see it in ./errors/403.pl and ./opac/errors/403.pl

Should be an easy fix...
Comment 8 Martin Renvoize 2024-06-11 10:37:31 UTC
Created attachment 167620 [details] [review]
Bug 37040: (RMaint follow-up) Restore passing CSRF error

This patch restores the plack.middleware.Koha.CSRF plack env setting to
allow passing to the errorDocument.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 9 David Cook 2024-06-11 23:37:37 UTC
Thanks, Martin. I meant to do that yesterday, but ran out of time.
Comment 10 Nick Clemens (kidclamp) 2024-06-13 17:10:54 UTC
*** Bug 37064 has been marked as a duplicate of this bug. ***