How to keep your domain name safe against hackers

How to keep your domain name safe from hackers

The short guide for Domain Security

Keep all your web accounts, secure with hard to guess passwords. Add authentication of 2 steps where possible and never provide your domain account information to anyone.
Use anti-virus and spyware keylogging software measures to prevent the capture of your login details and ensure your domain and data from malware.
Keep your domain contact information updated with his secretary; it is the best way to ensure that you can be contacted if there is any suspicious activity in your account.
Follow when your domains must be renewed and be aware of the renewal process. Set a reminder to avoid registration expires and be signed by someone else.
Add Domain to maintain the privacy of your contact information outside of the public domain. Thieves can use this information to impersonate you or fool you to access your domain.
Provide an additional level of security for your domain with a registry blocking service. This prevents someone from transfer your domain without your permission.
Be vigilant with your emails to avoid a phishing attack. Hackers can send by e-mail claiming to be his secretary and an email like this can contain a link to a replicate site where you enter your information to capture.
Secure your website with SSL certificates, enable DNSSEC for extra protection and add a firewall to prevent unauthorized access. Choose a reliable host, good security practices of the server, such as regular updates, and use a VPS to be more secure.

9 safety tips to protect your website from hackers

You may not think your site has nothing worth being hacked, but websites are in danger all the time. The majority of security breaches on websites are not to steal your data or fiddle with the site design, but you are trying to use your server as a relay of spam mail or set up a temporary web server, usually to serve files from the illegal character. Other forms of abuse very common compromised machines include the use of its servers as part of a botnet or removal of Bitcoins. You might even be beaten by RANSOMWARE.

Piracy is usually done using automated scripts written for scouring the internet in an attempt to exploit websites known security problems in the software. Here are our first nine tips to help you and your website safely online.

01. Keep the software up-to-date

It may seem obvious, but making sure to keep all the updated software is vital to maintaining your site secure. This applies both to the server operating system and any software that can run on your site as a CMS or forum. When the security holes in websites are found in the software, hackers are quick to try to abuse them.

If you are using a managed hosting solution, then you won't have to worry too much about applying security updates for the operating system as the hosting company should deal with this.

If you are using third-party software on your website as a CMS or forum, you must make sure that they are quick to apply security patches. Most of the providers have a mailing list or RSS detailing any website security problems. WordPress, Umbraco, and many other CMSes inform you of system updates are available when you log in.

Many developers use tools such as composer, NGP, RubyGems or to manage your units and software security vulnerabilities that appear in a package that depends on but are not paying attention to is one of the easiest ways of getting caught. Be sure to keep their units to date, and the use of tools such as Gemnasium for automatic notification when it announces a vulnerability in one of its components.

02. Look out for SQL injection

SQL injection attacks are when an attacker uses a web form or URL parameter to access or manipulate the database. When you use Transact SQL standard is easy to insert malicious code into an inquiry that could be used to modify tables, obtain information and delete data. You can easily avoid this by always using parameterized queries, most languages of the web have this feature and is easy to implement.

Consider this query:

"SELECT * FROM table WHERE column = '" + Parameter + ";"
If an attacker has 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';"
From '1' is equal to '1' This will allow the attacker to add an additional query at the end of the SQL statement that will be executed.

You can fix this query explicitly by using the parameterization. For example, if you're using MySQLi in PHP this should be:

$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value");
$stmt->execute(array('value' => $parameter);

03. Protection against XSS attacks

Cross-site scripting (XSS) attacks to inject malicious JavaScript code on your pages, which then runs on users' web browsers, and can change the contents of the page, or steal information to send back to the attacker. For example, if you display comments on a page without validation, then an attacker could send comments containing script tags and JavaScript, that could work in any other user's browser and steal your login cookie, allowing the attack to take control of each user's account that visualized the comment. You need to make sure that users might not be able to inject Please enable JavaScript in your pages of content.

This is a particular problem in modern web applications, where the pages are constructed mainly of user content, and that in many cases generate HTML code that then also interpreted by marcos as front-end angular and Ember. These frameworks provide many protections XSS, but a mixture of server and client processing creates new and more complex attack paths too: not only is to inject JavaScript into the HTML that is effective, but can also be injected the content that is going to run the code by inserting directives or angle of Ember helpers.

The key here is to focus on how user-generated content could escape the limits that you expect and be interpreted by the browser as something more than what is intended. This is similar to the defense against SQL injection. When the dynamic generation of HTML, using the functions that are explicitly set the changes that you are looking for (for example, using the element.setAttribute and element.textContent, which will automatically be escaped by the browser, instead of setting element.innerHTML to hand), or use functions in your templates that automatically perform the appropriate tool to escape, instead of concatenating strings or configuration of raw HTML content.

Another powerful tool in the toolbox on the ombudsman XSS is Content Security Policy (CSP). CSP is a header your server may return that tells the browser to limit and how it executes JavaScript on the page, for example, to prevent the execution of scripts are not hosted on your domain, disable JavaScript in line, or disable eval(). Mozilla has an excellent guide with some example configurations. This makes it more difficult for an attacker to scripts for their work, even if you can get on your page.

04. Be wary of the error messages

Be careful with the amount of information you give away in error messages. They provide only minimal errors to users and to ensure that do not drip secrets present in the server (e.g. API of the database or passwords). Do not provide exception details complete, since these can perform complex SQL injection attacks as much easier. Keep detailed errors in server logs, and only show users the information they need.

05. Validate on both sides

The validation should always be performed in both browser and server. The browser can catch simple errors such as mandatory fields that are empty and when you type text in a field of numbers only. These can, however, be excluded, and you must ensure that you check these validations and deepen the server-side validation as failure to do so could lead to malicious code or scripting code is inserted in the database, or could lead to undesired results in your website.

06. Check your passwords

Everyone knows that must use complex passwords, but that does not mean that they always do. It is essential to use strong passwords for your server and the website administration area, but also equally important to insist on good practices of passwords for users to protect the security of your accounts.

As much as users cannot approve of, compliance with password requirements as a minimum of eight characters, including a capital letter and a number will help protect your information over the long term.

Passwords should always be stored as coded values, preferably using a one-way hash algorithm such as SHA. Using this method means that when you are authenticating users who only compare values encrypted. For greater security on the website is a good idea to salt the passwords, using a new salt per password.

In the case of hacking in someone and steal your passwords, using hash passwords could help to limit the damage, such as deciphering is not possible. The best thing someone can do is a dictionary attack or brute force attack, essentially guessing each combination until it finds a match. When you are using passwords, crackers, the process of cracking of a large number of passwords is even slower as all I guess you have to have a hash algorithm separately for each salt + password that is computationally very costly.

Fortunately, many CMSes offer users management out of the box with a lot of these security features integrated Web, although some additional configuration modules or it may be necessary to use salted passwords (pre Drupal 7) or to set the minimum strength of the password. If you are using .NET then it is worth to use membership providers, since they are very configurable, providing security of built-in web site and include controls ready to log in and password reset.

07. Avoid charges of files

Allow users to upload files to your website can be a big security risk in websites, even if it is only to change your avatar. The risk is that any uploaded file, however innocent it may seem, could contain a script that when running on the server, completely open your website.

If you have a submission form of a file, then you need to treat all files with great suspicion. If you allow users to upload images, cannot depend on the file extension or mime type to check to see if the file is an image like these can easily be simulated. Even open the file and read the header, or the use of functions to control the size of the image is not infallible. Most of the picture formats allow you to store a section of reviews that may contain PHP code that could be executed by the server.

So, what can be done to prevent it? Ultimately, you want to stop users from being able to run any file that is uploaded. By default, the web servers will not attempt to execute files with extensions of images, but do not rely exclusively on the control of the file extension as a file with the name of image.jpg.php has been known to get through.

Some options to change the name of the file to upload to ensure the correct file extension or to change the permissions of the file, for example, chmod 0666 so that it cannot be executed. If you are using *nix, you can create a .htaccess file (see below) that only allows access to files or prevent the attack of double extension mentioned above.

Deny All
    <Files ~ "^\w+\.(gif|jpe?g|png)$">
    Order Deny, Allow
     To allow all
    </Files>
Advertisement
Ultimately, the recommended solution is to prevent direct access to uploaded files completely. In this way, all files uploaded to your website are stored in a folder outside of the webroot or in the database as a blob. If the files are not accessible directly, you will need to create a script to retrieve the files from the private folder (or an HTTP handler in the .NET) and send them to the browser. The image tags support an src attribute that is not a direct URL to an image, so its src attribute can point to your script file delivery offering properly adjust the content type in the HTTP header. For example:

<img src="/imageDelivery.php?id=1234" />
 
<?php
      // ImageDelivery.php
 
      // Get image file name from a database based on $_GET["id"]
      ...
 
      // Provide picture browser
       Header('Content-Type: image/gif');
      Readfile('images/".$name);
 
?>
Most hosting providers to deal with the server configuration for you, but if you are going to host your website on your own server, then there are some things that you will want to check.

Make sure you have a firewall configuration and are blocking all ports not essential. If it is possible to set up a DMZ (Demilitarized Zone) that allows access only to the ports 80 and 443 from the outside world. Although this may not be possible if you do not have access to your server on an internal network, you would have to open ports to allow the uploading of files and the log remotely to your server via SSH or RDP.

If you allow that you can upload files from the Internet only use methods of safe transport to your server as SFTP or SSH.

If it is possible to have your database running on a separate server from your web server. This means that the database server can be accessed directly from the outside world, only your web server can access it, minimizing the risk that their data are exposed.

Finally, don't forget to restrict physical access to your server.

08. The use of HTTPS

HTTPS is a protocol used to provide security via the Internet. HTTPS ensures that users are talking to the server that they expect and that no one can intercept or change the content that you are viewing in transit.

If you have anything that users want to private, it is highly recommended to only use HTTPS to deliver it. Of course, this means that the credit card and the login pages (and the URLs that are subject to) but usually much more than your site too. A login form is usually set a cookie, for example, that is sent with each request to the site that a logged-on user does, and is used to authenticate requests. An attacker to steal this would be able to perfectly imitate a user and take control of your session. To defeat this type of attacks, almost always want to use HTTPS to the entire site.

That is no longer as difficult or expensive as it once was. We are going to encrypt provides totally free and automated certificate, you will need to enable HTTPS, and there are community tools available for a wide range of common platforms and frameworks to configure this automatically for you.

In particular, Google has announced that they will impel you upwards in the search rankings if you use HTTPS, giving a benefit SEO too. HTTP is insecure in their way out, and now is the time to upgrade.

Already using HTTPS everywhere? Go beyond and look to configure HTTP Strict Transport Security (194), ahead of easy you can add to your responses from the server to disable HTTP unsafe for the entire domain.

09. Get web security tools

Once you think you have done all you can then it is time to test the safety of the website. The most effective way to do this is by using some tools of security of websites, often cited as proof of penetration or pen for short quizzes.

There are many commercial and free products to help you with this. Work similarly to the scripts of hackers in the sense that proves you all know explodes and the attempt to compromise your site using some of the above-mentioned methods such as SQL injection.

Some free tools that are worth looking into:

Netsparker (Free Community Edition and the trial version available). It is good to test SQL injection and XSS

OpenVAS claims to be the most advanced security scanner open source. It is good to test for known vulnerabilities, is currently analyzing more than 25,000. But it can be difficult to set up and requires a server that will install OpenVAS which only runs on *nix. OpenVAS is a fork of Nessus before it became a commercial product of closed source.

SecurityHeaders.io (free online check). A quick tool report that security headers mentioned above (194) as CSP and a domain has enabled and configured correctly.

 Xenotix XSS Exploit a useful framework of OWASP (Open Web Application Security Project), which includes a huge selection of examples of XSS attack, you can run to quickly confirm if your site of inputs is vulnerable in Chrome, Firefox, and IE.

The results of the automated tests can be enormous, as they present a wealth of potential problems. What is important is to focus on the critical issues in the first place. Each item reported normally comes with a good explanation of the potential vulnerability. You will probably find that some of the issues of medium/low are not a concern for your site.

There are some steps you can take to try to compromise your site manually modifying values GET/POST. A debugging proxy can help you here as it allows you to intercept the values of an HTTP request between the browser and server. A popular freeware application called Fiddler is a good starting point.

So what should you be trying to alter in the application? If you have pages that should only be visible to a user connected and then try changing URL parameters such as user id, or cookie values in an attempt to view the details of another user. Another area worth trying is forms, by changing the values POST to try to send the code to perform XSS or load a script on the server side.