Your website is your gateway to the world and at (many) times the entry vector to your network or customer database for a malicious actor. Just look at the last five years (Sony, TalkTalk & Equifax) and a large percentage of breaches started off with an attack listed within the OWASP Top Ten - namely SQL injection. Websites are complex and are made up of 1000s of files, and it only takes one flaw for someone to exploit the website thus exposing the backend database which should be for trusted employees only. Data exfiltration is not the only worry, uptime (the A in CIA [not Langley]) is another concern. If your website turns over hundreds of thousands of pounds daily, then it being offline for eight hours will lose you cash.
Patch patch patch
Why is patch written three times you may wonder? You need to patch the server & software, the core web application (maybe a CMS) and any plugins. Some CMS’s and operating systems (Linux) can download & patch themselves to some extent. Monitor all areas weekly and patch quickly. Subscribe to vulnerability emails for the products you use.
The top attack is SQL injection which lets an attacker query the database and even add records to it. XSS, CSRF and others are dangerous to for a different reason. Your web application, server and WAF needs to filter out bad strings. If a field is for a phone number, then A-Z or special characters are not at all needed. Do not just use your WAF to filter, do it at different layers.
Be conservative with error messages
Buildings do not shout out how many staff they have inside or what defences they have so your website does not need to either. Strip out any reference to what operating system or web application you are using. Errors should not say Joomla version 3.5 or Apache version 2.3. Such poor errors could give an attacker helpful snippets.
Pen test it
Before go-live have an unbiased expert 3rd party test your web application. That is not to have them run just a off the shelf tool you could do yourself but have them test it manually as well. Have them follow the OWASP Top 10 as any competent tester would. Do not let the whole exercise just be a top management tick box to move through your internal gating process. It should not be a one-off exercise but run on the whole website more than yearly.
Peer review or scan your code
Ask five people a question and you get five different point of views. Most coders are not security bods and most security bods are not coders. All code should be reviewed by 1-2 other coders to spoke flaws and ideally, they should understand secure coding. If you are a one-man coder then use a code scanner or outsource reviews.
TLS up your website
Many people will say use the HTTPS everywhere method but that is a rather high-level statement. You could turn on SSL v3 without knowing. You should be using TLS 1.2 without SHA1/RC4/3DES/CBC. Use the HSTS security header along with certificate pinning as well.
Turn on security headers
CSP, HSTS, XSS-Protection, X-Frame, Secure Cookie Flags and HPKP are just to name a few. These usually force the end user’s browser to do something. They can be injected at different levels: the web application, web server, WAF, load balancer and elsewhere.
Scan and filter file uploads
Uploaded files are bad for two reasons, 1. They could infect your web server and 2. They could infect your end users. You should filter files end users can upload, i.e. block .exe, .msi, .docm, .ps1 etc. Do not just rely on the file extension since these can be changed, look at the file headers. On top of this malware scan files and use more than just a single engine.
Block directory browsing
A school boy (or girl) error is to upload non-public files to a web server and then leave directory browsing on. Firstly, do not upload non-public files and anyway disable directory browsing so people cannot view the contents of a directory. HTACCESS has rules and/or stick in an index file as well.
Firewall non-essential ports
Web traffic is served over 80/TCP or 443/TCP for encrypted traffic (TLS). End users do not need to see or use anything else. The admin control panel (if you use a control panel – try not to) port and SSH or RDP should be locked down to the IP addresses of your corporate network.
“Encrypt” your passwords and more
The word encrypt has quotes round it for a reason. Encrypt means reversible but hashing is one-way encryption and cannot be technically reversed though due to pre-computation it kind of can. You should be using SHA-2 at minimum and ideally higher along with salting. On top of this you can use real encryption to but be careful where you store the encryption key – a HSM would be nice!
Change the defaults
As with anything if the default username is admin rename it, delete it or if you cannot, put two factor authentication on it. Go through all settings with a fine-tooth comb and tweak them. Many CMS’s use a default login directory like /administrator for Joomla, everyone knows it exists so stick a username/password on the whole directory.
Proper authentication and/or IP whitelisting
In 2017 people at large corporations were still rolling out externally facing websites or services with just a username (often to make it easy an email address) and password. Tonnes of flaws exist in this method. Avoid obvious usernames like email address or initialsurname, and use usernames with numbers in to. Two factor should be used to though it can be defeated so why not just IP filter the folder or username back to your corporate network?
As with a conventional folder or file on Windows it is not available to everyone nor everyone has full rights to it. Files and folders should have minimum permissions, and especially not 777 (full permissions) on everything. Block execution on files uploads to prevent them executing once uploaded. Chmod should apply to both public web directories and local server directories.
Be careful of 3rd party plugins
The core of Drupal, Wordpress or Joomla maybe “fairly” secure, well patched and vetted. 3rd party plugins are not vetted and could be insecure and/or not vetted. Just look into “vsftpd” which was backdoored. If you are going to use a 3rd party plugin research it’s history and manually review the code before you install it.
Vet your hosting provider
You could have the most secure website in the world but there is always a weak link in the chain. If you have your own dedicated standalone server great but shared hosting or a VPS means you share everything with tens or even thousands of other websites. A breach of one of them could leak over to your container or blacklist the whole IP address.
Use a web application firewall
A normal firewall is just interested in ports, protocols and the state (SPI) of the connection whereas a WAF is only interested in port 80/443. It can block known SQL injection attacks and filter known attacks against Joomla, Wordpress, Drupal and more. If you use one do configure it based on your setup not just leave the defaults on as many do. WAF’s on-premise or SaaS can help with DDoS mitigation though on-premise ones can get overloaded far easier.
Tweak your PHP settings
PHP, a massive programming language has 100s of functions and is controlled by a file called “php.ini”. Settings present are security and non-security focused. “shell_exec” and “system” along with many more can allow a shell to be executed. Even if an attacker managed to upload a PHP backdoor if you have the right functions turned off it would not execute.
Use a specialist website vulnerability scanner
If you are a small business and cannot afford up to £1200+VAT/day for a pen tester then you can use a website focused vulnerability scanner instead. These often cost the same price as a days testing and will last a year. The secret is pen testers use these tools! Have it scan all your pages and forms especially to find OWASP flaws before the attackers do.
Backup your website
You have spent days or months building your website and in a second you could delete a folder by error or have it defaced. Have a copy at the web host and on-site so all your eggs are not in one basket. Your backup should include the full set of files & directories plus whatever type of database you are using. If it is mission critical have it replicated and take snapshots multiple times per day.