Attackers are out there, constantly trying to exploit potential vulnerabilities in your website for malicious purposes.
Whether that’s attempting to brute force your admin password, or using automated tools and bots to try to exploit SQL or XSS vulnerabilities, almost all sites will face these issues at some point. Therefore, a properly secured website is a must.
Here’s how CynderHost high performance employs the newest techniques to keep your website from being compromised.
Weak usernames and passwords are the #1 reasons WordPress websites are compromised. Many users never change their default username from “admin” and use weak passwords that are easily brute-forced by bots.
By default, WordPress installs using our installer have unique usernames and strong passwords generated for them. If you are migrating your site from elsewhere, our one-click security settings can update your username to something else to help deter bots.
We also employed brute-force detection and automatic IP address banning using fail2ban. Should someone exceed a number of failed login attempts from 1 IP in the set amount of time, their IP address will temporarily be banned across all properties on our servers. This greatly decreases the effectiveness of brute-force attacks.
Outdated and vulnerable plugins or themes are also one of the largest attack surfaces for websites. Attackers usually gain access to a site using vulnerable application endpoints via injection attacks. We defend against this in two ways:
- All WordPress installs can be set to automatically update plugins, themes, and core to newer versions as they become available. This is one of the best ways to ensure you always have the latest security fixed and patches for your website.
- We use a web application firewall that automatically blocks malicious requests and is updated daily. This is very effective against vulnerable applications that have not been patched and can block zero-day vulnerabilities.
To demonstrate how the WAF works, we created an application with SQL injection and XSS vulnerabilities.
Disclaimer: All tests were conducted on websites owned by CynderHost. Do not attempt to replicate our tests on your own site, as it will results in your IP address being blacklisted temporarily and your site becoming inaccessible.
SQL injection vulnerabilities occur when un-escaped or validated strings make their way to database query statements and are able to modify the query to something else other than it’s intended purpose.
For example, let’s say we had the following line in our application, in order to get the contents of an article from the database:
Under normal circumstances, a valid article id will be passed in the ?id= query string, and an article will be returned.
https://badsite.com?id=1 becomes SELECT content FROM articles WHERE id = 3
Now, what if we pass the following value in the id parameter: 0 OR 1=1
The full url becomes https://badsite.com?id=0 OR 1=1, and the SQL statement becomes SELECT content FROM articles WHERE id = 0 OR 1 = 1.
Notice how the SQL statement now fetches articles where the ID is 0, or where 1 = 1, which is always true. This results in all the articles being fetched. If the hacker wanted to, they could then exploit to do something even more malicious, like dump the entire database, or gain access to a list of passwords.
Our demo site has the following SQL vulnerability
Normal requests return something like this:
Now, if we set the ?id parameter to 0 or 1=1, we get every single article in the database.
We can confirm this vulnerability using SQLMAP, a popular SQL injection auditing tool.
Now, what if we turn our WAF on?
We can confirm the attack was blocked in Apache’s logs:
We can also see SQLMAP no longer detects any vulnerabilities:
This means, should one of your installed plugins have a vulnerable endpoint, our WAF will block the request and prevent attackers from gaining access.
Another vulnerability that is common in applications is Cross Site Scripting attacks, or XSS. This is when unsanitized HTML or JavaScript code makes its when into the response body when it shouldn’t be there.
For example, if we had the following code in our application:
We’d be able to set the title with the ?title=TITLE parameter. Let’s say we used the following URL:
We’d get a page with a title that says:
With that in mind, we could embed any HTML code inside the page by putting it in the URL:
Would become:
I can also embed some JavaScript, and potentially use that to steal user credentials:
Let’s turn the WAF on again.
We can see all three XSS attempts were blocked by our WAF.
What does this mean?
This means you can sleep soundly at night, knowing that our WAF is constantly protecting from bots or humans trying to exploit and compromise your website via SQL, XSS, or even other vulnerabilities. That said, having a WAF does not mean you can ignore and neglect updating your site, following best practices, and using strong passwords.