security

Your Serverless Function has a Secret

Your Serverless function has a secret... maybe it's a password for a remote API, a private key, or signing certificate. These secrets have to be stored somewhere, and in the old days that usually meant just a plaintext config file on your server. Sure, you could encrypt it, but then you have to put the key on the server, and you haven't gained anything except a bit of obfuscation. Or you could use more complex schemes, like Hiera-Eyaml, which is a small improvement, but you've really just moved the threat to a different part of your infrastructure.

Origin Protection with AWS WAF & Shield

Amazon has been steadily improving their CloudFront CDN offering with WAF (Web Application Firewall) capabilities. This is a great feature, however it's ineffective if origin servers can be attacked directly, bypassing CloudFront. With a little extra work, access to the origin can be restricted. The solution is to add a secret header value at the edge, and configure the load balancer to block requests that are missing this secret. This is necessary because CloudFront distributions are not associated with security groups, nor are fixed IPs available (unlike higher-priced competitors like Kona Site Shield).
Anatomy of a Drupalgeddon attack Mike Purvis Mon, 04/18/2016 - 18:08

Before working at Metal Toad, I saw an email from Acquia. A strange email.

It went something like this: 

On October 15th, we will be addressing a security concern at 9:00 am.

Hmm. That's interesting. I don't remember getting an email about security updates like this. As with any CMS, there are constant security updates as new (and sometimes exotic) vulnerabilities are found. 

OAuth 2.0 and OpenID Connect: Now What? Dylan Tack Tue, 08/25/2015 - 22:34

A former Toad recently asked my opinion about this article:
OAuth 2.0 and the Road to Hell
The question is well-timed: I'm in the middle of a big OpenID Connect / OAuth 2 implementation.

That article was written three years ago, but I think Eran Hammer is essentially correct: the standard (especially OpenID Connect) is big, complicated, and enterprise-y.

Simple password grants with OAuth 2.0 and Drupal Dylan Tack Wed, 09/10/2014 - 08:30

Like many Drupal developers, we have become big fans of decoupled front-ends using Drupal as a RESTful backend (a.k.a. "headless" Drupal). The myriad of authorization options can be confusing, however. We've settled on OAuth 2.0 for most situations. When OAuth is brought up, many people will think of the single-sign-on flow in a browser, with the associated redirects and permission dialogs. This flow is widely used, but not always a good fit for first-party applications, or machine-to-machine API interactions.

We Are Providing Time for all of Our Employees to Change Their Passwords - Your Company Should Too. Joaquin Lippincott Fri, 04/11/2014 - 16:40
Heartbleed logo with bandaid

With the highly publicized Heartbleed vulnerability this week, a vulnerability in the core of internet security has been exposed. While the vulnerability hasn't been widely known, it has existing in perhaps 2/3 of the internet for more than a year, meaning any passwords that have been used during that time are likely compromised.

URL Shorteners Must Die

URL shorteners (such as bit.ly and tinyurl) have been called the "herpes of the web". Beyond just link-rot, a public shortening service is per se an open redirect vulnerability. Their ubiquity makes them an easy vector for spammers, phishers, and cross-site forgery attacks.

Joshua Schachter writes:

With a shortening service, you're adding something that acts like a third DNS resolver, except one that is assembled out of unvetted PHP and MySQL, without the benevolent oversight of luminaries like Dan Kaminsky and St. Postel.

Luckily, you don't have to contribute to this scourge.

Using JSONP Safely

JSONP is a way to make cross-domain requests through javascript. It takes advantage of a loophole in the browser's same-origin policy: <script src="https://anywhere.com/data.jsonp"></script> tags are allowed to load files from any domain. This differs from normal AJAX requests, which are only allowed to make requests to the same domain as the page you are viewing.

Unfortunately, many guides to implementing this technique in PHP contain a dangerous security flaw. Can you spot it?

Ready for transformation?