If I told you, “you can protect your business with just ONE minute per week,” you’d do whatever I said, wouldn’t you? Well, I’m going to give you that answer — at the end of this post.
But first! The best way to learn about security is to see real-world problems, so I’m going to show you a little XSS bug that we had on our www site and how we fixed it. Then, I’ll get into security strategies you can apply in your own business.
The ugly bug
Hey, look! It’s cross site scripting (XSS) in action.
It turns out that, up until a few days ago, you could inject code into our www search results page by searching for something like:
"><script type="text/javascript">alert('zzz')</script><a href=" Fixing it is a matter of adding the “escape” filter to the template output, literally a 2-character fix with the Twig templates in HiFi (which is our current CMS):
<input id="search_field" type="search" … value="{{ hifi.http.get.query }}"> Versus:
<input id="search_field" type="search" … value="{{ hifi.http.get.query|e }}"> Thanks to Anand, a friendly security researcher who took the time to test our site and email us about this. He’s a shining example (and recognized by Facebook and Twitter, to boot) of professionalism among security researchers — we got a direct email directly rather than public disclosure.
This gave us time to think through the ramifications — could someone use this to steal an admin session? To inject items in a cart?
We tried to use the XSS bug and found that our systems are safe from those attacks. Our admin and stores are on admin.foxycart.com and yourstore.foxycart.com. Our main site is at www.foxycart.com, so any Javascript there won’t be able to access cookies on the other subdomains. Browser same-site origin policies permit accessing “downward” in a domain only so, e.g., scripts running at foxycart.com could read cookies under admin.foxycart.com, but www.foxycart.com can only read from www.foxycart.com, or something beneath it like assets.www.foxycart.com.
But relying on random Internet strangers is not a real strategy, just like hoping for more customers isn’t going to get them coming in the door. So what to we do? Hire a penetration tester.
A… a what??! “Penetration tester?!”
Sounds dirty, right? “Penetration tester” is a fancy name for “someone who tries to break into your system and then tells you what they found.” Think Robert Redford in Sneakers: your server’s the bank, and your pentesters are the guys that sneak in during the night to sit down at a terminal and create a million dollars out of thin air.
Our pentester was wrapping up their report when we got Anand’s email. And guess what! They found the exact same vulnerability.
Hiring a professional security firm costs a bit, but for a business that relies on its site it’s worth every penny. Look at all that they do:
- Scans for commonly vulnerable services. Often there are services running on a new server that you don’t even know about — and probably shouldn’t be running.
- A fresh pair of eyes. You labor over your site and pour yourself into your work, but it’s hard to break something you love.
- In-depth attacks and analysis from security professionals. At the end, you’ll get a report with full details AND instructions on how to fix any issues found.
Beyond all that:
- Sleep better knowing that you’ve done your best to protect your site.
There’s nothing like submitting your site and getting a “clean bill of health” in reply — it means that you’re doing something very right when it comes to security. Why guess at security when you can know for sure? (We should note, however, that in security there is never truly a “for sure, definitely ‘secure'”. It just doesn’t exist, which we’ll probably discuss at some point in the future 🙂
The FoxyCart security process
“Yes, very well and good,” you say, “but how’d you deploy an XSS exploit to your www site?”
It’s a good question. We hold ourselves to extremely high standards when it comes to security, both because we take our responsibility to our users very seriously (this isn’t “just a job” to us, either), and because, as payment card industry (PCI) service providers, we are held to the PCI DSS. (Good news there: We’re compliant at the highest possible level, Level 1 Service Provider.) All the best intentions, however, don’t mean anything if the practices and procedures to back them up are lacking.
So how did this happen? Let’s first clarify that this exploit was on our “www” site, which is completely isolated from the admin & cart are our application code, and lives on completely different servers. The app code is in a different repository, surrounded by stringent development practices.
Our developers review every commit to the app code, looking in particular for security problems. Our review process combined with strong filtering libraries and extensive internal testing mean that XSS bugs like this don’t make it into the production app.
Our www site development process is, on the other hand, more flexible. The marketing team (as opposed to the core development team) works on it, and though our entire team is trained on security vulnerabilities, the emphasis, oversight, and code reviews are different (especially as there’s no account or login functionality hosted on www itself). That said, the www site (as with all FoxyCart properties, like the forum, wiki, and others) are indeed included in our pen tests.
The question you really want to know about is, “How safe is my store?”
The short answer is: As safe as possible, but you shouldn’t take our word for it. You can look at our PCI compliance, and know that we’ve had multiple third party pen testers review our systems over the years (and at least annually).
So how soon did we fix this issue? The same day we knew about it. In this case it’s a small issue, yes, but even a small issue can be a foothold for a larger attack.
You can also bet that we added “test the forms on our www site and look over any new or changed pages” to our already extensive monthly security testing.
What’s your security process?
There’s a simple lesson you can take away from this: it’s not just your application that needs protection! It’s easy to ignore peripheral systems like a www site, forum, or wiki. However, that’s often where an attack starts!
So what can you do?
Better security in just one minute per week
A great place to start is by signig up for the security lists for everything that you use — frameworks (like Rails, Symfony, Django, ExpressJS, etc.), tools like phpMyAdmin, forum software, wikis, Ubuntu/Debian/RedHat security lists, etc. You need to know about security patches for anything hosted under your domain.
You can’t fix issues that you don’t know about!
Here’s the real trick: Don’t filter these messages into a folder. Trust me, if you do, you won’t ever get around to reading them. You want those messages IN your inbox so that you’re forced to pass your eyes over them and DO something — even if it’s just to archive them. Most security lists are low volume, with at most one or two emails a week.
Form a habit of actually reading these messages, and then patching your software when needed. You, your business, and your customers will prosper from your diligence.
Thanks for tuning for this issue of “Adventures in FoxyCart Ops!” Until next time…