Bug 35445 - OPAC registration verification triggered by email URL scanners
Summary: OPAC registration verification triggered by email URL scanners
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor
Assignee: David Cook
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks: 35992
  Show dependency treegraph
 
Reported: 2023-11-30 00:36 UTC by David Cook
Modified: 2024-12-05 15:52 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.05.00,23.11.03
Circulation function:


Attachments
Bug 35445: Require OPAC user to confirm self-registration with button push (6.26 KB, patch)
2023-12-04 05:36 UTC, David Cook
Details | Diff | Splinter Review
Bug 35445: Require OPAC user to confirm self-registration with button push (6.33 KB, patch)
2023-12-04 12:04 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 35445: Require OPAC user to confirm self-registration with button push (6.42 KB, patch)
2024-01-26 07:27 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2023-11-30 00:36:02 UTC
I've noticed that Microsoft Safe Links is triggering /cgi-bin/koha/opac-registration-verify.pl?token=X links.

This means that the end user ends up seeing "Registration invalid" because the Microsoft link scanner has already verified the registration by hitting the page with a GET. 

We should update opac-registration-verify.pl so that it requires the user to click a button for a POST form confirming their registration.

(NOTE: Since opac-registration-verify.pl performs a state change, it should be a POST anyway.)
Comment 1 David Cook 2023-11-30 00:38:10 UTC
Basically, /cgi-bin/koha/opac-registration-verify.pl?token=X will take us to a HTML form where the token is a hidden form field, and we'll have another input to indicate that we're confirming the registration.
Comment 2 David Cook 2023-12-04 05:36:15 UTC
Created attachment 159516 [details] [review]
Bug 35445: Require OPAC user to confirm self-registration with button push

This change requires the OPAC user to confirm self-registration with
a button push when verifying registration using an emailed token.

Test plan:
0. Apply the patch and koha-plack --reload kohadev
1. Set syspref PatronSelfRegistrationVerifyByEmail to "Don't require"
2. Create a patron using the self-registration on the OPAC
3. Note that no confirmation step is needed when self-registering
4. Set syspref PatronSelfRegistrationVerifyByEmail to "Require"
5. Create a patron using the self-registration on the OPAC
6. Look in message_queue to find the URL with the token to
visit in the browser
7. Visit that URL
8. Note that the page says "Registration pending" and asks you to
click a button labeled "Confirm"
9. Click the button labeled "Confirm"
10. Note that the self-registration is confirmed and details are
shown on the page
Comment 3 Martin Renvoize (ashimema) 2023-12-04 12:04:57 UTC
Created attachment 159520 [details] [review]
Bug 35445: Require OPAC user to confirm self-registration with button push

This change requires the OPAC user to confirm self-registration with
a button push when verifying registration using an emailed token.

Test plan:
0. Apply the patch and koha-plack --reload kohadev
1. Set syspref PatronSelfRegistrationVerifyByEmail to "Don't require"
2. Create a patron using the self-registration on the OPAC
3. Note that no confirmation step is needed when self-registering
4. Set syspref PatronSelfRegistrationVerifyByEmail to "Require"
5. Create a patron using the self-registration on the OPAC
6. Look in message_queue to find the URL with the token to
visit in the browser
7. Visit that URL
8. Note that the page says "Registration pending" and asks you to
click a button labeled "Confirm"
9. Click the button labeled "Confirm"
10. Note that the self-registration is confirmed and details are
shown on the page

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 4 Martin Renvoize (ashimema) 2023-12-04 12:07:24 UTC
All working as expected here, signing off.
Comment 5 Victor Grousset/tuxayo 2023-12-09 17:50:13 UTC
(In reply to David Cook from comment #0)
> I've noticed that Microsoft Safe Links is triggering
> /cgi-bin/koha/opac-registration-verify.pl?token=X links.
> 
> This means that the end user ends up seeing "Registration invalid" because
> the Microsoft link scanner has already verified the registration by hitting
> the page with a GET. 

Isn't that a security issue? It's possible to create an account for someone else and their email will be verified automatically. I don't know much of what's around self-registration, what are the bad things that can happen due to email hosts autoclicking verification links?
Comment 6 David Cook 2023-12-10 22:32:00 UTC
(In reply to Victor Grousset/tuxayo from comment #5)
> (In reply to David Cook from comment #0)
> > I've noticed that Microsoft Safe Links is triggering
> > /cgi-bin/koha/opac-registration-verify.pl?token=X links.
> > 
> > This means that the end user ends up seeing "Registration invalid" because
> > the Microsoft link scanner has already verified the registration by hitting
> > the page with a GET. 
> 
> Isn't that a security issue? It's possible to create an account for someone
> else and their email will be verified automatically. I don't know much of
> what's around self-registration, what are the bad things that can happen due
> to email hosts autoclicking verification links?

I think that you could argue it's a security issue conceptually in terms of the state change being a GET rather than a POST, but no it wouldn't work the way you're describing here. 

Koha sends the email with the URL to the user's mail server. That mail server rewrites the URL to point to Microsoft Safe Links or Web CISCO or whatever. Then when the user clicks the link in the email, Microsoft Safe Links or WEB CISCO or whatever visits it first, verifies that it's OK, and then redirects the user to the original link.

So it still requires the user to click the link in their email. If someone self-registered as someone else, that someone else would still need to get the link and click it. It works the exact same way without the Microsoft Safe Links as well.
Comment 7 Victor Grousset/tuxayo 2023-12-15 20:51:43 UTC
> That mail server rewrites the URL to point to Microsoft Safe Links or Web CISCO or whatever. Then when the user clicks the link in the email, Microsoft Safe Links or WEB CISCO or whatever visits it first, verifies that it's OK, and then redirects the user to the original link.

Great, nothing to worry about then :D Since these tools don't click on the link on their own in advance.
Comment 8 Marcel de Rooy 2024-01-26 07:27:28 UTC
Created attachment 161476 [details] [review]
Bug 35445: Require OPAC user to confirm self-registration with button push

This change requires the OPAC user to confirm self-registration with
a button push when verifying registration using an emailed token.

Test plan:
0. Apply the patch and koha-plack --reload kohadev
1. Set syspref PatronSelfRegistrationVerifyByEmail to "Don't require"
2. Create a patron using the self-registration on the OPAC
3. Note that no confirmation step is needed when self-registering
4. Set syspref PatronSelfRegistrationVerifyByEmail to "Require"
5. Create a patron using the self-registration on the OPAC
6. Look in message_queue to find the URL with the token to
visit in the browser
7. Visit that URL
8. Note that the page says "Registration pending" and asks you to
click a button labeled "Confirm"
9. Click the button labeled "Confirm"
10. Note that the self-registration is confirmed and details are
shown on the page

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 9 Katrin Fischer 2024-01-29 11:28:43 UTC
Pushed for 24.05!

Well done everyone, thank you!
Comment 10 David Cook 2024-01-29 22:43:50 UTC
Yay! I'd love to see this one in 23.11 as well :)
Comment 11 Jonathan Druart 2024-01-30 12:17:29 UTC
Should not we adjust opac-shareshelf.pl as well?
Comment 12 David Cook 2024-01-30 22:12:39 UTC
(In reply to Jonathan Druart from comment #11)
> Should not we adjust opac-shareshelf.pl as well?

I'm not familiar with that one, but if it works similarly then I'd say you're right.
Comment 13 Marcel de Rooy 2024-02-01 07:23:38 UTC
(In reply to Jonathan Druart from comment #11)
> Should not we adjust opac-shareshelf.pl as well?

Will have a look at that marvelous script :)
Comment 14 Fridolin Somers 2024-02-01 14:56:38 UTC
Pushed to 23.11.x for 23.11.03
Comment 15 Marcel de Rooy 2024-02-05 10:51:53 UTC
(In reply to Marcel de Rooy from comment #13)
> (In reply to Jonathan Druart from comment #11)
> > Should not we adjust opac-shareshelf.pl as well?
> 
> Will have a look at that marvelous script :)

Opened a new bug 35992, but will wait first for changes from 34478.
Comment 16 Marcel de Rooy 2024-10-10 13:56:33 UTC
(In reply to Marcel de Rooy from comment #15)
> (In reply to Marcel de Rooy from comment #13)
> > (In reply to Jonathan Druart from comment #11)
> > > Should not we adjust opac-shareshelf.pl as well?
> > 
> > Will have a look at that marvelous script :)
> 
> Opened a new bug 35992, but will wait first for changes from 34478.

Ah. Should revive that.