On the Websec.io site a new tutorial has been posted (a sort of continuation from this previous article) showing how to keep secrets safe in a PHP and Docker environment without too much overhead.

In a previous post I covered one method you can use to secure the credentials in your PHP application. In that article I provided an example specific to the use of Apache and its envvars handling to read in values and pass them along to the waiting PHP process as $_ENV variables. This in combination with the psecio/secure_dotenv library allowed you to pass along an encryption key that could be used to decrypt values from the application's .env file.

While this works for a flat Apache and PHP environment, the world has moved beyond that basic setup and has moved to using another popular environment building tool: Docker. [...] So, if we move forward with current technology, we need a way to secure our credentials in a Docker-based environment that makes use of PHP-FPM and Nginx. Fortunately there's a relatively simple way to handle this with just a few configuration changes.

The tutorial starts with an overview of what technologies are involved in the environment (Docker, PHP-FPM, Nginx and Vault) and some of the options for storing secrets with Docker. It then gets into the configuration files needed to create the environment: a Docker Composer configuration, the Nginx server definition, the PHP-FPM settings and the .env file that contains the secrets. Using these pieces and some special configuration directives, the secrets are injected into Docker when the containers are built and storing them in-memory rather that on disk.

On the Paragon Initiative blog has a new post that shares some of their own tips and tricks of how to building secure PHP applications moving forward in to 2018.

As the year 2018 approaches, technologists in general—and web developers in particular—must discard many of their old practices and beliefs about developing secure PHP applications. This is especially true for anyone who does not believe such a feat is even possible.

This guide should serve as a complement to the e-book, PHP: The Right Way, with a strong emphasis on security and not general PHP programmer topics (e.g. code style).

The guide covers a wide rang of topics that can help you secure your applications (and not just PHP ones either) including:

• working with security headers
• safely handling file uploads
• effective password hashing
• general-purpose cryptography
• searchable encryption
• event logging with Chronicle

Each item in the list is a link to another part of the guide where the topic is discussed. In each there's plenty of good information about prevention and implementation as well as links to other tutorials and packages that can help.

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).

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".

Jack Skinner has posted his latest "roundup" results of the most popularly installed versions of PHP across the web. In the post he looks through the percentage of installations for each version and how many are "secure" (currently supported and in a popular/stable linux distribution).

Last year, Anthony Ferrara posted an excellent round up of PHP versions in the wild, specifically focusing on the volume of un-patched versions running production websites. Even as an estimate it was an eyeopening moment for many people.

Using data from w3techs and, while the raw data isn't posted, what's there is good enough for an estimation. He talks some about the definition of "secure" in the context of the results and lists the current versions of several popular linux distributions and the versions they support. His results are then grouped by minor release and created some graphs for the results to help with visualization. The remainder of the post shares these results for PHP versions 5.6, 5.5, 5.4, 5.3 and yes even 5.2/5.1. The results end with overall numbers/graphs of the most widely installed versions and what percentage of those are considered "secure". With PHP 7 just released the results are a little discouraging but it is good to see things trending the right way since last year's results.

The Paragon Initiative has posted an article to their blog talking about how to build secure applications in PHP. Rather than try to get into the specifics of specific vulnerabilities, they stay relatively high level and stick with concepts to keep in mind and steps you can follow to ensure your development practices are secure.

Whether you're planning the development of a brand new application or trying to prevent legacy code from causing a costly data breach, if you're going to be writing PHP, where should you begin? That is the question we will attempt to answer, in detail.

The article starts with an "easy way out" for those that don't feel like they know enough or just don't have the resources they need: hire consultants. With that out of the way, the article mentions two root causes for insecure apps: lack of knowledge about security and bad development habits. They then get into some suggestions about how you can learn to understand and prevent vulnerabilities in your own applications. They focus in on a few key places for PHP developers to pay attention to, complete with some charts showing the parts of the flow. The post ends with some advice on what do to if your site is compromised anyway and how to move forward.

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.

On the Paragon Initiative blog there's a post showing you how to implement secure authentication with long term persistence (a secure "remember me" essentially) in a PHP application

A common problem in web development is to implement user authentication and access controls, typically accomplished through sign-up and log-in forms. Though these systems are simple enough in theory, engineering one that lives up to application security standards is a daunting undertaking.

Without a great deal of care and sophistication, authentication systems can be as fragile as a cardboard lemonade stand in a category five hurricane. However, for everything that can go wrong, there is an effective (and often simple) way to achieve a higher level of security and resilience.

He starts with a look at passwords - how to correctly hash them, how salts play into it and some suggestions about password policies. From there he gets into the "remember me" handling, giving two common problems with most systems: insufficient randomness and timing leaks (timing attack issues). He then proposes a different kind of solution, storing some additional information in the database record, a "selector" that's not timing dependent to find the record then use a timing attack safe method to compare the hashes. He ends the post with a brief look at account recovery and some things to watch out for if you plan to implement it.

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.

The Resonant Core blog has a post today with a selection of tips and techniques you can use to help build secure applications in PHP, preventing several of the most common issues (several as mentioned in the OWASP Top 10).

There are but two causes for the unintentional creation of insecure web applications: A lack of knowledge about security [and] bad development habits. Developers who don't know about the risks involved with writing a widget a certain way are unlikely to make the secure choice. Thanks to the work of MITRE and OWASP, the most common vulnerabilities (and their consequences) are widely known and accessible. However, when teams are under pressure to meet a tight deadline, bad habits and insecure development practices may still emerge.

Most of the examples (at least the solutions) center around a framework they've created (Tuner) but the concepts are all there and could be adapted to other tools easily. They talk about the "pain" that can come with secure coding and how the right tools can make it much easier for the developer. He talks about how the framework offers a better database interface based on PDO and prepared statements to prevent SQL injection issues (with examples for each of the CRUD operations). He also shares a list of pre-existing PHP libraries that can help make the rest of you application secure too including:

• HTML Purifier
• Twig (templating)
• password_compat and the built-in password hashing

He also mentions a PHP extension that adds in scrypt support, another option for hashing strings and passwords as an alternative to bcrypt.