You may not think your site has anything worth being hacked for, but websites are compromised all the time. The majority of website security breaches are not to steal your data or mess with your website layout, but instead attempts to use your server as an email relay for spam, or to set up a temporary web server, normally to serve files of an illegal nature. Other very common ways to abuse compromised machines include using your servers as part of a botnet, or to mine for Bitcoins. You could even be hit by ransomware.
Hacking is regularly performed by automated scripts written to scour the internet in an attempt to exploit known website security issues in software.
You’ve worked hard on your website (and your brand) – so take the time to protect it with these basic hacker protection tips! This article will also teach you how to check if a website is safe and what you can do to ensure your website protection from hackers
Keep Platforms & Scripts Up-To-Date
One of the best things you can do to protect your website from being hacked is to make sure any platforms or scripts you’ve installed are up-to-date. Because many of these tools are created as open-source software programs, their code is easily available – to both good-intentioned developers as well as malicious hackers. Hackers can pore over this code, looking for security vulnerabilities that allow them to take control of your website by exploiting any platform or script weaknesses.
It may seem obvious, but ensuring you keep all software up to date is vital in keeping your site secure. This applies to both the server operating system and any software you may be running on your website such as a CMS or forum. When website security holes are found in software, hackers are quick to attempt to abuse them.
Install Security Plugins, When Possible
Using WordPress as an example, you’ll want to look into free security plugins like iThemes Security and Bulletproof Security (or similar tools that are available for websites built on other content management systems). These products address the security vulnerabilities that are inherent in each platform, foiling additional types of hacking attempts that could threaten your website.
Use HTTPS
As a consumer, you may already know to always look for the green https in your browser bar any time you’ll be providing sensitive information to a website. Most consumers know to recognize those five little letters as an important shorthand for hacker security: they signal that it’s safe to provide financial information on that particular webpage. If you have an online store, or if any part of your website will require visitors to hand over sensitive information like a credit card number, you have to invest in an SSL certificate. The cost of an SSL certificate is minimal, but the extra level of encryption it offers to your customers goes a long way to making your website more secure and trustworthy.
Watch Out For SQL Injection
SQL injection attacks are when an attacker uses a web form field or URL parameter to gain access to or manipulate your database. When you use standard Transact SQL it is easy to unknowingly insert rogue code into your query that could be used to change tables, get information and delete data. You can easily prevent this by always using parameterised queries, most web languages have this feature and it is easy to implement.
Consider this query:
"SELECT * FROM table WHERE column = '" + parameter + "';"If an attacker changed the URL parameter to pass in ‘ or ‘1’=’1 this will cause the query to look like this:
"SELECT * FROM table WHERE column = '' OR '1'='1';"Since ‘1’ is equal to ‘1’ this will allow the attacker to add an additional query to the end of the SQL statement which will also be executed.
You could fix this query by explicitly parameterising it. For example, if you’re using MySQLi in PHP this should become:
$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));Protect Against XSS Attacks
Cross-site scripting (XSS) attacks inject malicious JavaScript into your pages, which then runs in the browsers of your users, and can change page content, or steal information to send back to the attacker. For example, if you show comments on a page without validation, then an attacker might submit comments containing script tags and JavaScript, which could run in every other user’s browser and steal their login cookie, allowing the attack to take control of the account of every user who viewed the comment. You need to ensure that users cannot inject active JavaScript content into your pages.
This is a particular concern in modern web applications, where pages are now built primarily from user content, and which in many cases generate HTML that’s then also interpreted by front-end frameworks like Angular and Ember. These frameworks provide many XSS protections, but mixing server and client rendering creates new and more complicated attack avenues too: not only is injecting JavaScript into the HTML effective, but you can also inject content that will run code by inserting Angular directives, or using Ember helpers.
The key here is to focus on how your user-generated content could escape the bounds you expect and be interpreted by the browser as something other that what you intended. This is similar to defending against SQL injection. When dynamically generating HTML, use functions that explicitly make the changes you’re looking for (e.g. use element.setAttribute and element.textContent, which will be automatically escaped by the browser, rather than setting element.innerHTML by hand), or use functions in your templating tool that automatically do appropriate escaping, rather than concatenating strings or setting raw HTML content. Another powerful tool in the XSS defender’s toolbox is Content Security Policy (CSP). CSP is a header your server can return which tells the browser to limit how and what JavaScript is executed in the page, for example to disallow running of any scripts not hosted on your domain, disallow inline JavaScript, or disable eval(). Mozilla has an excellent guide with some example configurations. This makes it harder for an attacker’s scripts to work, even if they can get them into your page.
Beware of Error Messages
Be careful with how much information you give away in your error messages. Provide only minimal errors to your users, to ensure they don’t leak secrets present on your server (e.g. API keys or database passwords). Don’t provide full exception details either, as these can make complex attacks like SQL injection far easier. Keep detailed errors in your server logs, and show users only the information they need.
Validate On Both Sides
Validation should always be done both on the browser and server side. The browser can catch simple failures like mandatory fields that are empty and when you enter text into a numbers only field. These can however be bypassed, and you should make sure you check for these validation and deeper validation server side as failing to do so could lead to malicious code or scripting code being inserted into the database or could cause undesirable results in your website.
Check your passwords
Everyone knows they should use complex passwords, but that doesn’t mean they always do. It is crucial to use strong passwords to your server and website admin area, but equally also important to insist on good password practices for your users to protect the security of their accounts. As much as users may not like it, enforcing password requirements such as a minimum of around eight characters, including an uppercase letter and number will help to protect their information in the long run.
Passwords should always be stored as encrypted values, preferably using a one way hashing algorithm such as SHA. Using this method means when you are authenticating users you are only ever comparing encrypted values. For extra website security it is a good idea to salt the passwords, using a new salt per password.In the event of someone hacking in and stealing your passwords, using hashed passwords could help damage limitation, as decrypting them is not possible. The best someone can do is a dictionary attack or brute force attack, essentially guessing every combination until it finds a match. When using salted passwords, the process of cracking a large number of passwords is even slower as every guess has to be hashed separately for every salt + password which is computationally very expensive.
Thankfully, many CMSes provide user management out of the box with a lot of these website security features built in, although some configuration or extra modules might be required to use salted passwords (pre Drupal 7) or to set the minimum password strength. If you are using .NET then it’s worth using membership providers as they are very configurable, provide inbuilt website security and include readymade controls for login and password reset.
Article References : https://www.hostgator.com https://www.creativebloq.com/
