(Article 4 of 15): This wiki is part of an expert series that discusses important web security standards to weigh before selecting a web hosting provider and which steps to take to protect a website from hackers. We’re talking ‘Web Security for Dummies 101,’ written for beginners who can’t imagine stomaching a training course, books on the advantages of security testing, or articles about a subject as boring (but important!) as this. For a condensed version of these tips from a whitehat perspective, download our handbook: Ultimate Guide: 15 Ways to Intelligently Host Your Site Like a Pro.
Hosting on the Internet without web site security is like criticizing the PR department of a Mexican drug cartel. It’s just not a good idea. What else is not a good idea? Pretending your site’s security is someone else’s responsibility until the day you wake up to discover your website is down, hackers have stolen your customer’s passwords and personally identifiable information (PII), a non-compliance fine is imminent, your reputation is hopelessly tarnished, and all of your hard work is achingly gone. Prep the typewriter … because your next excruciating move is to send out the bad news to your loyal customers.
It’s bizarre, but despite the growing threats including ransomware viruses like WannaCry and Petya, most small business owners don’t have a site security management plan when it comes to implementing best practices to protect their most treasured assets: their website and their customers. Nor do they have the foresight to determine if they’re in good hands by having clear visibility into their web host’s security strategy (or, as it turns out, lack thereof).
So let us consider a checklist of all the powerful fundamentals and guidelines for how to quickly and easily get educated and perform an analysis before this unspeakable tragedy happens to you (and, sadly, it happens all the time).
Don’t Be Lazy
Stop conforming with the masses and go strengthen your passwords right now. They probably suck. 60% of the top 10 most popular passwords contain some variation on the sequential usage of numbers from 1 through 9. So if your password is “123456,” or uber-popular choices like “qwerty,” “qazwsx,” or the #32 most-popular and oh so cleverly derived “f*cky*u,” you’re recklessly playing with fire.
Get a CLU
What makes your password resilient to the flirtatious advances of remote hackers lounging in the depths of their mother’s basements? Consider adopting the CLU strategy (because they sure as heck won’t):
But Your Brain Hurts
How are you supposed to remember all of those passwords (you plead desperately with a waver in your voice)? One easy-to-remember technique is to use the same combination of digits in conjunction with the company/service name requesting the password. All you have to do is remember the combination of digits. Of course, if anyone discovers this, you’re doomed. Otherwise, take advantage of the available services that securely store passwords like LastPass and KeepPass.
Multi-Factor Authentication
This is also a slick way to quickly add some sturdy bars to those breakable storefront windows. Sometimes the settings for your applications allow you to enable this as supplemental security, in turn asking you for one piece of information that only you can provide.
Customer Password Encryption
Have your developer encrypt your customer’s sensitive information with a hashing algorithm like SHA. And add a pinch of salt (they’ll know what I mean).
What About Your Web Host?
A tell-tale sign of a web host’s philosophical stance on implementing web security standards is detectable the moment you sign up for a new account. If they don’t force legitimately strong passwords (defined as those you’ll forget unless you write them down), that’s a red flag – particularly if you are hosting in a shared environment. This is because passwords, like a chain, are only as strong as the weakest link. The compromise of one customer’s account due to a poorly structured password can lead to heartburn for everyone sharing the same server.
So, Now You Want to Be a Hacker?
That sparkle in your eye says to me that you’re curious about how these l33t hax0rz (translation: elite hackers) crack passwords in the first place. Well, I’m not going to perpetuate the problem by aiding this segment of the gene pool, but I’ll offer a wee little hint. Hackers use a number of techniques with the most popular being “dictionary” and “brute force” attacks carried out by a persistent legion of bots that spend endless hours attempting to guess your passwords. Web hosts who are on the ball will automatically detect cleverly disguised botnets scattered across multiple IPs and swat them like the annoying flies they are.
And while you’re at it, change your router’s password, too. It’s about time your neighbors pay for their own Internet access.
It’s really in your best interest to patch up what might otherwise be a sinking boat with you at the helm. The longer you wait to do this, the harder it can be to accomplish later and the worse the security risk becomes – like a growing avalanche of suffocating misery. Like a British car, outdated applications can suddenly cease to function. As the application’s functional environment evolves around it and old code becomes deprecated (ie. put out to pasture), your application stagnates to the point of becoming as unreliable as someone buying furniture from you on CraigsList.
Email Notifications
First off, do you already get notifications of updates for your applications? If yes, quit ignoring the peace of mind they provide and follow their instructions to patch your outdated applications. If not, determine if you have a control panel for your web site (like cPanel). Sign into it and find the application installer (eg. Installatron, Softaculous) to gain access to your list of installed applications (eg. WordPress, Drupal). It’s there that you can configure these instances to either automatically update themselves (and their plugins) or notify you by email when new releases become available.
There are also plugins that will help send along email notifications like WP Updates Notifier (note: this plugin hasn’t been updated in awhile).
Avoid Applications Susceptible to Vulnerabilities
If you’re keenly interested in how to protect a WordPress website from hackers, users of plugin-heavy blogging/CMS platforms (eg. WordPress, Joomla, Drupal) must pay close attention not only to the number and quality of reviews for the plugins they choose to install, but how many people are using the plugin, when it was last updated, and whether its compatible with their current version of the installed application.
What About Your Web Host?
Quality web hosting services will absolutely take security issues seriously and not only keep their own infrastructure patched and up to date, but proactively ensure you do as well. There are a couple quick ways to tell how seriously your web hosting service takes application vulnerabilities:
Advanced Tools
For those that like to get their hands dirty, there are tools that can monitor application dependencies and alert you about updates and vulnerabilities. Try Gemnasium for auto notifications, Composer to manage dependencies in PHP, and npm for Javascript. RubyGems is a gem hosting service for Ruby on Rails.
You’ve probably noticed this by now, but for those who have locked themselves in the bathroom for the last twenty years, this is how all data is transferred between websites and its visitors. HTTP (HyperText Transfer Protocol), while still very much in use, has become as passé as paper. Speaking of which, HTTP is unsecured and akin to a website writing down its contents on a piece of paper, folding it into a paper airplane, and chucking it at your head from the roof of a high-rise building. On the other hand, HTTPS translates the data into ultra-complicated Pig Latin, locks the paper in a metal briefcase knowing only you have the key, handcuffs it to a super cool spy-like fellow, and has him deliver it to you.
Like, Google Totally Likes You Liking HTTPS
In 2014, Google announced that websites embracing HTTPS would be rewarded by making HTTPS usage a positive ranking signal. As of January 2017, Google’s Chrome started marking non-HTTPS sites that collect sensitive information, like passwords and credit cards, as non-secure.
Man In The Middle Attacks
Other than sounding like a creepy human sandwich laden with testosterone, HTTPS prevents MITM attacks where an unwanted individual snoops in on the conversation by intercepting data between your site and its clients. As a business owner, leaking data that may include personally identifiable information (PII) can open you to fines for being non-compliant with PCI DSS.
How to Go All Clandestine With Your Data
Quite simply, you need an SSL (Secure Socket Layer) website security certificate installed in order for your website to leverage encryption and communicate securely over HTTPS. This is an absolute architectural requirement if you run an e-commerce website and plan on collecting sensitive information from your customers.
Similar to domain names, SSL certificates are generally renewed on an annual basis. However, there are free alternatives you should be aware of. While SSL certificates are often something that are installed manually following the instructions offered by the certificate provider, your web hosting company may offer options within your control panel (eg. cPanel):
Redirecting to HTTPS
Once you have the certificate installed, force all inbound traffic to redirect from HTTP (port 80) to HTTPS (port 443). Check to see if your blogging/CMS platform has a setting to enable this, or make the following change to the .htaccess file in your web root directory (eg. /home/youraccount/public_html(or www)/.htaccess):
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.yourdomain.com/$1 [R,L]
HSTS
Force all browsers to communicate with your website over HTTPS by including a HSTS response header as part of your web security policy, making it impossible for shadow-lurking attackers to read or modify data being transmitted from your site. This only works after the first visit unless you implement HSTS preloading which is a method for communicating to major browsers that your site requires communications over HTTPS. A HSTS header looks something like this:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Warning: Do not add this header unless you intend to stick with HTTPS. Removing this line will leave visitors, whose browsers previously processed this header, unable to access your site until the max-age parameter has expired.
Once you’ve added this, use this online HSTS testing tool to see that the header is functioning properly.
This is not a perfect analogy by any means, but imagine your high school-aged daughter is dating and you’re settling in for an evening introduction. File permissions decide who gets the pat on the back with a curt nod toward a 11pm curfew … and who gets some pump-action from the 12-gauge.
If that wasn’t clear enough, file permissions declare who can and cannot touch your files. Applied individually to both directories and files, permissions can be assigned to three groups: Owners, Groups, Public (or “Other”). It’s the last group that should concern you most. For if your permissions are set improperly, that punk kid from down the street can touch and modify your files without your knowledge. Grr.
Permissions can be set either in SSH (Secure Shell) using the chmod command (Linux), or via your FTP client, typically by right clicking on a directory/file. Most directories can be set to read and execute for the public (rwxr-xr-x, or 755), whereas files can be set to just read (rwxr–r–, or 644). The files to watch out for are those that allow read, write, and execute (rwxrwxrwx, or 777).
A word to the wise: setting your file permissions incorrectly can cause some applications to stop working. If all else fails, get the advice from a web developer, network security administrator, or leave a comment so I or someone else can help.
Here’s a good primer for better understanding how file permissions work.
Man, I love analogies. Here’s another terrible one. If you’re a guard at a prison and it’s visiting hours, are you or are you not going to check that slimy guy’s subway sandwich before he hands it over to his incarcerated granny? She ain’t busy filing her nails for her health, ya know..
The point is that pesky hackers like to embed malicious surprises in otherwise innocuous looking files. For example, a file uploaded to your message board might look like an innocent enough image, but only when it’s executed do we find out that it’s some dangerous script masquerading as a picture of someone’s aloof Mexican Hairless cat.
Now most modern applications account for this sort of thing and put the necessary precautions in place, but it demonstrates that you should be certain your applications limit the types of files that can be uploaded. As a rule of thumb, the type of files your nerdy uncle taught you to never open in your email is the same sort of thing you don’t want on your server.
Shutting Down Uploads in PHP
Your website’s control panel may offer you the ability to manage your PHP integration. If your applications function in PHP and you have no reason to except uploaded files from your visitors, disable their ability to do so.
In cPanel, select Software > MultiPHP INI Editor > Basic Mode tab > Select your website in the drop down. Scroll down and make sure file_uploads is set to disabled.
In and of themselves, backups are a great thing … unless they’re the sort that sit on the bench (little pun for my sports bros). Of course you and/or your web hosting services provider should be backing up your website on a regular basis to ensure data integrity. But so far as web security concepts and procedures are concerned, backups can contain outdated applications with vulnerabilities.
To that end, make sure your backup(s) are stored outside of the web accessible (public) area of your website’s file structure. Let’s look at example directories where your web site is accessible from the Internet:
/home/your_account/www/ or /home/your_account/public_html/ or /home/your_account/www/backups/
Everything within /www/* (or /public_html/*) is accessible to the web. So your backups should be stored one level below:
/home/your_account/ or /home/your_account/backups/
Better yet, your backups should be stored locally on your own computer, at a cloud storage site like Dropbox, or handled automatically by your web host company and stored somewhere else entirely which alleviates this concern.
No, this isn’t about veterinarians and their penchant for poking tree-dwelling rodents with rabies shots.
SQL (pronounced sequel, not squirrel) injections are one of the oldest, most prevalent, and destructive application vulnerabilities where hackers hijack and piggyback poorly written code (typically in a web form or URL parameter). This method of attack allows hackers to inject their rogue code and wreck all sorts of havoc on websites leveraging SQL-based databases. When compromised, an intruder can do any number of things including:
If you’re not a programmer who keeps a trusty SQL Injection Cheat Sheet handy, now you know better and can broach the subject with your developers and ensure they are preventing this from happening through the use of parameterized queries. In the very least, you can see why its important to keep your applications updated so newly discovered vulnerabilities can be fixed and removed from the equation that formulates your greater peace of mind.
Similar in some ways to SQL injections, XSS attacks are accomplished by hackers embedding malicious payloads into your website’s JavaScript code. But the website is not the direct target of the attack. Instead, the attacker is going after your website’s unsuspecting visitors. Through modifications to your website’s code and a little social engineering, visitors to your site can fall victim to any of the following consequences without even knowing it:
Google Will Beat You Down
As you’re probably aware, Google crawls the web and once they become aware of the exploit code on your site, they’ll note its presence and take appropriate action. Considering this is an altogether nasty set of circumstances, Google goes so far as to warn visitors (and you) away from clicking on search results to infected sites. As you might guess, this isn’t conducive to maintaining a reputation on the up and up.
Curious? Use their Safe Browsing security checker to test your web site now.
Prevention
Protecting against these attacks requires that your website provide a web browser a set of instructions for how it should behave under certain data exchange circumstances. You do this by adding some combination of the following response headers to your website’s .htaccess file:
None are required, all can be helpful, and at worst some can cause your site to function erratically once added, but the top four should be strongly considered. Use this free security headers scanning tool to see which, if any, of these headers are currently in use on your website along with more information for how you can install them.
For more information, read up on the Content Security Policy (CSP) which is a series of techniques used against content injection attacks.
What About Your Web Host?
Yes, your web host can take the necessary steps to enable (some of) these headers for their hosted sites. If they do, you will see them enabled when you run the tool linked to above. Psyphire enables variations on the first four. Enabling all of them by default can lead to wide-spread compatibility issues, so we leave the rest up to the discretion of the individual webmaster. Many web hosts don’t utilize these to offer any protection at all.
Your website may look pristine now, but if your web host updates its hosting environment to make general application updates, your website could start throwing warnings or errors where visitors can see them.
Publicly displaying these messages gives would-be hackers and automated bots insight to your hosting environment and your website’s application vulnerabilities. Only leverage error messages outside of a production environment, or at the very most, when your web developers are busy at work making modifications to your web site. Better yet, show users only what they need to know and keep error messages in your logs. So, turn them off.
Disabling PHP Display Errors
These can be disabled in your control panel. For example, in cPanel, access Software > MultiPHP INI Editor. In the drop down box, select the PHP configuration for the website you wish to modify. Set display_errors to Disabled, then click Apply to save your settings.
If you can’t disable PHP errors in your control panel, do so by editing/creating the php.ini file with SSH/FTP or your control panel’s File Manager. The file is likely located in either of the following directories:
/home/yourdomain/php.ini
/home/yourdomain/www/php.ini or /home/yourdomain/public_html/php.ini
Add/edit the following line and save your changes:
display_errors = Off
If the line is already there, be sure to remove the “;” (semicolon) at the beginning of the line so that it becomes active and is processed.
If you wish to save errors to your error_log, be sure the following line exists:
log_errors = On
Your error_log is accessible from your control panel (cPanel > Metrics > Errors) and can also be found in one of the following locations:
/home/yourdomain/error_log /home/yourdomain/logs/error_log /home/yourdomain/www/error_log
(or a sub-directory where the error is occurring)
Are you securely sending and receiving those embarrassingly intimate emails between you and your dog? Edit your email settings to find out. If you’re communicating over any of the following ports, your email communications are NOT secure:
Drop by your email/web hosting providers web site for instructions explaining how to utilize their secure email services. Keep in mind that once you apply a SSL certificate to your own website, you can start securing your email transmissions to and from your email server over your own domain. The following ports are secured by encryption (SSL/TLS):
Keep in mind that you are only securing the connection between your computer and the one from which you retrieve your email. Your email can be intercepted if the recipients of your email (your dog) are not also using their own secure connection.
Outlook
Here is how you can access the port settings in Microsoft Outlook:
While this will set you on the right path, these exact settings may not work for everyone, so rely on the instructions from your email / web hosting provider to be sure.
You know those times when you’re filling out the contact form on your own website because you want so badly to feel like someone cares, try throwing in some malformed content, or leaving a required field blank. If the form notifies you of an error before you have submitted the form, this is client-side validation and, while arguably more user-friendly, it’s less secure if used by itself.
Forms that report errors after the data has been submitted are using server-side validation and this method is, by far, more secure and highly recommended.
Better yet, maximize user-friendliness and security by using both.
When creating user accounts within various applications for your employees/contractors/gardener, we recommend you provide permissions on a need-to-know basis. In other words, rather than give your blogging crew the keys to the kingdom with administrator rights, give them permissions to accomplish only what they need to. Do they really need access to customer invoices? No. So don’t give it to them.
Also ensure that all changes made within your secure applications are being tracked and logged by user account, so when something goes wrong, you’ll know who to blame.
Consider that throughout the world (er… basically, Russia, China, India, and Romania), there are an army of hackers who are programming an entourage of bots to test discovered instances of the most popular applications on the web to see if they are still using default settings.
When installing new web applications, one of the most powerful site security measures you can take is to change the default settings, for crying out loud. For example, changing the default path of the administrative directory for the installed application may stop 99% of attacks against that application because automated bots won’t be able to find the application in the expected default location. Instead of using /admin/, try /82lWN2sjD/ or /nIceTryLosErs/.
Pro Tip: Anywhere you allow user-generated content, ensure in the settings of your applications that any links they add to that content are marked as “nofollow.” This signals to search engines that you do not editorially vouch for sites that your users link to (including spammy or malicious web sites). A must if you don’t moderate user contributed content.
Review your web hosting service for this protective policy as a must-have security feature. This is particularly important if you are using “shared” hosting meaning you occupy the same server environment as a few hundred other customers. This, in and of itself, is not a bad thing, but if customers #9283 becomes the target of a cyber attack because he stood-up his hacker girlfriend on date night, your website will suffer as well. That is unless your web host effectively mitigates against these types of distributed attacks.
Say you run a bar. When drunk Joe starts mouthing off, your WAF bouncer grabs him by the collar and boots him to the curb. This layer of security leverages its 6’5 frame and dangling meat-hooks to monitor data exchanges between your server and the outside world … and steps in to stop any suspicious activity it detects (with a fury).
Your WAF bouncer guards against zero-day exploits, buffer overflows, session hijacking, and that nasty duo I mentioned earlier: SQL injections and cross-site scripting (XSS) attacks.
Again, an imperfect analogy from a half-cocked brain full of imperfect analogies, but know that your web hosting company should provide some level of firewall protection for your website. Check your web host’s package feature list.
This tactic is also put in place by your web hosting provider. At first glance, it might be annoying to realize that your hosting provider puts a limitation on the max allowable emails that you can send per hour. But this is good! See this as a feature of security rather than a limitation. It’s an indicator of a company that places a strong emphasis on precautionary security measures. You’ll be thankful should a hostile bot network guess your email password, start funneling thousands of spam from your email address to all four corners of the globe, and get your domain/IP address blacklisted (anyone with email should recognize this happens all the time).
I hear you saying that you need to send more email per day because you’re super popular or something. Listen, Don Juan, broach the subject with your web host and they’ll surely accommodate you if your needs are legitimate.
In the least, your web host should communicate that its own infrastructure is adequately protected against the threat of virus and malware. Sometimes this can be as simple as looking on their homepage for a “seal of protection.” No, not the sort that are dripping wet, bark a lot, and carry an assault rifle – but those offered by web security companies like SiteLock. When present, the SiteLock service will publish the rating and date showing when the web host’s own site was last scanned (preferably today’s date).
Keep in mind that as search engines crawl the web (Google, specifically) they scan websites for unsafe content and, if found, will either levy the ban hammer and remove the site from their search results or deliver a notice to visitors warning them that the site may contain unsafe content.
Pro Tip: To offer peace of mind and help avoid this potentially embarrassing event, quality web hosts will offer to extend optional malware/virus protection to their customers as an add-on service. Use Google’s Transparency Report to see if your site is clean.
Using SSH/FTP, or your control panel’s File Manager, acquaint yourself with your website’s primary configuration file as this is where additional security measures can be initiated. Popular web server files include:
Here are a couple helpful security articles for nginx and Microsoft IIS, but since I specialize in Apache, we’ll look specifically at the fun things we can do there, some of which can be manipulated by tools within your control panel.
Disable Access to .htaccess: Keep prying eyes out of this important file.
Order allow, deny Deny from all
Display Custom Error Pages: Direct visitors to specific pages of your choice when they get an error while accessing your site. This is a way to create custom pages that are more helpful to your visitors than default error pages which are generally anything but helpful.
ErrorDocument 400 /errors/400.html ErrorDocument 404 /errors/404.html ErrorDocument 500 /errors/500.html
Prevent Directory Browsing: This is important if you have directories on your site that do not have an index file (eg. index.html, index.php, etc.). When this is the case and your web host has taken no steps to protect you, people accessing those directories will see a list of files within that directory and gain greater insight to how your site operates behind-the-scenes.
Options All - Indexes
Prevent Image Hotlinking: This prohibits other websites from using images hosted on your site in their own pages. Sites that do this are effectively leeching your server resources and bandwidth. First stop the hotlinking:
RewriteEngine on
# You only need the above line in your .htaccess file once. This is a comment that is not processed by your server.
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)example.com/.*$ [NC]
RewriteRule \.(gif|jpg|jpeg|bmp|zip|rar|mp3|flv|swf|xml|php|png|css|pdf)$ - [F]
Next you can send alternative content to sites that hotlink your images, such as an advertisement for your company/services:
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)example.com/.*$ [NC]
RewriteRule \.(gif|jpg)$ http://www.example.com/company-advertisement.gif [R,L]
Disguise File Extensions: Doing so makes it more difficult for casual hackers to determine how your website is built and which vulnerabilities should be assessed.
# Disguise php files with .html extensions AddType application/x-httpd-html .php
Disable Server Signature: When your site delivers an error (e.g. 404, File Not Found), it also includes the server configuration information. The less information hackers have, the better.
ServerSignature Off
Protect Sensitive Files: Similar to blocking access to the .htaccess file, it’s worth repeating that this can be used for any sensitive files you have stored on your web site.
Order allow, deny Deny from all
You can block access to multiple sensitive file types with this:
<FilesMatch "\.(htaccess|htpasswd|ini|psd|log|sh)$"> Order allow, deny Deny from all
Block IPs or Domains: Maybe you want to block certain people from accessing your website. You can do so if you know what IP address or domain they are accessing your website from (information that can be located in your access_log and error_log):
Order allow, deny allow from all deny from xxx.xxx.xxx.xxx deny from .*domain\.com.*
Password Protect Files & Directories: Restrict access to certain files and directories to only those who have the required credentials.
# Protect a single file AuthType Basic AuthName "Mypassword" AuthUserFile /home/path/.htpasswd Require valid-user # Protect multiple files <FilesMatch "^(execute|index|myfile|anotherfile)*$"> AuthType Basic AuthName "Mypassword" AuthUserFile /home/path/.htpasswd Require valid-user
Disable PHP Execution: Disable PHP execution in a particular directory.
php_flag engine off
If you’ve made it this far and we’re nearly to the end, you still might be wondering where you should start. With a little old fashioned penetration testing, that’s where. Below is a list of the best software products, vendors, application programs and online tools – most are low cost or free to use.
Conclusion
Hackers are always looking for the next website of an uninformed small business owner where they can park their email spam relay, leverage resources to mine for bitcoins, propagate ransomware, add to their botnet, or perform any number of other illegal activities. Now that you’ve learned all of the ways you can determine the strength of your site’s security and how to secure a website from hackers, you have no excuse but to drop that Twinkie and find out if your livelihood is vulnerable.
As a responsible and intelligent business owner, it’s in your best interest to urgently leverage these security tips for websites by performing an assessment, or risk fending off the bots busting down your door with nothing other than a virtual can of mace (which is effectively yanking the door wide open). And that’s the very definition of insanity.
If during your audit you achieve even half of these basic and advanced techniques, you’ll be well on your way to less sleepless nights.
What other small business web security measures do you believe are essential?
View Comments
Amazing issues here. I'm very glad to see your article. Thanks so much and I am having a look forward to contact you.
Will you please drop me a mail?
Hi there,
I wanted to stop by and give my genuine feedback on your website. I really enjoyed to read your content, I think it's interesting and very well written. I've been on your website for an hour or so and very enjoyed it.
I didn't find your Instagram page though, do you have one?
Best,
Yalla
Good article and excellent way to articulate, keep it up
Awesome post! Keep up the great work! :)
Great content! Super high-quality! Keep it up! :)