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.
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.
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.
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.
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.
Alarmist rhetoric from news organizations about the web is nothing new, but today's front-page headline on the New York Times still caught my eye: "Web Code Offers New Ways to See What Users do Online." It's about HTML5 privacy risks, and it's a load of crap.
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.
<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?