Security problems with Preferences Center

[Anonymous]

Hi guys,

Recently we implemented the preferences center, where you can enter and subscribe, edit your settings or unsubscribe. The problem here is that you can put any email for this without any validation, plus the use of cookies, if you fill a form (unsubscribe one) with other person email and go to the edit settings, it will recognize that email as yours and will bring your peresonal data.

So one step that I see here is to hide those options so you can only enter by link form email, plus this link will pre-populate the email in the edit setting form.

How do you guys manage your Preferences Center to avoid this kind of issues?

Regards,

Raúl

Message was edited by: Raul Ocaña

[Grégoire_Miche2 · Accepted solution]

Welcome to the club ...

I have been keeping saying this to my customers for months and no one is listening

The way we handle it is making sure that the preference center can only be accessed from an email link. It's not 100% perfect because of the forwards (in which case it's your lead's problem, though), but it's a first level. The way we do this is with some JS that controls that there isa mkt_tok in the inbound URL and that it's not fake (it generates an email). If this is not the case, the page redirects with a simple, cookie-less identification LP with a form where one can enter his email are receive a new link to the preference center.

The second level of security is to make the email field read-only in the preference center. There are some additional buttons to access the identification LP. There is also another button to access a "change email" LP that is also controlled with a series of emails.

And the third level is to have the preferences validated with a last email.

-Greg

[Anonymous]

Hi Greg,

In your solution what will happen if a user submits the form that has the email only, but opens it from another PC? This new location won't have the cookies because it didn't do any form submit, so once the Preferences page loads (with email field as read-only), will it set the email address or it won't recognize it?

Regards,

Raúl

[Grégoire_Miche2]

Hi Raul,

In my solution, whether the cookie exists or not does not matter. Only the mkt_Tok from the email matters. If the person accesses the page without coming from an email, he will be redirected to the identification page.

-Greg

[SanfordWhiteman]

Raul, like Greg says, this is how Marketo Forms always work (whether labeled as "Preference Center" or regular forms). Since leads do not have a password, there is no way to authenticate them other than via email.

Removing the Email field -- so a mkt_tok-enized link is seemingly required for Pre-Fill -- merely obscures the functionality. It doesn't actually disable it, as you can still add a hidden Email field to the form post if you're malicious, and nothing can fully protect against that vector.  (If you remove Email completely, also consider the legal angle: if you don't allow someone to enter another email address, then you're effectively stopping people from unsubscribing if they don't have an email on hand, which may not be legal -- talk your counsel on this.)

Unfortunately, there are multiple interests that are in conflict here.

• On one hand, you want to allow people to manage their preferences from anywhere, regardless of whether they just received an email or not and regardless of whether they know a special self-management password. When used non-maliciously, this affords them the expected control over their marketing settings and is better for the relationship.
• On another hand, you want to prevent the system from being abused by malicious actors. So you may wish to generate a new outbound email before letting somebody update their preferences. However, this [a] doesn't stop malicious actors from doing their thing and [b] increases friction, so may cause legit actors to accuse you of purposely making opt-out more difficult.
• On yet another hand, there's the temptation to distribute passcodes via email and then validate them via an API-based process, not via standard forms. But, as above, this [a] doesn't disable forms from being used, [b] opens you up to a denial of service that may be worse than the original disease, and [c] is additional friction, though at least if they keep the passcode on hand they won't have to wait for an email.

[Grégoire_Miche2]

[b] increases friction, so may cause legit actors to accuse you of purposely making opt-out more difficult.

I am eager to see the first lawsuit that will have to arbitrate between security and friction, if even the court can understand anything to all this

-Greg

[Anonymous]

Hi Greg,

How are you injecting Javascript to the form? I would like to prevent the access using JS and allowing only from email's link.

Thank you!

[Grégoire_Miche2]

There are various ways, but all of the will require at least some modification to the LP template.

Are you familiar with form 2.0 API ?

read this: Best way to add a script in a guided landing page

-Greg

[Anonymous]

Hi Greg,

Thank you, I have checked that link and I have set up a LP Template to read URL params, that is the easy part.

But how do you create the link in the email with the params? I mean, do you encrypt it or somehting or it is just the mkt_tok variable with some random value in the URL?

Regards,

Raúl

[Grégoire_Miche2]

Marketo will automatically add the Mkt_tok parameter as soon as you make the linjk traceable in the email. It does not need more. From the mkt_tok, Marketo will be able to identifiy the person and retrieve the data from the database without any cookie.

-Greg