On the Snyk.io site they've announced the release of their State of Open Source Security Report for 2019. In this report they talk about packages and managers outside of the PHP ecosystem, but there's also plenty in there about general Open Source security, regardless of the technology used.

We’ve seen big technology players doubling-down on open source in 2018. In every registry we reviewed, we saw an increasing rate of open source libraries being indexed in every language ecosystem. This is to be expected, but the rate of growth may come as a surprise to many.

[...] In 2017 the CVE list reported more than 14,000 vulnerabilities, breaking the record for the most CVEs reported in a single year. 2018 continued the record-breaking streak with over 16,000 vulnerabilities reported.

We can see how open source package growth translates into user adoption when looking at the download numbers for various packages in different ecosystems.

They specifically cover packages in the Node.js, Python and Java worlds but the same principles apply to PHP and Composer packages too. There's a few other related posts that go into more detail on the vulnerability increases, the desire for Open Source developers to be security-minded and other topics. You can get all of the information in one place, though: the PDF version of the report.

On the PHP.net site they've made an announcement about releases of all currently supported major PHP versions with bugfix/security releases.

The PHP development team announces the immediate availability of PHP [7.0.33, 7.1.25, and 7.2.13]. Five security-related issues were fixed in this release. All PHP 7.0 users are encouraged to upgrade to this version.

You can download these latest releases from either the main downloads page or windows.php.net for the Windows executables.

There's also a note for the PHP 7.0.33 release based on the release and support timelines: this will be the final release, of any kind, for the PHP 7.0.x branch including security support. If you haven't already upgraded past version 7.0.x, there's never been a better time!

The folks over at RIPSTech, a PHP-focused security company, have posted the announcement about the latest edition of their PHP Security Advent Calendar. This is the third year they've done this and it's always interesting and fun to find out about some of the vulnerabilities that can lie hidden in everyday PHP code.

The holiday season is coming up again and it’s time for some security fun. For the third time in a row, we are proud to announce our PHP security advent calendar. This year, we will analyze 24 exciting security bugs that we detected in the most widespread WordPress plugins.

In our first calendar edition in 2016, we analyzed exceptional vulnerabilities in some of the most popular open source PHP applications. Last year, we released 24 PHP security challenges with a hidden security pitfall in every day’s code challenge. This year we would like to give once again something back to the great PHP and Infosec community and release another advent calendar with 24 security surprises.

While you can't start on the calendar just yet (as of this post it's only November 28th) it will be coming soon. Be sure to sign up for their newsletter to get updates on when it's officially launched.

For the WordPress users out there, the RIPSTech.com blog has posted an invaluable "cheat sheet" sharing details on securing your configuration to prevent exploits and other issues down the line.

WordPress is the most frequently installed web application in the world. The system is operated not only by experienced developers but also by beginners. In this blog post, we summarize what to look out for when configuring your WordPress installation’s security.

In our series about misconfigurations of PHP frameworks, we have investigated Symfony, a very versatile and modular framework. Due to the enormous distribution and the multitude of plugins, WordPress is also a very popular target for attackers. This cheat sheet focuses on the wp-config.php file and highlights important settings to check when configuring your secure WordPress installation.

Suggestions made in the guide cover values involving: debugging, database credentials, keys/salts, database repair, external requests and many more. The post provides examples for each of the settings and a recommended value to make it easy to drop in the changes and harden your WordPress installation.

On the Jolicode.com blog, there's a tutorial they've posted showing how to "mix security and forms" in a Symfony application to show only certain form fields based on a user's roles.

In some applications, it could be required to disable some form fields depending on user’s roles.

In this article, we will see how to implement this feature thanks to a simple example: a blog engine.

For their example, they use a Symfony 4 application with the MakerBundle and create a basic blog with "article" entities and an "admin" entity for the user list. From there, the post includes the code needed to update the buildForm method in the ArticleType class to check the current user and be sure they have the "admin" role. To make this work, they also build out a SecurityExtension form extension class that performs the actual check. This is then hooked into the pre-submit event on the form to prevent other issues where an attacker might delete the "allowed" element and submit the data anyway. The post wraps up with an example of performing a similar check but hiding the field instead of just disabling it in the form.

On the TutsPlus.com site they've posted a new tutorial showing you how to use the Symfony Security component to authenticate users in your system and use role-based access checks.

In this article, you'll learn how to set up user authentication in PHP using the Symfony Security component. As well as authentication, I'll show you how to use its role-based authorization, which you can extend according to your needs.

The tutorial starts with a summary of the Symfony Security component and what subcomponents it includes. It then walks you through the installation of the component via Composer (of version 4.1). They then walk through a more real-world example that uses user credentials and role information pulled from a MySQL database. They provide the code for the User class, a DatabaseProvider class, a DatabaseAuthenticationProvider, and how they all work together. Code is provided to complete the authentication process and to create the database table for the user credential and role details.

On the TutsPlus.com site they've posted a new tutorial showing you how to use the Symfony Security component to authenticate users in your system and use role-based access checks.

In this article, you'll learn how to set up user authentication in PHP using the Symfony Security component. As well as authentication, I'll show you how to use its role-based authorization, which you can extend according to your needs.

The tutorial starts with a summary of the Symfony Security component and what subcomponents it includes. It then walks you through the installation of the component via Composer (of version 4.1). They then walk through a more real-world example that uses user credentials and role information pulled from a MySQL database. They provide the code for the User class, a DatabaseProvider class, a DatabaseAuthenticationProvider, and how they all work together. Code is provided to complete the authentication process and to create the database table for the user credential and role details.

On the Laravel News site they've posted an announcement recommending all Laravel 5.6.x and 5.5.x users upgrade to the latest release (5.6.30 & 5.5.42) due to a security issue dealing with the APP_KEY value.

Laravel 5.6.30 and Laravel 5.5.42 have both been released to fix a security issue and is recommended that all users upgrade as soon as possible.

This update also includes changes to cookie encryption and serialization logic. In addition to the upgrade, they also recommend rotating the key if you believe any malicious user (or former developer/employee) had access to it. The upgrade guide has the information you need to make the update to your application.

On the TutsPlus.com site they've posted a tutorial showing you how to use the Auth0 service to create a passwordless authentication system for your application.

In this article, you'll learn how to set up passwordless authentication using the Auth0 service. Auth0 allows you to outsource authentication features for your app.

Auth0 is an authentication-as-a-service tool that makes implementation of authentication-related features for your app or site a breeze. If you've built an app and you want to just outsource the authentication and authorization features, a service like Auth0 is something you should consider.

The tutorial walks you through the installation and configuration process of their example PHP application including the setup of the .env file to contain the Auth0 secrets. It then provides the code needed to create two kinds of logins:

• Using email as the identifier
• Sending the approval via SMS

Both make use of (the Auth0 PHP SDK) to do most of the heavy lifting but there's still a bit of code you'll need to get it up and running.

On the Websec.io site there's a new tutorial posted showing a potential method for keeping secrets safe in PHP-based applications.

One of the most difficult things in any kind of application (not just web applications) is how to protect "secret" values. These values might be API keys, database passwords or even special bypass codes. Ideally, you're not having to define these directly in the application and can have them loaded from another source.

While a lot of the issues around protecting secrets can be removed by better secret handling, it seems like there's still always a need for some kind of secret value to exist in an application. Using this sort of pattern is, obviously, recommended against. The Common Weakness Enumeration database even has an entry specifically about it: CWE-798. Hard-coding credentials, especially plain-text ones, can be a huge risk if an attacker were able to somehow access the code and read them directly.

The post then goes on to talk about specific issues with secrets/credentials handling in PHP and some of the common approaches (mostly using a .env file). It covers some of the basics of using the phpdotenv package before getting into the encryption of the secrets it contains. It makes the recommendation of using an "Apache pull" method to pull in the encryption key when Apache starts, putting it into an environment variable and using the psecio/secure_dotenv library to work with the encrypted values.