Tag: security

Laravel Tip: Generating Signed URLs with Ignored Parameters

Posted on by Andrew Minion

TL;DR: don’t use ignored URL parameters when building signed URLs or the resulting signed URL will be invalid. Instead, manually append them to the resulting URL.

Laravel includes some really nice helpers for building signed URLs: https://laravel.com/docs/master/urls#signed-urls

They allow you to generate a URL containing a signature that prevents anybody from modifying the URL to access something you didn’t intend (e.g., you could provide a signed URL for a specific post with ID 123; if somebody changed that ID to 124, then Laravel will display a 403 Signature Invalid error rather than happily displaying post 124).

Occasionally you may wish to ignore certain URL parameters when validating the signature (e.g., a pagination or print parameter).

In this case, you cannot include the ignored parameter when generating the signed URL, or the URL will be invalid.

Here’s an example. This route ignores the print parameter when verifying the signature:

If you generate a signed URL without the print parameter, it will be valid. But if you include print in the URL parameters for the helper method, the resulting signature will be invalid, because Laravel uses all of those parameters to generate the signature. Instead, just add the new parameter to the end of the resulting URL:

Note how examples 1 and 3 have the same signature; that is the signature that Laravel calculates when determining what the correct signature should be to verify that the URL has not been modified. The example 2 use print=true when generating the signature, but will remove that parameter when verifying the signature, so they don’t match.

Update: I submitted a PR to the framework to pass ignored parameters to the signed route methods to make this easier.

Proxying Signed AWS S3 URLs using CloudFlare Workers

Posted on by Andrew Minion

A common use case for S3 is hosting content that should not be available to the public, but needs to be made available to specific user(s) or for a specific length of time. A great example of this is granting access to digital files after a purchase or subscription payment.

In this case, I needed the domain to be a first-party subdomain, rather than a default Amazon AWS domain, due to same-origin policy requirements.

Hat-tip to Fershad Irani for an initial version, which I modified to suit my needs.

Set up the AWS Bucket

  1. Create a bucket
  2. Prevent all public access to objects in the bucket
  3. Upload files

Configure a Cloudflare Worker

  1. Go to CloudFlare > Workers & Pages > Overview and create a new application
  2. Add the worker code below, modifying line 8 to use your bucket name
  3. Publish the worker
  4. If you already added the subdomain under the DNS tab pointing to anywhere, delete that before proceeding
  5. View the worker and go to the Triggers tab
  6. Under Custom Domains, add a custom domain (documentation) and enter your custom subdomain
  7. Under Routes, add a route for your custom subdomain