Freek.dev

In this video Tom Scott explains why Chrome couldn't handle http://a/%%30%30 :

https://www.youtube.com/watch?v=0fw5Cyh21TE

Read more

In this excellent post Matthias explains why you can't put all your trust in cat when inspecting a file:

https://ma.ttias.be/terminal-escape-sequences-the-new-xss-for-linux-sysadmins/

Let's all agree to never trust anything that has been posted on the internet without very thorough inspection. And let's especially agree to never run an arbitrary command or script found on the internet, without really close inspection.

Read more

Garrett St. John wrote a clear example on how to use UUIDs in Eloquent models. This kind of logic could go in a trait so it can be reused across multiple models.

By default, Eloquent uses an auto-incrementing integer as the primary key for its tables. While most of the time this is totally acceptable, sometimes there is a need for primary keys to be less predictable.

EDIT: Kirk Bushell has made a trait for this functionality. Take a look at his Eloquence package on GitHub.

Read more

The project I'm currently working on will have to send out mails to all its users on a regular basis. It's not a newsletter: the contents of each mail will be very specific to each user. The mail also should contain a link to unsubscribe the user from simular future mails.

The link could look like this: https://myapp.com/unsubscribe. Clicking on the link would direct the user to a login page. After the user has logged in the unsubscribe can be automatically performed. In my mind requiring the user to login first in order to unsubscribe from something isn't very user friendly.

This can be improved by adding the id of the user to the link. Here's what that could look like: https://myapp.com/user/1/unsubscribe. With this link you the app can unsubscribe the user with id 1 in one go. That'll work, but it's not very secure. Unsubscribe links for all other users can be easily guessed. Such links can be made more secure by adding a signature and an expiry date on them.

My colleague Sebastian coded up a Laravel package to create signed url's with a limited lifetime. Here's example where the url gets signed and made valid for only one day:

echo UrlSigner::sign('https://myapp.com/user/1/unsubscribe', 1);

This outputs an url that looks like: https://myapp.com/user/1/unsubscribe?expires=1123690544&signature=93e02326d75

The validate-method can be used the determine if a signed url is (still) valid:

$isValidUrl = UrlSigner::validate($theSignedUrlInTheExampleAbove);

The signature is calculated using the original url itself, the expiration date and a secret string that's specific to your project. When a malicious user tries to change any part of the url the signature won't match up.

I'm assuming that the most common use case of signing url's is to protect routes. The package supplies a middleware that protects routes from invalid signed url's. In the following example only requests with a valid signed url will hit the controller:

Route::get('unsubscribe', ['middleware' => 'signedurl', 'uses => 'UserController@unsubscribe']);

If you're interested in using the package, take a look at it on GitHub: https://github.com/spatie/laravel-url-signer

There's also a framework agnostic version: https://github.com/spatie/url-signer

E-mails can be intercepted and are never 100% secure. Bearing that fact in mind you should never use this kind of link for any destructive action.

EDIT: Some fellow developers pointed out that I could also obfuscate the id in the url. Here are two good libraries to do that:

• http://hashids.org/
• https://github.com/jenssegers/optimus

And sure enough, the unsubscribe links of other users cannot be easily guessed. A small downside however is that the url becomes less readable. The big disadvantage is that the url will remain valid forever. As these links through an unsafe medium I think it's a good idea to give them a limited lifetime. Signing an url will do that.

Read more

If you're comfortable at the CLI, WPScan is super easy to get going.

The project is open source on Github and uses the WPScan Vulnerability Database, an open dataset of known WordPress vulnerabilities.

Installation on a Mac is a piece of cake. Other methods and operating systems are documented on Github.

Read more

While doing some research about other obfuscation techniques I stumbled upon an implementation based on Donald Knuth's integer hash. This unbelievable small and fast algorithm will generate random-like integers with the ability to convert them back to the original value. This technique was so cool that I decided to create a PHP package for it called Optimus.

Read more

When installing an SSL certificate on your server you should install all intermediate certificates as well. If you fail to do so, some browsers will reported “untrusted” warnings for your site like this one.

Searching and downloading those intermediate certificates can be a hassle.

Today my colleagues at Spatie and I launched certificatechain.io. This online tool helps you download all intermediate certificates. Just paste or upload your certificate and you'll get a file containing the entire trust chain that you can install on your server.

The site is built with Laravel 5 and uses the SSL certificate chain resolver we made last month.

Read more

This package ensures that your application doesn't have installed dependencies with known security vulnerabilities.

...

The checks are only executed when adding a new dependency via composer require or when running composer update: deploying an application with a valid composer.lock and via composer install won't trigger any security versions checking.

Awesome idea! It works by leveraging the "conflict"-property in the composer.json-file of the package.

Read more

CodeIgniter 3.0 will support PHP 5.2. Anthony Ferrara wrote an interesting article on his blog why that's a very bad thing.

http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html

Read more

Ultimately, we can even imagine a long term in which secure origins are so widely deployed that we can leave them unmarked (as HTTP is today), and mark only the rare non-secure origins.

I'm all for it.

Read more

With my recent move to HTTPS I wasn’t sure if there were any pages left on my site that had Mixed Content or not. To check this I wrote a little PHP CLI app to scan an HTTPS website for Mixed Content. The script starts crawling at a given URL, and processes the page.

Nice!

Read more

Google introduced a new method that verifies you are human without you having to solve a riddle.

On websites using this new API, a significant number of users will be able to securely and easily verify they’re human without actually having to solve a CAPTCHA. Instead, with just a single click, they’ll confirm they are not a robot.

It looks like this:

http://googleonlinesecurity.blogspot.nl/2014/12/are-you-robot-introducing-no-captcha.html

Read more

Authy makes it easy to integrate two-factor authentication into your existing Laravel application. It's user-end implementation is versitile, offering support for both smart-phones and standard phones. Furthermore, implmentation with its API is easy and seamless. Finally, its analytics and data tracking can you provide insights into your users and how they interact with your application's authentication system.

This tutorial assumes that you have an Authy developer account (which can be created here ), an application (either testing or production), and your application's API key.

Read more

When creating a new website you should always use HTTPS. Here's a video recorded at Google I/O earlier this year on the why and how.

The New York Times switched to HTTPS last month. Here are their reasons for doing so:

http://open.blogs.nytimes.com//2014/11/13/embracing-https/

Read more

99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address.

Read more