3 B2B Website Security Faux Pas To Avoid
WordPress has a reputation for being prone to security breaches, but this is only if security is not taken seriously or you don’t have access to an expert. WordPress is very secure if set up correctly and we recommend it for its flexibility and ability to meet just about any requirement that has been thrown at us as a website design and development agency.
The journey toward a bulletproof website involves more than just a one-time setup. It’s a continuous battle fought on multiple fronts. We’ll explore the three case studies that represent the most common B2B website security breaches and how to avoid them – without drowning you in technical jargon.
How to increase website security
Think of security as the four main pillars holding up the roof of a building. The siding, plumbing, electrical, and other aspects of your home are needed to make it comfortable and aesthetically pleasing, but these pillars keep the roof from crashing down and ruining it all.
These pillars are:
- Manage access. Implement login protection, regularly manage your users and their roles, restrict hosting access and close unneeded APIs.
- Approach plugins and third-party integrations with caution. Avoid unmaintained, unpopular, or orphan plugins and scan your theme dependencies for vulnerabilities.
- Create multiple layers of protection. Set up several layers of protection such as a CDN/WAF proxy on the top layer, an application firewall on your website, and secure change deployments.
- Backup and monitor. Regularly monitor your website for changes, uptime, and general health. Perform security audits. Always have a backup and automation in place to easily roll back the site to a prior version.
Good website security is a result of choosing the right technology (platform, hosting, plugins, and security layers), protecting access through user management, and relentlessly monitoring and patching any unexpected changes or vulnerabilities.
Case Study 1: A lead heist via formula injection
The scenario
A company used Marketo embedded forms, and Marketo does not limit character types or length during form entry or sanitize the data after input. The hacker submitted a form with a formula (also known as Formula Injection) in one of the fields. Once the company that was attacked downloaded a list of leads into Excel with that record in the list, the injected formula selected the rows in the client’s spreadsheet and sent the data to a remote server. The attacker gained access to names, emails, phone numbers, company information, and anything else that was downloaded in the spreadsheet.
The attack does not work unless the attacked company downloads data into a spreadsheet. It’s easy to see whether an embedded form is a Marketo form, however, the attacker had to either know the company routinely exported data to a spreadsheet, thereby introducing this vulnerability, or the attacker got extremely lucky. We suspect that they just got lucky.
The business impact of a formula injection attack
The hacker gained information to lead data in the particular list pull. It’s difficult to know the scope of the breach – it depends on how much data the attacked client exported at a given time with that malicious record. Personally identifying information (PII) should be protected to maintain trust and adhere to data privacy rules, and a breach like this is bad news on both fronts.
How to prevent a formula injection attack
The easiest way to avoid a formula injection attack is to avoid exporting form data to a spreadsheet. The leading marketing automation systems don’t offer character type limits without adding code or processes/automations to scrub text for unexpected characters.
We also recommend carefully picking your form input types and always making sure to sanitize the inputs. In this case, special characters were allowed and added to different text fields – which is necessary for the formula injection to work. Sanitizing the data on the server side by setting limitations on the type and number of characters that can be inputted on the front-end can be implemented via code.
Case Study 2: A free plugin with a hidden redirect (Surprise!)
The scenario
WordPress is an open-source platform. Since its early stages, developers have been able to create plugins, or software that extends the website capabilities.
Plugins introduce third-party code to your website. While we recommend regularly updating plugins from trusted sources, even those trusted providers sometimes introduce a vulnerability in a new release. There are also a ton of shady plugins that purposefully introduce malicious code to financially benefit the developer.
A couple of years ago, a plugin introduced a small code change that redirected a portion of the traffic to another website (in this case, a gambling website). It’s unclear whether the plugin’s author got hacked or intentionally did this for extra income, but unfortunately it was a popular free plugin and impacted a lot of websites.
The business impact of a malicious redirect
A redirect like this causes a lot of havoc on a website’s domain authority. It degrades trust, negatively impacts keyword ranking, and causes Google to un-rank or bury your content via search results.
Obliterating your search traffic is bad enough, but imagine the user experience of anyone who was previously considering your product. Not a great experience for someone looking for a solution to their problem, right? Overall product and PII data security is called into question and you may have lost key opportunities!
How to fix a plugin issue
Once it’s clear a plugin has caused a breach, it’s time to figure out which plugin is the problem. If you have 30-40 plugins, this is a huge job! Your website team has to go through the painstaking process of disabling plugins (which breaks functionality on your website) and then turning them on one-by-one to replicate the issue to identify the problematic plugin. In this particular case, we had to navigate a multi-layered cache to completely fix the problem.
How to prevent a plugin issue
It’s important to remember that every plugin introduces some risk, even paid plugins. To reduce that risk further (but, admittedly, not completely), we’ve established the following protocol at Airfleet:
- We check with our hosting partners to ensure the plugin isn’t on a blacklist. Here’s WP Engine’s blacklist.
- Our team maintains a separate blacklist based on direct experience or feedback from a client who previously used the plugin with poor results.
- We carefully review the plugin’s details like frequency of updates, how many users have downloaded the plugin, and its rating.
- We review the plugin author’s background to determine whether it’s a legitimate company or an independent developer.
- Finally, the plugin must be compatible with WordPress’s latest version.
Once the plugin passes our initial reviews, we install the plugin in a staging environment and test it. If there are any compatibility issues or a negative impact on the website’s UI, performance, or security tests, we don’t deploy it to production and keep looking for an alternative solution.
Another key to managing plugins is retaining an audit history on your plugin updates that catalogs the versions installed over time to make it a bit easier to correlate a break with a specific update.
Case Study 3: The case of the anonymous website editor
The scenario
Have you ever had the sense that someone moved things around either on your desk or in your home? Spooky, right?
It’s the same feeling we get when a website changes unexpectedly. Maybe a title gets jumbled on the home page or the product page has weird text. No one admits they did it, but everyone sees the change.
The diagnosis? Anything is possible! Human error, intentional defacement, a feature that behaves unexpectedly for the end user, or perhaps a bug.
The business impact of unauthorized or unexpected edits
If someone intentionally defaced your website – perhaps a disgruntled contractor or former employee – it can call your company’s reputation into question, particularly if they’ve made false claims about your product or executive team. It’s every marketer’s nightmare.
Any change that goes unnoticed by the marketing team can harm your department’s reputation. No one wants to give ammunition to a VP of Sales who is already eager to trash marketing’s credibility.
How to prevent unauthorized or unexpected edits
We advise following these best practices to reduce the risk of unauthorized or accidental changes:
- Limit user access. Never provide access to users that do not need access. Limit users’ access to the job they will be performing. For example, SEO specialists or copywriters don’t need to be administrators and they certainly don’t need access to your hosting server, DNS, or CDN. Only give access to advanced website elements or software to the people who know how to manage it.
- Review your users regularly. When employees or freelancers leave the organization, it’s important to revoke their permissions.
- Don’t leave APIs Open. WordPress utilizes the xml-rpc for remote read/write capabilities and we usually recommend disabling it. In addition, look for open generic endpoints that allow access to user data. For example, one test would be to append this to your website domain to see if it works: /wp-json/wp/v2/users. When properly handled through security setup, such an attempt would be blocked
- Monitor. We highly recommend adding tools such as Wordfence, a plugin that adds an application firewall and tools like an Audit Log which logs any user activity including logins, page edits, and settings changes.
- Enforce login best practices. At Airfleet, we made 2FA a standard long ago. We recommend using this extra step with any application used on a daily basis or that contains sensitive information. Enforce strong passwords, never share your profile with other users, and recommend your employees use a password manager to suggest and store complex passwords. Lastly, we usually recommend changing the default WordPress login path /wp-login to something impossible to guess to add one more layer of protection.
- Use a WAF proxy. Because attackers are becoming more sophisticated we highly recommend adding another layer of protection. There are many solutions to choose from like Cloudflare, Cloudfront (AWS), Imperva and Akamai to name a few. Cloudflare provides great value for their entry tiers. Whichever solution you use, we recommend restricting access to administrator locales (by IP or region). To take it a step further, you could restrict access to the public-facing website to certain countries or regions. I would also highly recommend adding all crucial security headers.
An ounce of prevention: The role of audits
Regular audits act as the critical third layer of defense, offering a chance to catch vulnerabilities before they become a problem. Periodic, thorough examinations keep your security measures ahead of hackers’ ever-evolving tactics.
Out of necessity, we developed a clear audit protocol at Airfleet. It allows us to analyze all security aspects and address any issues. We provide website owners with a simple report detailing necessary action items because trust and transparency are key. If you have any concerns or need advice, please reach out to us. We’re always happy to assist!
Website vulnerabilities keeping you up at night?
