Pattern Library Security Vulnerability

If you’re running a version of the ALA pattern library that’s more than a few weeks old on a public server, please update it right away. The script that powers the navigation in the pattern library was found to have a pretty glaring security issue that would potentially allow read access to any file on a public webserver, even outside of the web root. If you’re running the pattern library locally there’s nothing to worry about—but you should pull the latest from the repository just the same.

To view the patterns in isolation, a small PHP script checks for a path variable in the URL then uses include() to pull a snippet of code on the page. If that variable isn’t present, all the patterns are rendered instead.

Unfortunately, where this pattern library script had really only been used on internal projects, it operated on a certain level of trust—whatever was passed in that path variable would be included on the page, without restriction or filtering. This meant that a path pointing outside of the pattern library root—or even the web server’s public root—could be rendered on a public page. Permissions settings aside, this meant the potential for public access to any file on a server hosting the pattern library.

This issue has since been resolved, and any inputs thoroughly sanitized. We’re now ensuring that special characters are escaped, that the path variable can’t point to any parent directory, and that the file being included has an .html extension.

In terms of lines of code, this was a very small issue—resolved in about fifteen minutes, if even that. In terms of security impact, it meant largely unrestricted access to any file on any public-facing server that hosted the pattern library—a serious issue.

The lesson here is to always sanitize your inputs—even in code that isn’t meant to be released to the public, just in case.

Thanks to @linssen for pointing the issue out to us.