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.
Solved! Go to 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.
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.
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?
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.
Paul Su I blogged (a lot) about this at http://blog.teknkl.com/tokens-as-hacker-weapons-1/.
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?
No, because all JS validation can be bypassed.
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.
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.
> 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.