It’s important to be aware of security when you run a professional programming company. Chad Fisher is the owner of BTown Web, an ecommerce web development company focused on helping companies sell online.
With high profile hacks occurring almost monthly, security has become an even greater concern for companies that are selling online. I was curious what web development companies are doing to address their client’s security risks and reached out a friend of mine.
I have known Jonathan Martin for over 5 years and have followed him as he created his programming company Cool Blue Web from just a couple programmers to over 25 full time developers. His company works on many ecommerce platforms and I wanted to know what his clients were asking and what worries him on the security front. This is my interview with one of his lead developers.
What are the biggest security risks that your customers mention?
Store owners tend to be concerned with the most visible or most discussed risks. Most of the security questions we field are around out of date plugins, password strength, and issues around SSL/HTTPS web page service. PCI compliance comes up with some frequency as well.
With the possible exception of PCI Compliance, all of the items on this list have a way of making people yawn. In the realm of computer hacks these seem like fairly mundane and trivial details, but having the basics covered is the first step toward keeping a site secure.
What security risks keep you up at night?
The biggest, scariest risks we’ve seen have actually been around careless passwords and weak coding and server configuration practices. Concern about passwords at the website admin user level is one thing, but passwords and usernames that allow admins to access the machine hosting the site, as well as the database with all of the information used by the site, are far too often very weak.
Weak coding practices have a way of making things scary as well. For example, I’ve seen sites that store credit card data directly, without encryption, in the database. Besides being a violation of defined industry best practices, these sites put their customers at major risk.
Carelessness at the server setup level can leave gaping security holes as well. I’ve seen at least one example where vital directories are exposed or open for reading, which hackers can use to dissect target sites’ code for weaknesses and look for sensitive data within the file structure (such as the password credentials to the site database).
We have also seen sites which have built-in backdoors added in by “clever” developers in an attempt to facilitate a failsafe recovery system. While the idea of a backdoor sounds great in theory, site owners should realize that a “backdoor” swings both ways - hackers that find the failsafe can take advantage of it.
How are you proactively ensuring the safety of your client’s code and/or data?
We use a multi-pronged approach to keeping our clients code and sensitive information locked down. We use a combination of plugins and third party services (word fence, sucuri, etc), a strict policy around the protection of client credentials, standard server configuration files which are used to protect against known weaknesses, and we are constantly communicating about the latest hacks, updates and risks.
Communication is arguably the most important aspect of our protection activities. Thieves and security experts have been in a constant race to get ahead of one another since the conception of lock-and-key; this is one aspect of life that has not changed in the information age. In order to protect against a flaw or vulnerability at the code or server level, we keep our ear to the ground for recommended updates and strategies for countering newly discovered hacks, bugs, etc. We look to our favorite sources on the internet to keep us informed, we surf the boards, and we talk to each other about security regularly.
How are you storing client usernames and passwords?
We are using 1Password (a paid service) to store our and access client credentials. 1Password uses end-to-end encryption (with the AES-256 bit algorithm) and account-level passwords to securely encrypt, transmit and decrypt our client credentials as appropriate. 1Password takes care of all of these activities for us - because of this abstraction all we need to do is login on our machines and store/access information. The developer accounts, themselves, are locked down with secure passwords, that only each individual owning developer knows.
1Password allows the team to have ready, secure and centralized access to important client credentials without the need to write down or backup this sensitive and business-critical data. If a credential is updated on a site or server, we have the power to update that credential in 1Password. This saves us an immense amount of redundant communication and confusion around “out-of-date” credentials.
What type of security recommendations do you make for your clients?
Customers do well to demand that their developers and hosting staff adhere to strict standards when it comes to password management. It’s important to avoid sending passwords over chat and especially over email as well. If passwords are ever passed around this way, they should be updated by their owner immediately.
There are all kinds of cheap tools and scripts that hackers, with very little skill, can use to take advantage of things like weak passwords, out-of-date plugins and lack of SSL certification. By locking down these aspects down, site owners already make it much more expensive and time consuming to crack the site’s security measures. That isn’t to say that a site owner is fully protected at that point (is there such a thing as “fully protected?” Many large firms have been hacked in the last few years), but it’s a huge move in the right direction.
At the end of the day, no outside entity can keep a site 100% secure for the site owner (though they should definitely have high security expectations for their technical service providers). If the code and server are 100% locked down, but an admin on the site has a password like “12345”, they’re still at tremendous risk of their site being breached. Site owners do best to keep an ear out for new security updates and concerns, and to update their passwords on their site every 3 - 6 months as well.
Do you have documented security policies covering client data? If not is this something you are planning to create?
We maintain a company knowledge base which helps our team get quick access to standard setup files, code snippets, and general best practices around security and web work in general. The resources in our knowledge base (a simple Wordpress site) include server configuration files, repository configurations, scripts to sanitize data on local site instances and procedural documents describing how to protect against particular vulnerabilities.
Have there been any hacks of your client’s sites? If so what was the cause?
We have seen a few site hacks over the last year. The most popular hack seems to secretly update the PHP files running behind the scenes - even going so far as to write the updates 1,000 characters to the right of the main part of the file so as to be missed by developers (crafty!).
We have also seen hacks where hackers threaten to exploit security deficiencies if they are not paid a ‘security’ fee. These people will send emails to site owners demonstrating the security hole, and then offer to ‘audit’ or ‘fix’ their problem for a stiff fee. While this may sound innocent/helpful enough, the web community established long ago that such activity is tantamount to a threat, and the hackers behind these attacks know it.
The two most frequent vulnerabilities inviting these attacks, as far as we are able to tell, come down to outdated software and not having server security locked down. Where outdated software is concerned, this means that any software being used by the site, be it the core website software or the plugins that support it, should be up to date against the latest release. Even plugins that sound insignificant may expose massive security issues - there was an issue with an image library a few years back that allowed arbitrary files to be uploaded to a site server by simply requesting nasty URLs from a site using the library, for example.
Where server security is concerned, the two biggest security holes we’ve seen have to do with improperly configured file structure permissions within the websites file path, and failing to use the web server software configurations to block access directly to highly sensitive directories and pages. This is especially true if the supporting technicians are using a repository for code management, and the directory holding the repository info is stored within the root folder of the website. Access to that (and any other sensitive) directory should be explicitly blocked from HTTP traffic by the web server configuration.
Was your company able to fix the hack? Did you or the client change their security practices afterwards?
The countermeasures to these attacks usually boil down to reinstallation of core software suites and plugins, using the most up-to-date code available, as well as doing a sweep of server configurations and tests to ensure that classic, known attacks are blocked from being exploited. This process can take a site down for 1 day or longer - much longer if the code hadn’t been updated in a long time (new versions have a way of introducing small bugs - many new versions, piled on at one time, have a way of introducing bigger bugs). Both the company and our clients have reacted to these cases by bolstering their security processes in every one of these cases so far.