Simple Methods of Adding SSL to Your WordPress Website

SSL WORDPRESS

People choose SSL mostly because it provides more secure information and gives more benefits, especially from a user’s perspective, as any information they share with your site via a form, shopping cart, etc. is encrypted – it is safe from the third party. However, few web developers that know the very same principles also apply to site administrators.

In fact, running the WordPress admin in https also brings huge benefit, since you can secure all the sensitive information you input daily inside of WordPress. All of this information needs protection; therefore, it is essential for every WordPress website out there to renew the certificate in every three months.

If you are in a tight budget, you can opt on the market for low-cost certificates that do the job nicely in most cases. Remember that ecommerce sites might be better off with higher level certificates that offer features like identity validation which allows customer to know you better.

This makes us have no reason for not giving a little time and money to understand and apply an SSL certificate. So, if you are committed to integrating SSL with a WordPress installation, now it’s time to discover the ways.

HTTPS Your WordPress

Before, we setup WordPress to utilize an HTTPS connection; you have to make sure that you already have an SSL certificate installed on your server. Actually, it is quite simple to setup WordPress to utilize an https connection, as follows:

  • Back up the site
  • Change the Site URL
  • Ensure all internal links and attachments use https
  • Run the WordPress admin in https
  • Automatically forward http requests to https

Change the Site URL

First, navigate over to settings > General inside the WordPress administration area since you’ll want to change the WordPress Address (URL) and Site Address (URL) from ‘http://www.yourdomain.com’ to ‘https://www.yourdomain.com’. Scroll down to the bottom and save the changes when you’re done and then, WordPress will automatically log you out. If you want to log back, you can use the newly-secured URL.

Make Sure All Internal Links/Attachments Use HTTPS

Even though you change the URL, image or attachment URL throughout WordPress, it will not suddenly switch your website into HTTPS. In order to discover ways to change the URL site, you can conduct a search and replace area of your database. One thing for sure, you need to back up your site to prevent anything from going wrong.

Nowadays, you can find many searches and replace plugins available for WordPress, but you can give a try to Velvet Blues Update URLs, as it can be an effective solution. Furthermore, this plugin only touches the areas of the database that need changes, so you will not mistakenly change the right thing. In fact, you can update URLs to get started once you’ve installed and activated the plugin, head over to tools > Update URLs to get started.

Don’t worry as using plugin is as simple as adding the old and new URLs for your site. All you need to do is make sure that all the settings look are correct then click “Update URLs Now” when you’re ready and let the plugin take care of the rest. You’ll see a report on the screen that says how many URLs are changed and where the plugin found them, once the URLs have been replaced.

Run the WordPress Admin in HTTPS

In order to ensure that there will be HTTPS in the WordPress back end, you should grab the latest version of your site’s wp-config.php file and add the following line just above “/* That’s all, stop editing! Happy blogging. */”:


Now, you can save and upload the file to your server.

Automatically Forward http Requests to Https

The last step is to make sure that you only use https URLs for your site. First, you need to download the latest copy of your site’s .htaccess file and add the following just underneath the line “RewriteEngine On”:

Then save and upload the file to your server. You can try and enter an http URL for your site in a browser to test it. If you do it right, it should automatically forward you to the https version. Bear in mind that every server has been set up differently, so you should find other ways to make this work. Feel free to contact your web host for suggestions.

Troubleshooting a ‘Broken’ Lock

Discover if there are any broken padlock icons in your browser’s address bar and/or mixed content warnings. If you find any, then something is trying to load in from an http address. Usually, it is caused by a script or other outside resource being called from your site’s theme or CSS. As a solution, you can refresh the page and see if that clears up the issue.

If the problem is still going on, you can visit “Why No Padlock?” and input your URL that you want to analyze. The site will scan and analyze it for you.

Conclusion

Keeping user’s information private is an important thing, especially if you are doing a business in digital world. By seeing the green padlock in your site’s address, users will think that your business takes their personal information seriously. This will surely increase their trust and interest to buy something from you or even fill out a simple contact form.

Predictions of IPv6 in 2017

IPv6-Predictions-for-2017_ywf

If you are a web developer, you might have  an experience with IPv6. You might find it either enticing or loathing at the same time. However, many developers discover that 2016 is a great year for IPv6, so it is no longer ramp-up, as using IPv6 advocates have often been frustrating by the pace of adoption. The good news for us was that 2016 was a really great year for IPv6. To discover how many changes that you can find in this new IPv6, you can take a look on the information below:

In a similar format to our IPv6 predictions for 2016, we are simply stating what we think will happen.

  1. The majority of container solutions (Docker, Kubernetes, Mesos) will have IPv6 support by the end of 2017
  2. IPv6 growth worldwide will, again, outpace the US
  3. Major private cloud solutions (OpenStack, AzureStack, VMware) will have production ready IPv6 support
  4. Security will finally start figuring out IPv6
  5. Early IPv6-only data center solutions will start happening

It is predicted in 2017; there will be more developers adopting IPv6 at a faster rate as containers and those that have solutions around containers will continue seeing the massive growth. Containers will become the next generation of operator platforms replacing VMware vCenter or OpenStack Horizon. Many developers believe that this is the solution to run and operate with IPv4 and/or IPv6. It is because more than 33% of native IPv6 services (mainly due to mobile operators) and the rate will grow steadily over 2017. However, since there are still so many countries outside the US which have not had high adoption rates, they have a much higher initial deployment growth curve to leverage. A massive deployment of IPv6 will appear almost overnight, when a single service provider enabling IPv6 for a country. Moreover, other countries, such as China or Russia are also poised to do just that in 2017.

As more and more customers determine that an all-in public cloud strategy does not address all their business requirements or concerns,  you will see an uptick in hybrid-cloud solutions that will require deployment of private clouds. To allow low friction utilization of both public and private clouds, these private clouds will have to be as tightly integrated with their public cloud counterparts. Some of us may have noticed that both AWS and Azure have native IPv6 capabilities and hopefully, Google will be the same.

Furthermore, you will not only see IPv6 specific capabilities within security product portfolio, but also event correlation and matching for dual-stack hosts. Therefore, it is important to understand the relationship between IPv4 and IPv6 and what kinds of features or events are happening. In the end, developers will no longer opt to turn off IPv6 as the standard request from IT security and gain skill and insight into what IPv6 is doing. As a result, stakeholders will become more common with what IPv6 is doing. In fact, the craziest prediction is that many big companies will take a serious look into the option of doing an IPv6-only solution to meet their primary customer needs. To keep providing resources for an IPV4-only host, developers may adopt protocol conversion or proxy functions for IPv4 with IPv6. In addition, compared with a dual-stack, it will be far more cost-effective to deploy and operate a new data center with IPv6

In conclusion, IPv6 will surely become an important part of data center story in 2017. Others, like cloud, containers and global adoption will end up as the big IPv6 stories.

 

Introduction of Cross-Site Scripting (XSS) Vulnerability & How to Prevent It?

What is the Cross-site Scripting (XSS) Vulnerability & How to Prevent it

As a web developer, you may know XSS as Cross-site Scripting. It is a way of bypassing the SOP concept. An attacker could easily insert his own HTML code whenever HTML code is generated dynamically, and the user input is not sanitized and is reflected on the page. In this case, the web browser will still display the user’s code since it belongs to the website where it is injected.

The attacker could easily interject JavaScript code which would run under the site’s context. By this way, the attacker can access other pages on the same domain and read data like CSRF-Tokens or the set cookies.

The attacker can use the cookies which typically contain session identifier information, and use it in his own browser and login to the web application as the victim. Another way is by reading private information from the pages, such as read CSRF tokens and makes requests on behalf of the user.

Impacts of the Cross-site Scripting Vulnerability

There are many impacts of an exploited XSS vulnerability. It ranges from Session Hijacking to the disclosure of sensitive data, CSRF attacks and more. The attacker can impersonate the victim and take over the account by exploiting a cross-site scripting vulnerability. It might even lead to code execution on the server if the victim has administrative rights. But it will depend on the application and the privileges of the account. To get more information on how a XSS vulnerability was used in a successful attack can read about the apache.org jira incident .

Preventing XSS Vulnerabilities

The most important thing in preventing cross-site scripting vulnerabilities is to apply a context dependent output encoding. In some cases it might be enough to encode the HTML special characters, such as opening and closing tags. In other cases, URL encoding is necessary if it is correctly applied.

Moreover, your inbuilt XSS filter, even in your most modern web browsers should not be seen as an alternative to sanitization. However, they cannot catch all kinds of cross-site scripting attacks. As a result, this will prevent some pages from loading correctly. Since the idea is to minimize the impact of existing vulnerabilities, a web browser’s XSS filter should only be a “second line of defense”.