4 ms·

My work actually visits the url ahead of time. This sucks when the link is a one-time-use only code.

cimnine 5y ago
Sounds like a great target for Server Side Request Forgery, https://owasp.org/www-community/attacks/Server_Side_Request_Forgery https://owasp.org/www-community/attacks/Server_Side_Request_.... Could be fun to try if that software also visits links for internal-only applications, should such exist in your corp.
smcl 5y ago
This is pretty common and something that bit us last year - enterprise Outlook 365 (or some extension? idk it was def only O365 though) added some security features that would make a HEAD request to any links contained in an email. This messed up our (admittedly antiquated) process for activating users and resetting passwords as it consumed the one-time code our systems generated for them, as you mentioned. Because the app that handled this was old and in the process of replacement we didn't want to invest too much time in rewriting it all, so a quick and easy fix was to have a handler specifically for HEAD requests to those activation and reset resources. The link protection started issuing GET requests a little while after, so we ended up having to add an extra confirmation step so the user had to click something after the link was followed. To be honest the original process we had maybe wasn't 100% perfect - users can double click links for example, and would see a message that the link had "expired". So from a UX perspective we maybe should've had the extra confirmation step before activation/reset to begin with. But I'm in two minds over email providers following all the links in your emails, it feels a bit creepy
- gmueckl 5y ago
  Wow, this behavior seems perfect for sneakily verifying that an email was received. And the user can't do anything against it. It's not a perfect replacement for tracking pixels, though, if you want to figure out whether an email was opened. Creepy.
  - dewey 5y ago
    > Wow, this behavior seems perfect for sneakily verifying that an email was received. Isn't that pretty much the definition of "confirming your email address" transactional emails? Wouldn't really call this "sneaky".
    - dpwm 5y ago
      I read it as anyone – including spammers – who puts link in will get a head request to it from the email provider, thus providing information – even if just that the address is real. However, the absence of a bounce probably also does that, albeit less reliably.
      - gmueckl 5y ago
        Some email providers don't bounce/reject specifically to not leak that information as far as I know.
  - smcl 5y ago
    I don’t think it would be that useful to be honest. I don’t think it happens when the email is opened by the end user, but some point during the delivery process. And even then you’d only find out from some email providers - not everyone does it
- deleted 5y ago
  [deleted]
franga2000 5y ago
Does anyone actually send links like that? Any competent programmer will make the link expire on an interaction, not on load - there are some many things that could cause a link to receive a GET request, but where the use wouldn't actually be able to interact with the page.
- fomine3 5y ago
  Using GET for non-idempotent generally considered bad, but it seems that email is a place that non-idempotent GET is still used. I often see it on unsubscribe link.
  - franga2000 5y ago
    Yeah, fair enough, I do run into those occasionally too, but most of them these days make sure to require at least a confirmation click.
  - DaiPlusPlus 5y ago
    > I often see it on unsubscribe link. Those are meant to load a page with a confirmation form that makes a POST request. The GET link can still expire over time, but must never be expired from a GET request: you never know when a link preview bot is going to follow links.

Sounds like a great target for Server Side Request Forgery, https://owasp.org/www-community/attacks/Server_Side_Request_Forgery https://owasp.org/www-community/attacks/Server_Side_Request_.... Could be fun to try if that software also visits links for internal-only applications, should such exist in your corp.

smcl 5y ago

This is pretty common and something that bit us last year - enterprise Outlook 365 (or some extension? idk it was def only O365 though) added some security features that would make a HEAD request to any links contained in an email. This messed up our (admittedly antiquated) process for activating users and resetting passwords as it consumed the one-time code our systems generated for them, as you mentioned. Because the app that handled this was old and in the process of replacement we didn't want to invest too much time in rewriting it all, so a quick and easy fix was to have a handler specifically for HEAD requests to those activation and reset resources. The link protection started issuing GET requests a little while after, so we ended up having to add an extra confirmation step so the user had to click something after the link was followed. To be honest the original process we had maybe wasn't 100% perfect - users can double click links for example, and would see a message that the link had "expired". So from a UX perspective we maybe should've had the extra confirmation step before activation/reset to begin with. But I'm in two minds over email providers following all the links in your emails, it feels a bit creepy

gmueckl 5y ago
Wow, this behavior seems perfect for sneakily verifying that an email was received. And the user can't do anything against it. It's not a perfect replacement for tracking pixels, though, if you want to figure out whether an email was opened. Creepy.
- dewey 5y ago
  > Wow, this behavior seems perfect for sneakily verifying that an email was received. Isn't that pretty much the definition of "confirming your email address" transactional emails? Wouldn't really call this "sneaky".
  - dpwm 5y ago
    I read it as anyone – including spammers – who puts link in will get a head request to it from the email provider, thus providing information – even if just that the address is real. However, the absence of a bounce probably also does that, albeit less reliably.
    - gmueckl 5y ago
      Some email providers don't bounce/reject specifically to not leak that information as far as I know.
- smcl 5y ago
  I don’t think it would be that useful to be honest. I don’t think it happens when the email is opened by the end user, but some point during the delivery process. And even then you’d only find out from some email providers - not everyone does it
deleted 5y ago
[deleted]

franga2000 5y ago

Does anyone actually send links like that? Any competent programmer will make the link expire on an interaction, not on load - there are some many things that could cause a link to receive a GET request, but where the use wouldn't actually be able to interact with the page.

fomine3 5y ago
Using GET for non-idempotent generally considered bad, but it seems that email is a place that non-idempotent GET is still used. I often see it on unsubscribe link.
- franga2000 5y ago
  Yeah, fair enough, I do run into those occasionally too, but most of them these days make sure to require at least a confirmation click.
- DaiPlusPlus 5y ago
  > I often see it on unsubscribe link. Those are meant to load a page with a confirmation form that makes a POST request. The GET link can still expire over time, but must never be expired from a GET request: you never know when a link preview bot is going to follow links.