Ecommerce: External Script Audit

A friend runs an ecommerce company and has asked for some help. The company started small, selling private label fashion, but has now grown rapidly and has a lot of traffic.

Over time his team have implemented many external scripts (tracking pixels, external advertising scripts, third part consumer behaviour scripts etc). He is concerned about how to audit all of these effectively (and on an ongoing basis) to ensure everything is legitimate and none of these scripts are presenting a security concern for his shoppers. Either because it is malicious, or because it is simply doing more with their data than it is supposed to.

What is the best way to go about this? Is there potentially a ‘hygiene code checker’ type module out there for checking remote code before its executed on a client’s machine?

Any advice or pointing at a product/service provider who could help would be much appreciated.

Yes, that makes sense. It's a software "anti-pattern" that can be largely solved with Composer (https://getcomposer.org/). Composer allows you to designate the scripts and release levels that your application

It's third party javascript primarily, being called from internal ecommerce platform code. The code base has grown so quickly, how does one do the following in a timely manner:
1. Identify all external scripts so they can be reviewed individually and manually?
2. Parse or verify the code in these scripts to ensure there is nothing malicious or customer details are not misused?
3. How can the security team identify and monitor external scripts on an ongoing basis?

Manual review of the code is always an option, and the current solution. But is there a better way?

It is probably time for a demolish and rebuild
I hope they didn't build there own e-commerce but use a payment provider. Building a secure payment module is prone to errors and subsequent security problems. using a payment provider removes these security concerns from your site to the payment provider. This also keeps the customers private information off of your site. Even Steve Gibson of https://www.grc.com and a security expert uses a payment provider as he did not want the responsibility of keeping his customers data secure on his hosted website.

He is more concerned about third party scripts that deliver legitimate services. Such as track user behaviours, display a scroll bar of products down the side, display a product based on what the user might like etc. All of these are provided by legitimate third party companies. The owner of the site is trying to think proactively about possible threats to their shoppers in the future; what if one of these providers are hacked and this trusted script is suddenly modified to serve some kind of malware to shoppers?

Even a rebuild would only give some assurance about what is in place at that moment in time. No matter how well you manually attempt to catalogue things, these ecommerce sites grow at furious rates and within six months it would be a mess again.

Yes, that makes sense. It's a software "anti-pattern" that can be largely solved with Composer. Composer allows you to designate the scripts and release levels that your application depends on ("Dependencies") so you know you're always building on a stable code base. There are similar dependency injectors for JavaScript, and task runners that can build your libraries for you (Grunt, Gulp, etc.) These help keep your work organized and your dependencies at known, trusted and stable release levels.

For the most part, if you start with trusted components and download your own copies (or serve only from the stable CDNs like Google and Twitter), you will be OK. If you're unsure about the stability of a script, just make an MD5() digest string from the code (sort of like what GitHub does). If the md5() ever changes you can flag the code for review.

To your specific questions...

1. Identify external scripts? No problem if you're using Composer. Otherwise, begin the task by reading the HTML documents and looking for off-site URLs. This is a time-consuming task, so prepare to spend a while making the inventory.

2. Verify there is nothing malicious? Expect there to be malware in anything you're getting from a tainted external source! Read the source code. If the code comes from a reasonably popular and well-respected source like GitHub, you've got a fair chance that other people are reading the code, too. And if there are security holes found in open-source software they are usually patched immediately. If the code is from third-party suppliers who are not part of the open-source community, you have to trust them. If you can't trust them, don't depend on them, full stop.

3. Identify and monitor... ongoing basis? Information technology security is a full-time four year college major today. The threats are always changing and there's no answer you can get in a forum that will keep you protected in the future. In fact, it you start that college major today, by the time you graduate there will be new threats entering the world and curriculum. Most installations concerned with security (especially those growing very fast) will have on-staff professionals or will hire a consultancy like PwC or McKinsey to help monitor the ever-changing threats and issues. If you want the management-level overview, consider joining OWASP and becoming active in their work.

It should go without saying, but I'll say it anyway -- if someone deploys a site that depends on foreign code without understanding exactly what the code does, well, they probably deserve what they're going to get! If you were thirsty and you found a bottle of unknown liquid would you close your eyes, hold your nose, and drink it?

Featured Post

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

JavaScript can be used in a browser to change parts of a webpage dynamically. It begins with the following pattern: If condition W is true, do thing X to target Y after event Z. Below are some tips and tricks to help you get started with JavaScript …