The first thing to know about securing your website (and in my opinion, the most important thing) is that you are not doing this as an absolute guarantee against malicious attackers.
In the worst‐case scenario, their sites make their users’ Personally Identifiable Information (PII) become vulnerable due to cross site scripting.
What I’m saying is, the security that you enable for your website is more of a sieve than an umbrella. You can deflect big, obvious, and clumsy attacks — the kind comprising up to 97 percent of cyberattacks — but there will always be someone clever and subtle enough to penetrate your defenses. A good cyber‐defense will always include a plan for when (not if) your defenses fail.
That being said, here are some of the most common attacks against websites — cross site scripting, information leakage, and DDOS attacks — and how to deflect them.
Cross Site Scripting (XSS)
Cross‐site scripting is a dangerous problem to have. Unlike vandalism or a DDOS attack, cross‐site scripting attacks turn your website into a malware vector, and can compromise your users’ personal information.
A common example is this: let’s say that you have a contact form on your website.
Instead of putting in their name, email, and message, an attacker would write some arcane code‐string, and then hit the ‘submit’ button.
If you’re unlucky or un‐careful, that string of code then worms its way into your website’s database — it becomes a part of your site.
When a user visits your site, their browser renders all of your content right alongside the attacker’s code. This allows the attacker to do things like record every single one of the user’s keystrokes, thus eventually capturing their username, password, SSN, credit card numbers, and so on.
How do you defend against cross‐site scripting?
Much has been written on the subject of preventing cross‐site scripting, and the good news is that it doesn’t require buying an expensive security solution.
Your website developer can bake in protection against XSS as they build or modify your site.
Essentially, you need to treat all user input into your site as ‘untrusted.’ It could be someone genuinely reaching out to you, or it could be malicious code.
Therefore, this data needs to be encoded, or transformed into the sort of text that doesn’t render in a browser, before being added to your database.
For example, a user might put a comment on your site consisting of some text between these two characters: <text>.
Unfortunately ‘<’ and ‘>’ usually mean <executable code goes here> in HTML — it could be a trap!
With encoding, ‘<’ and ‘>’ get transformed into ‘<’ and ‘>’ — which are gibberish to both you and your HTML renderer.
If you’re in search of more information, OWASP has put together a comprehensive cheat sheet for preventing XSS.
There are also companies who will, for a fee, scan your website for XSS vulnerabilities — which aren’t all as obvious as an unprotected comment‐box — and suggest remediation.
This is one of the most common causes of attacks against websites, and it isn’t even based on a specific software vulnerability.
Do me a favor — when you’re reading this on a desktop, quickly hit F12 on your keyboard. If that doesn’t work, you may need to right‐click and hit ‘view source.’ Either way, you’ll end up seeing something like this:
You probably already know what this is, if you’re a developer — it’s the HTML source code for a given webpage. You also know that as you develop a page or a web application, you’re likely to leave comments in that code, indicating the presence of a bug, for example.
Here’s the million‐dollar question:
Do you always take those comments out once the page goes live?
This is where information leakage lives: in the leftovers from the software development cycle.
Leftover comments from the dev process can reveal things like server configuration, software version numbers, exploitable bugs, and so on — all things that an attacker would be happy to exploit.
Of course, the solution is head‐breakingly simple: don’t do this.
That’s an easy answer in theory, but in practice, software developers routinely work 80‐hour weeks in order to get products out the door. Mistakes get made.
In an environment where time‐to‐market is rewarded above all else, security very often goes by the wayside.
If you’re having your webpage developed by a third party, it may be best to have a penetration tester take a look at your finished page in order to sniff out these and other insecurities.
Distributed Denial of Service Attacks (DDOS)
I’ve written extensively about DDOS attacks in the past, and they are the worst.
They work on the principle that it’s very easy to crash a website by sending a lot of illegitimate web traffic to it at the same time.
A single user can generate a DDOS attack by spamming DNS traffic. Other times, a hacker uses one or more infected computers that are being controlled remotely in order to accomplish the same task.
A lot of companies pay up.
After all, what’s easier to give up — $10,000, or several days’ worth of revenue?
Unlike the attacks mentioned above, you might not be able to secure your website against DDOS attacks with sensible development practices alone.
You can, however, mitigate these attacks.
The first step is to monitor your DNS server using its built‐in software (usually BIND). If traffic is higher than normal, then you might be in trouble.
If you suspect you may be vulnerable to a DDOS attack, your next step might be to adjust the volume of queries your servers can handle.
This takes money, so the extent by which you provision your servers should take the form of a cost‐benefit analysis.
Lastly, a tool called Anycast allows users to host servers using the same IP address across multiple locations.
If an attacker attacks your server in one location, you can use this tool to route traffic to servers in other parts of the world, allowing most legitimate users to query your site without experiencing latency issues.
Many of you reading this will have blogs or websites on the WordPress platform. WordPress sites are pretty much vulnerable to the same types of attacks seen above.
For example, the company recently released a patch to fix a vulnerability that made its millions of users vulnerable to cross‐site scripting.
Hopefully, for most of you, the biggest security threat you’ll ever have to worry about will be the occasional spam comment.
A lot of basic security revolves around keeping the WordPress client up to date. The organization is commendably bullish on security, and constantly released automatic updates that increase security for the everyday user.
That being said, updating the core WordPress software won’t protect you if you use an insecure custom theme.
Assuming your theme is secure, hackers might be able to steal your login credentials by attacking the computer(s) you use to control and edit your site. If you run a firewall and antivirus (for home users) or enterprise‐level system monitoring, you’ll mitigate this risk.
There are plugins that purport to offer the full suite of security services, including a firewall, intrusion detection, and error‐logging.
I’ll say about this what I say about all security tools — simply having it on your system is not going to make you any safer. You need to use it, understand what it’s telling you, identify a baseline that represents ordinary traffic on your site, and only then will you be able to understand if you’re coming under attack.
VPNs as a Component of Website Security
Most of us think about VPNs as a way to get around the restrictions on region‐locked videos, or as a way to log in securely to your company’s intranet while abroad.
If your website provides things like cloud‐hosted software or data, VPN is also very important to have.
This secure connection prevents bad actors from listening in while someone is accessing resources that you want to place security around — credit card numbers, health records, and other PII. However, if you have a VPN portal on your website, you need to take some important steps to make sure that the portal is secure.
Securethoughts.com has a fairly comprehensive list of VPN services on offer, with accompanying reviews.
TLS, not SSL
Due to an exploit called POODLE (very similar to Heartbleed), SSL VPN is in fact obsolete. If your VPN portal still uses SSL, your visitors might see that as a red flag.
The secure replacement for SSL is Transport Layer Security (TLS). This is the one you want to use. It’s important to note that for the sake of familiarity, many security professionals call TLS by the old, incorrect name of SSL — this can get confusing. You’ll also want to be sure that you’re using the latest version of TLS, as it offers significant improvements over the original.
When All Else Fails
As I’ve explained, most of the common attacks against websites can be deflected by using practices that don’t require expensive tools.
There is, however, always the possibility that black‐hats will get the better of you.
The good news is that responding to the breach efficiently will reduce your overall costs, and restrain customers from departing your business.
For example, in response to its 2014 breach, Evernote fully detailed what was taken, reset all its customers’ passwords, and sent out prompt and comprehensive notifications.
The company was generally lauded for exercising transparency and an abundance of caution.
My best advice is this: invest intelligently in security. Use sound practices, and well trained employees, while minimizing your reliance on tools.
You may not be able to deflect every attack every time, but when the hammer finally drops, no one should be able to say that you weren’t prepared.