Token Security in Auto-Responder Emails?

[Paul_Su2]

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 https://www.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.

[SanfordWhiteman]

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]

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 · Accepted solution]

It is difficult to defang this vulnerability, as it's perpetuated by overly "friendly" email clients. In Gmail, the http:// 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.

[SanfordWhiteman]

Paul Su​ I blogged (a lot) about this at http://blog.teknkl.com/tokens-as-hacker-weapons-1/.​

[Nicholas_Manojl]

Alternatively, could a piece of javascript listen for inputs to common form fields and reject any that contain special characters necessary to construct a URL?

[SanfordWhiteman]

No, because all JS validation can be bypassed.

[Nicholas_Manojl]

This is interesting. I guess a workflow should look like..

1. Use the Velocity method on the original double opt-in (and push all the entered data back to the email addressee) to confirm

2. Block field updates from form fillouts.

[SanfordWhiteman]

Escape using Velocity: absolutely.

Blocking updates: I'm alarmed at how many people don't do this. But if you're going to allow a hacker to set the initial value, you have to make sure you don't give that person primacy over the real human making a necessary update.

[SanfordWhiteman]

> 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.