26 Replies Latest reply on Jun 1, 2018 1:12 PM by Sanford Whiteman

    Security problems with Preferences Center

    Raul Ocaña

      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

        • Re: Security problems with Preferences Center
          Grégoire Michel

          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

          4 of 4 people found this helpful
          • Re: Security problems with Preferences Center
            Sanford Whiteman

            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.
            3 of 3 people found this helpful
            • Re: Security problems with Preferences Center
              Raul Ocaña

              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!

                • Re: Security problems with Preferences Center
                  Grégoire Michel

                  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

                  1 of 1 people found this helpful
                    • Re: Security problems with Preferences Center
                      Raul Ocaña

                      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

                        • Re: Security problems with Preferences Center
                          Grégoire Michel

                          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

                          1 of 1 people found this helpful
                            • Re: Security problems with Preferences Center
                              Raul Ocaña

                              Hi Greg,

                               

                              I didn't know about that link option. So in the JS validation for the mkt_tok, how do you check that is not fake, I mean I can check for the mkt_tok param and its value, but how do you tell that is a valid token instead of random characters?

                               

                              Thank you!

                                • Re: Security problems with Preferences Center
                                  Sanford Whiteman

                                  You can't.

                                   

                                  The only thing that distinguishes a legit mkt_tok-enized link from a fake mkt_tok-enized link is whether, in the absence of an associated cookie, the link succeeds in pre-filling fields.

                                  2 of 2 people found this helpful
                                    • Re: Security problems with Preferences Center
                                      Raul Ocaña

                                      Hi Sanford,

                                       

                                      Oh I got it, so adding the read-only email field will complete the secure filter to the page!

                                       

                                      Thank you!

                                      • Re: Security problems with Preferences Center
                                        Grégoire Michel

                                        +1 on this, and this how we secure Preference centers:

                                        • We remove the cookie on page entry on the PC page, before the munchkin is ran. No data can be extracted from the database if the Mkt_tok is not present
                                        • If no Mkt_tok is present in the URL, we redirect to an identification page on page entry. That identification page is a no traced page with a form on which the only field is the email address. The visitor enters his email address and receives an email with a link to the PC page (with an Mkt_tok in it).
                                        • After the page is entered and the form is loaded, we check whether an email address has been retrieved from the Mkt_tok. If not, we redirect to the identification page
                                        • and we look the email field so that the person cannot change the email address (although a hacked could easily override this one)

                                         

                                        In fact, we rely on how Marketo has encrypted the Mtk_tok to identify the person.

                                         

                                        It does not cover the case of email forwarding, though. we have not found a way to cover this case. Hoping people will not forward emails to people they do not know (This is wishful thinking, obviously but it should not happen so often).

                                         

                                        -Greg

                                        2 of 2 people found this helpful
                                          • Re: Security problems with Preferences Center
                                            Sanford Whiteman
                                            • We remove the cookie on page entry on the PC page, before the munchkin is ran. No data can be extracted from the database if the Mkt_tok is not present

                                            That's not exactly so. You have to remove the cookie and refresh the page without the cookie in order for the database record to not be loaded. The cookie has already been transmitted to Marketo during the HTTP request, and the Pre-Fill block injected into the HTML, by the time the page is drawn into the browser.  Deleting the cookie at that point after the page is drawn doesn't make the Pre-Fill info go away.

                                            2 of 2 people found this helpful
                                            • Re: Security problems with Preferences Center
                                              Raul Ocaña

                                              Thanks guys for your replies.

                                               

                                              About the page with only the email address, how do you set up a form to only send an email avoiding the lead creation? Because as far as I know, any form submit will create/update a record

                                               

                                              Regards,

                                              Raúl

                                                • Re: Security problems with Preferences Center
                                                  Grégoire Michel

                                                  Hi Raul,

                                                   

                                                  We do not. If some one new want to enter the database and access the preference center and indicate his preferences, that's OK, since the preference center is an opt-in form.

                                                   

                                                  -Greg

                                                  1 of 1 people found this helpful
                                                    • Re: Security problems with Preferences Center
                                                      Raymond Johnson

                                                      We all feel your pain Preferences Centers are generally discussed as easy to setup but once you start digging in there is a lot to take into account and consider even without all of the new GDPR requirements. I complete agree with Stanford and Grégoire both helped with questions as I was going through this process, one thing we did was split out our Preferences Center into different functional areas that all work together.

                                                       

                                                      The public subscription page, accessible on our website. The only trick we used here was to clear the cookie value on the form submission so that data is entered without being tied to an existing cookie ID. This is only able to add to new and update existing subscription, not remove any details. This uses a double opt-in, so unless you confirm your selection by clicking a link in the confirmation email everything changes back after 24 hours.

                                                       

                                                       

                                                      Manage your subscriptions page, only accessible from an email link. This clears any cookies before being loaded and uses only the data provided through the Marketo URL string to pre-populate contact details and existing subscriptions. This can both add and remove contact details and subscriptions. This also uses a double opt-in for any new subscription added.

                                                       

                                                       

                                                      Unsubscribe page, again only accessible from an email link. This also clears any cookies before being loaded and uses only the data provided through the Marketo URL string to pre-populate contact details and existing subscriptions. This can remove individual newsletter subscription or all newsletter subscriptions. No confirmation needed, but you are only able to unsubscribe the person that the email was sent to, that you clicked over from.

                                                       

                                                       

                                                      ...and because we have a number of different business units each with there own version of the above pages we also have a "Global Unsubscribe" page, only accessible from the individual unsubscribe page that removes you from everything across the whole organization. This also only uses the Marketo URL string to pre-populate contact details. which means you are only able to unsubscribe the person that the email was sent to, that you clicked over from.

                                                      2 of 2 people found this helpful
                                      • Re: Security problems with Preferences Center
                                        Sanford Whiteman

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

                                        Note you can't actually prevent people from posting the form using arbitrary data, as I mentioned above. Protection you add via JS isn't really protection at all -- except from people who are technically malicious, yet completely technically unskilled. Not a very large cohort.

                                         

                                        This is not to say it won't help higher-ups feel better, just like JS-based field validation, but it doesn't quite rise to the level of "security."

                                        2 of 2 people found this helpful
                                      • Re: Security problems with Preferences Center
                                        Shannon Kelly

                                        I learn a lot from these posts! Thank you all for taking the time to explain the details.