Token Security in Auto-Responder Emails? | Community
Skip to main content
Paul_Su2
Paul_Su2
New Participant
December 6, 2016
Solved

Token Security in Auto-Responder Emails?

  • December 6, 2016
  • 2 replies
  • 4969 views

For webinar programs, I have auto-responder confirmation emails that tokenize the lead first name after someone registers. I was forwarded the below description of how this could potentially be exploited to send out malicious/phishing links to other people. Has anyone encountered this issue coming up? How did you deal with an issue like this?

=====================================================================================

Bug Type : Hyperlink Injection

Description:

A user can change their name to a URL in order to send email invitations containing malicious hyperlinks.

Steps to Reproduce:

Request for a new account with the first name google.com

You will receive the auto-responder confirmation email where you can see the injected url ..

You will receive a new email with the first word being a link to a potentially malicious site.

Consequences

This permits users to send malicious/phishing links to potential clients. It could also have an effect on how spam filters treat your emails.

Best answer by SanfordWhiteman

It is difficult to defang this vulnerability, as it's perpetuated by overly "friendly" email clients. In Gmail, the isn't even necessary for the vulnerability to raise its head -- a bare domain-like string "www.example.com" will become a hyperlink.

You can run tokens through a sanitization step that converts domain-like strings to a special format that looks the same, but will never be clickable. This could be done at send time using a Velocity script, or via a webhook that permanently changes the stored value of any token that might be embedded in an email (which could, of course, be any token at all!). I'll write a blog post about the Velocity method in coming days.

2 replies

SanfordWhiteman
SanfordWhiteman
New Participant
December 6, 2016

> It could also have an effect on how spam filters treat your emails.

And yes to this: if your form is used to reflect spam links to innocent recipients then that means you're going to endanger the reputation of your domain + Marketo instance + fellow Marketo customers.

On the other hand, a malicious person doesn't to "slam" the First Name field for this. Any reflected field will do, like -- for example -- a field that is specifically designed to store the customer's website. If that is reflected as-is in an email, particularly in a text-only email, that's a link by definition.

SanfordWhiteman
SanfordWhiteman
New Participant
December 6, 2016

Well, the security vulnerability is real.  Bottom line, all tokens that originate as unsanitized user input should be HTML-encoded when output, because  email clients have an unfortunate eagerness to make URL-like text into clickable URLs.

Paul_Su2
Paul_Su2Author
New Participant
December 6, 2016

Thanks for the reply Sanford. So basically there's really no fully safe way around this issue outside of not using the token in the email?

SanfordWhiteman
SanfordWhitemanAccepted solution
New Participant
December 6, 2016

It is difficult to defang this vulnerability, as it's perpetuated by overly "friendly" email clients. In Gmail, the isn't even necessary for the vulnerability to raise its head -- a bare domain-like string "www.example.com" will become a hyperlink.

You can run tokens through a sanitization step that converts domain-like strings to a special format that looks the same, but will never be clickable. This could be done at send time using a Velocity script, or via a webhook that permanently changes the stored value of any token that might be embedded in an email (which could, of course, be any token at all!). I'll write a blog post about the Velocity method in coming days.

Terms & ConditionsAccessibility statement

Loading footer...