Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Michael Dyrynda:
Customising Laravel's URL signing key
Jan 03, 2019 @ 15:12:29

Michael Dyrynda has a post to his site sharing a method he's worked up for customizing the URL signing key that the Laravel framework uses to sign URLs to ensure the integrity of the URL's contents.

Since 5.6, Laravel has shipped with functionality to sign URLs. These URLs append a "signature" to the query string, so that Laravel can verify that the link has not been tampered with since it was created. This also allows you to generate temporary signed routes that expire after a configured period of time.

This is useful for things like verifying account emails, or enabling passwordless logins.

Passwordless logins is something that is quite useful for an application, but what if you wanted to be able to generate a signed URL in one application that would allow you to log in to a second application?

He starts by defining the use case, requiring multiple signing keys to be used, one for customer URLs and another for admin URLs accessing the same content. He makes this work through the use of a custom key resolver, pulling the key for the signing dynamically. He also shows how to update the passthrough authentication handling, allowing the administrators (staff) of the system to bypass normal authentication handling and more directly view the user's information.

tagged: customize tutorial laravel url signing key value

Link: https://dyrynda.com.au/blog/customising-laravels-url-signing-key

Pádraic Brady:
PHP Package Signing: My Current Thoughts
Mar 10, 2014 @ 16:57:49

Pádraic Brady has a new post sharing some of his ideas around PHP package signing and a few possible ways to approach (and possibly solve) the problem.

We figured out how to write good code. We figured out how to write good code in a reusable way...for the most part. We figured out how to distribute and mix all that good reusable code in a sensible fashion. Can we now figure out how to do it all securely? [...] The problem with package signing from my perspective is tied up in a phrase most of you would know: The needs of the many outweigh the needs of the few. Thank you, Spock.

He compares two different alternatives, Public-key infrastructure (PKI) vs (Pretty Good Privacy) GPG, and how the idea of trust fits into the picture. He also points out an unfortunate fact when it comes to the initial adoption of package signing methods - people are lazy (and cheap). They want to get things done and not have extra steps. Signing their packages would be one of these steps. He suggests an alternative, though, using double signatures to verify the integrity and validity of its contents. He also talks about the role that metadata plays in the overall package ecosystem and how signing it as well could be part of the solution.

tagged: package signature signing metadata packagist composer

Link: http://blog.astrumfutura.com/2014/03/php-package-signing-my-current-thoughts

Pádraic Brady:
Thoughts on Composer's Future Security
Mar 06, 2014 @ 17:09:06

Pádraic Brady has a new "let’s watch Paddy think aloud in a completely unstructured manner blog post" about the future of security when it comes to the popular PHP package manager Composer. It's recently come under criticism around its lack of package signing and TLS/SSL support.

The Composer issue, as initially reported by Kevin McArthur, was fairly simple. Since no download connection by Composer was properly secured using SSL/TLS then an attacker could, with the assistance of a Man-In-The-Middle (MITM) attack, substitute the package you wanted to download with a modified version that communicated with the attacker’s server. They could, for example, plant a line of code which sends the contents of $_POST to the attacker’s server.

He's been working on some updates to the project, one of with is TLS/SSL support as defined in this pull request currently pending. It enables peer verification by default, follows PHP 5.6 TLS recommendations and uses local system certificates in the connection. He talks some about other additional TLS/SSL measures that could be added in the future and how, despite it being safer than nothing, TLS/SSL is not the "cure all" for the problem.

He then moves on to package signing and suggests one method for implementation - signing the "composer.phar" executable and signing "everything else" (packages to be downloaded) to verify their validity.

The flaw in Composer’s installer isn’t that it’s unsigned, it’s that it doesn’t afford the opportunity for the downloader to read it before it gets piped to PHP. It’s a documentation issue. You can go down the route of using a CA, of course, but that’s further down the rabbit hole than may be necessary. Signing the composer.phar file is another matter.
tagged: composer package signing tls ssl support security

Link: http://blog.astrumfutura.com/2014/03/thoughts-on-composers-future-security

KnpLabs Blog:
Composer Level2: 5 more things like Class Maps, Forking, & Scripts
Nov 08, 2012 @ 15:17:14

On the KnpLabs blog there's a new post from Ryan Weaver sharing some cool things you can do with Composer you might not have known about when managing your application's dependencies.

For those of you that are comfortable with Composer, I wanted to talk about a few lesser-known, but really fantastic features. These are inspired by real questions I've heard while running around the country doing my one-man composer-and-dancing show (i.e. conference talks).

He shares four of them with a fifth that's more of an "upcoming feature" than a current one:

  • Autoloading & Performance: "I thought class maps were the fastest?"
  • Running Post-Deploy Scripts
  • "What if I need to fork a library?"
  • Can I host private packages on Packagist?
  • What about signing the authenticity of Packages?

That last one about package signing is still on the known issues list and is under discussion, but no doubt that future versions of the tool will support it.

tagged: composer classmap forking scripts package signing

Link:

Joshua Thijssen:
Installing composer: russian roulette.
Oct 15, 2012 @ 17:19:19

In this new post to his site Joshua Thijssen talks about the "russian roulette" that's involved in the single-line install of Composer (as was mentioned here) and how it sets a bad precedent for developers to follow.

Michael Maclean has written a very good article on what is wrong with this. His point essentially boils down to this: you have no way of knowing what you are actually installing on your system and if it’s the software as intended by the original developers. Especially developers tend to do this more and more often, and in even more dangerous ways. Now, this is bad by itself of course, but this is not a simple app you run on occasion (if that was an excuse to begin with). Composer is the software that pretty much controls ALL your application dependencies. What would happen if this software would fetch its packages from packagists.org, or packagits.org?

He brings up a scenario where, say Packagist.org gets hacked and links to repositories are altered. If you're blindly installing via Composer, you'd have no idea that the code you're working with is potentially tainted. He notes that it boils down to trusting the source and how some simple hashing could help some of the problems. He also talks briefly about security issues that have been discussed (like "use SSL" or "don't run as root") to help prevent issues.

He suggests the implementation of the hash-based signing of the downloads to ensure that the software you're getting is what you're expecting. He mentions getting rid of auto-updates and the creation of signed packages/tarballs to help increase the security checking abilities of the installer.

tagged: composer install package signing hashing security

Link:


Trending Topics: