On his site Sameer Borate gives you a quick tutorial on how to migrate your WordPress site to HTTPS to help secure the communications between it and your users.

Finally, after much deliberation, I decided to move my blog to https. For the past few months I had encountered articles pointing that google gives a higher ranking for sites served over https. I had decided against https as I was afraid it may slow down by blog. However, the [a message about Chrome's HTTP/HTTPS support] from google forced me to take the issue seriously and finally move to https.

[...] Luckily during the same time Godaddy was offering SSL certificates at a discounted price. So taking this as a sign I bought the SSL certificate and moved my blog to HTTPS. Surprisingly installing SSL on Godaddy was a breeze. There was no configuration involved and the SSL certificate was applied within a few minutes.

He assumes that you know how to get the certificate installed, so that part isn't covered. He does cover the shift of the WordPress site over including changes that'll need to be made to web server and WordPress application configurations. He ends the post briefly talking about any speed difference he saw with the site (hint: not much).

In a recent post to his site Aidan Woods shares information (and code) related to the use of secure headers in PHP applications. He's even created a package to help make it easier to drop them into a new or existing project without too much trouble.

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP. By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project. The project, SecureHeaders is available on GitHub.

He starts by covering why he created the library and what it can help you with including making things like a CSP policy easier to maintain. The article goes on to talk about the Content-Security-Policy header is and what kind of prevention it applies. He also shares how the package displays errors, modifies cookies to secure them (HTTPOnly and Secure flags) as well as provide a "safe mode" that "place an upper limit on things like HSTS and HPKP, and remove flags like includeSubDomains or preload until the header is manually added as a safe mode exception, or safe mode is disabled."

Stoyan Stefanov has written up a post sharing the process he followed to migrate a WordPress blog to HTTPS on the Dreamhost hosting service.

Now some folks reminded me recently that the Perf calendar was not yet migrated to HTTPS... True enough. I have to do it. Eventually. In any normal situation I'll procrastinate indefinitely, but since I had more pressing things to do and "Anyone can do any amount of work, provided it isn’t the work he is supposed to be doing at that moment"... I bit the bullet.

Below are the steps that worked for me with a WordPress blog, hosted on DreamHost. The steps are still relevant to any WordPress site, just using Dreamhost as an example and since Dreamhost makes many of the steps easy.

He breaks the process down into six parts, including a bit of testing at the end:

• Setup free SSL certificate thanks to Let's Encrypt
• Backup all the things (or just the blog's database or just the table with the posts)
• Search and replace internal references (images and links) WP settings
• Redirect http to https permanently in .htaccess
• Test/tweak?

Each step comes with the code or configuration you'll need to set up HTTPS and some screenshots where necessary, like with the Let's Encrypt setup.

The Paragon Initiative has posted a new tutorial giving you a pocket guide version to securing your PHP application in 2016.

Please set aside most of what you've heard over the years; chances are, most of it just muddies the water. Security is not a product. Security is not a checklist. Security is not an absolute.

Security is a process. Security is an emergent property of a mature mindset in the face of risk.

Perfect security is not possible, but attackers do have budgets. If you raise the cost of attacking a system (your application or the networking infrastructure it depends on) so high that the entities that would be interested in defeating your security are incredibly unlikely to succeed, you'll be incredibly unlikely to be compromised.

The post talks about the "essence of security" and how most prevention methods don't even add much processing overhead or overall development time. He makes four recommendations of things to do in current and future development to help secure your applications:

• Use PHP 7 in All New Development
• Use HTTPS Everywhere
• Use Security Headers
• Use Trustworthy Reference Material

The post ends with a few other things to think about when building secure applications including raising the "cost" of attacking your system and keeping in mind that your platform may not be the attacker's "end game".

There's always been an issue with the creation of Phar packages in PHP and the security around them. There's been recommendations about creating signatures and only using secure connections for updates and rollbacks. Unfortunately there isn't an overly easy way to handle this yet. However, Matthew Weier O'Phinney has written up a post showing his workflow for doing these kinds of things, making use of the Box project to help with some of the more detailed parts.

For a variety of reasons, I've been working on a utility that is best distributed via PHAR file. As has been noted by others (archive.is link, due to lack of availability of original site), PHAR distribution, while useful, is not without security concerns, and I decided to investigate how to securely create, distribute, and update PHAR utilities as part of this exercise.

This is an account of my journey, as well as concrete steps you can take to secure your own PHAR downloads.

He starts by outlining the "roadmap" of the features he wants to include and the steps to take to create this more secure phar archive. It includes the use of both current, local tools and services (like Box and GitHub pages). He then walks through the steps in the full process:

• Create an OpenSSL Key
• Use Box to create the PHAR
• Generate a version file
• Create the gh-pages branch
• Write self-update/rollback commands
• Enable Travis-CI for the repository
• Create an SSH deploy key
• Archive and encrypt the secrets
• Write a deployment script
• Add the script to travis

While this seems like a lot of steps to just get a more secure phar set up, Matthew has done the hard work for you here and includes all of the commands, configuration examples and steps you'll need to take to fully set the process up. If all goes well, his example in his last "push and watch it work" section will go off without a hitch.

In this post to his site Joshua Sampia shows how to set up and configure CORS in your Slim-based application. CORS or Cross-Origin Resource Sharing, lets you further lock down what sources can access your application and some requirements around the ones that can.

Ok, another PHP post but this time it’s about setting up some middleware for a slim PHP application.

Let me set this up. We are building a simple REST API for use with a basic phone native app (both Android and iOS). Me being new to this, I wasn’t sure if the native app domain call is considered cross browser or not, plus there are some outside companies we are working with who MAY access the API as well. [...] I setup some middleware by extending the Slim Middleware class and adding them via the app.

He talks about the steps he had to take in the middleware to set up an AccessControlOrigin middleware (and two others requiring HTTPS and HTTP Basic Auth). He includes the simple code to send the required HTTP headers to support CORS on the response object and the update to his Javascript to include credentials with every request.

The Paragon Initiative has posted a new white paper to their site covering secure data encryption in web applications written in PHP. The paper covers high level topics and offers some more practical suggestions about tools and guides to use in protecting your applications.

Encrypting network communications is absolutely essential to the security of anyone who wishes to use your website or application. The standard and most reliable form of network encryption is called Transport Layer Security (TLS), which was preceded by and older standard called Secure Socket Layer (SSL).

Websites that use SSL or TLS are accessible by typing https://domain.com into your browser instead of just http://domain.com. Consequently, the shorthand way to refer to HTTP over TLS is simply HTTPS. Contrasted with network cryptography, storing sensitive information is a much more challenging and interesting problem to solve, and is the focus of this paper.

Among the topics covered in the white paper are things like:

• The flow of a HTTPS request (and if it's "fast" or not)
• Secure password storage and handling
• On-demand encryption/decryption
• Cryptography library recommendations
• Using asymmetric cryptography with public and private keys

They also point to this curated list of resources to help you learn more about general web application security including cryptography.

Pádraic Brady has a new article on his site talking about the secure distribution of phars (PHP archive files) including some of the common pitfalls and potential solutions.

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed. [...] [Several security-related issues introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed.

He shares some of the steps he's taken to secure his own phar for a CLI application with things like:

• Distribute the PHAR over HTTPS
• Enforce TLS verification
• Sign your PHAR with a private key
• Avoid PHAR Installer scripts
• Manage Self-Updates securely

He finishes the post with one of the most important parts of the article - a reminder to do all of the things on the list above consistently.

This is not an outrageous outcome to introducing proper security on PHAR downloads. Go forth and do it for all PHARs. Help create an environment where distributing and installing code in secure ways is the normal expected thing to do.

Pádraic Brady has a new post today sharing a tool he's created to enhance the current PHP file_get_contents function with a safer, more secure alternative, the humbug_get_contents library.

With the release of PHP 5.6, there was a significant security improvement in how PHP handled SSL/TLS protections, namely that it enabled a secure set of default options. Previously, SSL/TLS was disabled by default. No peer verification, no certificate checking, and a lack of configuration options had combined to create a serious problem. You can find this problem easily by searching for file_get_contents() on github and locating a call to this function used to retrieve any HTTP resource while also having zero configuration.

An excellent example of this is Composer which uses file_get_contents() instead of curl to ensure maximum compatibility with using systems. Of course, this beggars a question. If all the SSL/TLS protections are off by default in PHP 5.3-5.5…what’s stopping some irksome hacker from injecting bad code into our Composer downloads? Answer: Nothing.

The package provides a drop-in solution to the possible man-in-the-middle issues that could be caused by the native functionality. It enhances the current function with additional TLS/SSL checking for HTTPS requests on current PHP versions.

On the Docnet.nu blog today they've kicked off a series looking at the use of streams and SSL in PHP and asking if you're doing it wrong in your current applications. The focus is more on the security aspect, breaking it down into a set of common problems (and how to work around them).

The upcoming PHP 5.6 release brings with it a number of improvements to encrypted PHP streams, both internally and externally. In these articles I will try to cover the most important changes, and how they affect your code. This article will focus on how to get the best security level in code that needs to be run on PHP versions below 5.6, and highlighting some of the gaps in the currently available functionality. Version 5.4.13 is the earliest version that supports all the options described below - and if you are running something earlier than this, then you really should consider upgrading to at least the latest version of the 5.4 series 1.

Their list is made up of six different problems:

• Problem 1: Peer Verification
• Problem 2: Cipher Lists
• Problem 3: Protocol Support
• Problem 4: TLS Compression Attack Vulnerability
• Problem 5: Cipher Order
• Problem 6: TLS Renegotiation Attacks

Each problem comes with a brief description of what it is and why it's an issues. Some also include code snippets showing how to correct the issue, usually relatively simply.