Security : Server side validation / SQL injection / XSS

[Anonymous]

Hi,

Our security scan on Marketo form is now revealing that Marketo form accepts invalid inputs such as HTML code etc.For example, <script>Alert(‘Hacked’);

This flaw may cause several security issues, such as SQL Injection, Cross site scripting (XSS), etc.

I do many researches on Marketo community and find no articles talking about how Marketo handle such invalid inputs/SQL injection/XSS on Marketo form.

Does Marketo have server side validation or any security mechanisms to validate invalid inputs and mitigate risks such as SQL injection, Cross site scripting (XSS), etc.? Any suggestion to overcome this security flaw is appreciated.

Thank you in advance for all comments.
Regards,
Taworn D.

[Tim_Tran5]

Do we know if this critical security flaw been resolved? or its been 6+ years and Marketo has made no progress?

[tware]

Hi Tim, MKTO hasn't done anything about this, we currently have an open Support Ticket and they have acknowledged that a hacker can bypass the form and inject malicious values into MKTO however they do not consider it a vulnerability to the MKTO database and deem it harmless.

Since this has been going on for some years, curious what others have been able to do on the client side to remedy this? 

[SanfordWhiteman]

You can’t do anything on the client input side, by definition.

On the client output side, make sure everything is HTML-escaped. Marketo does this automatically with LPs and allows manual control with emails.

Have yet to hear what actual vulnerability is being described here. The correct practice is always to escape output.

[SanfordWhiteman]

Escape your output. That's how you deal with untrusted input (always).

Exactly what vulnerability exists when you properly escape output?

(And all user-supplied input should be considered untrusted, regardless of whether it's said to be "sanitized".)

[Jonathan_Marzin]

It's an old thread, but did anything come of this? How does Marketo account for SQL/HTML injection?

[Dan_Stevens_]

We're still trying to understand the same thing - and how to remove these leads from our instance.  While working in RCE, we came across hundreds of malicious form injects.  Not sure how old they are, but so far, Marketo Support still has no answer (case has been opened for almost a month now).

Re: Malicious leads via form submits - how to remove?

[Anonymous]

What we first tried was to create a filter that dropped all leads with a name beginning with a number. Problem was the spammer was using hexadecimal, so that only reached some of the bad leads. The available filter tools were a bit limited, so we switched to manually finding and deleting them. We were lucky in that there were two fairly reliable fields we could search for that would return a list of 90%+ spammed addresses, so we searched, then manually deleted all the bad records from the returned list. Took quite a while, but we brought it down significantly. I added some javascript and attached it to the form submit on our end, to prevent the form from being submitted through us with bad data, and that effected a reduction, but not complete elimination. It's not an ultimate solution; I expect it will be just a matter of time before that measure falls as well.

Since then we've been evaluating the idea of presenting and handling the form ourselves, so we can write and enforce our own spam-filter rules, then using an API to insert them into Marketo. No reports available from that effort, yet; we're still evaluating the Marketo APIs for usability and fitness for that purpose.

[Anonymous]

You can also add code to do your own custom validation right in Marketo. Just look up the form.onValidate examples. We wrote a validation routine and put it in a snippet that we drag onto the landing pages that need the validation.

[SanfordWhiteman]

While we've done some very elegant things with the Forms 2.0 API, that's still client-side validation.  Client-side validation is all bypassed by bots (or any noscript environment). If bots are a direct problem, that's not the solution.

[Erin_Van_Leer]

Am I understanding correctly:

- Bot spammers often bypass client-side validation on Marketo forms (including default Marketo validation and any custom JS/CSS I've added) so that's useless against anything but the most basic spam bots,

- Marketo has no server-side validation measures in place so there's no protection offered there,

- Marketo has known about this vulnerability for 4 years now and hasn't done anything to fix it?

[Kenny_Elkington]

I don't recall if anything came from this specific thread, but we take security seriously and employee modern security practices to combat XSS and SQL injection, in addition to many other attack vectors.  You can read more here: TRUST - Security and Customer Data Protection - Marketo

[Anonymous]

Well, we don't have that particular concern...in our case we have someone reading the form fields, then auto-submitting a few thousand per day with a 13-digit hex number in the name field. It's easy enough to filter that out of a smart list, but I want to keep it from getting into the db in the first place. Marketo just lets it in, no apparent way to insert some server-side filter that just drops the record.

[SanfordWhiteman]

Approach your forms workflow from a different angle. Require a valid reCAPTCHA response or delete the lead immediately. Bot-generated posts will not pass reCAPTCHA.

[Anonymous]

BTW, both Google's original reCAPTCHA and the follow-on NoCAPTCHA reCAPTCHA have been solved by some spam bots (https://www.shieldsquare.com/sorry-google-captcha-recaptcha-doesnt-stop-bots/). The latest entry in the field, the invisible reCAPTCHA currently works, I hear, but I'm wondering about its long-term viability.

[SanfordWhiteman]

(And there's some supreme nonsense in that blog post, too. Note the POC link has been taken down.)

[SanfordWhiteman]

Arlen, there's no better solution on the client side than these technologies. If you want to pass data through your own server, you of course may. But then you'll have created a brand-new DoS vulnerability, since all the API endpoints you could use to push leads into Marketo are rate-limited -- hardly an improvement if your resources are in fact under strain.

[Anonymous]

Even if you're right, client-side controls always have the potentially fatal flaw that the client is actually in the control of The Other Guy, not me. No mater what, that is the  card that trumps all. It's why I think all client-side solutions are ultimately doomed, even if they enjoy a short period of effectiveness. The alternatives are participate in a client-side arms race, or move your prevention measures to the server side.

All sites have a DoS vulnerability, whether it's on the processing end of the form, or on the end serving up the link that sends people to the form. It's a fact of life on the web, and there's a common body of practices available to limit its effects. I'm not concerned with the computer resources; I'm concerned with saving the time and effort the human resources around me are expending dealing with the mess created by polluting the leads with the rest of the crap. The easiest, most efficient way to clean up a database is to not let it get dirty in the first place, and if spending a few computer cycles can help with that, it's worth the trade.

That's why it's worth exploring the API Marketo has for remotely inserting leads. I'm not trying to save on computer resources; I'm trying to get the computer to do the drudgery it's so good at so our people have more time to do what *they're* good at.

[SanfordWhiteman]

I'm pretty sure you're not aware of the limits in question.

A maximum of 30,000 form posts per day can be gatewayed from a remote server to Marketo using the API. 30K total.

A maximum of 43,200 form posts per day *per source IP address* can be forwarded from browser clients to Marketo. 100 source IPs: 4 million form posts.

So this is not a question to be waved away with "all resources are finite." It's many orders of magnitude of difference in the real-world resilience of two services: one that can be quenched by one end user over a 14.4 modem in half an hour, the other that would require sustained, distributed abuse.

Have you used ReCAPTCHA with Marketo, or are you just deciding it won't help because of an old blog post?

[Anonymous]

Interesting. Marketo says I get 50K API calls per day, each call allowed to insert a max of 300 leads per call (Marketo's REST API documentation is my source for that; I haven't tested those limits so if Marketo is lying to me about it then the rest of the math here isn't applicable). My math says that means I can insert a hard upper limit of 15 million or so leads per day (if I can manage that with a limit of 5 calls per second). If we allow for an overhead of as many as 4 calls per insertion, that still equates to a little under 4 million leads per day. I doubt our end-user with a 14.4 modem can submit that many leads that would pass our validity checks in half an hour. But let's say he can, that's not the only tool in the box: If aside from checking the validity, we rate limit to one contact form submission from a particular user every 20 seconds or so, our single user (oh, give him a full-bandwidth pipe instead of a 14.4 modem) gets to use up about 50K leads per day, leaving plenty of room for the rest of the world.

Or were you assuming I was going to make my server pretend to be a browser submitting a form?

By having the lead form post to our server, and not Marketo, we can not only control for the validity of the leads going to Marketo, but we can control the size of the batches and how frequently we update Marketo. Side effect: If we generate a spectacular amount of interest, we can buffer the leads accumulated on our end and send them in as rate limitations allow. So if for some reason we generate more than a few million leads in a day (or a stretch of days) we could buffer them on our end, and get them in to Marketo when time, and rate limitations, permit. Admittedly, if that keeps up for a long stretch of time it can become worrisome. But if that's the case we'll be making enough in profits to cover more drastic, and expensive, approaches. Anyway, we're still looking at it as a possibility; we'll have to do some serious tire-kicking (read: code writing) before we head in that direction.

I haven't used the reCAPTCHA with Marketo for two main reasons. First, I don't use the Marketo forms designer because we have not been able to consistently (that's probably an understatement; I don't think she's passed even one of them) produce forms that pass our designer's standards using it. And second, I don't like arms races; I prefer not to play. Google has twice already revamped reCAPTCHA, so I suspect I'm not alone in mistrusting it as a long term solution (though I'll admit to being a little fascinated by their current 'invisible' approach, and wondering how it'll work out with mobile and assistive tech users and other fringe cases). Hence my focus on server-side controls.

Anyway, this has now gone way far afield from the original topic. My fault, my apologies. It was not my intention, but the right buttons were pressed, and I gave in.

[Anonymous]

Interesting. Marketo's board sensor has the effect of making me sound more foul-mouthed than I am. Note the word it deemed too bad to be allowed was a four letter term that begins with 'c' and ends with a three-letter name for a style of music. Dictionary.com doesn't even call it slang when used in the manner I was using it (meaning #3, if you're playing along at home).

I wonder if crud would have fared better?