Month: November 2013

Starting Secure Development

As I’m trying to get back into some more regular article writing for the websec.io security tutorial site, I thought I’d ask on Twitter for some of the things people might be interested in reading. I thought I’d gather them all up and share them here (since Twitter is sooo good at tracking this kind of thing…). There were some good responses and some things I hadn’t thought about yet:

> Top 10 pitfalls and how to avoid them. @calevans
> how to actually filter input and escape output correctly. @skoop
> I’d like the ability to answer to the question “Is it safe?” with confidence. @AmyStephen
> Data sanitization, escaping, and authentication. @codeguy
> how to test for secure code. @scottmattocks
> One of my largest stumbling blocks has been learning how to write proper (library-less) templates in a secure and flexible manner. @mkmcdonald

You can see all of the responses here. There’s a few articles related to these posted already:

If you have any other suggestions let me know!

Advertisement

iniscan: a security scanner for php.ini

I do a lot of talking at conferences and in the articles I write about application security, mostly in PHP. There’s been a resurgence of interest in creating secure applications and some of the best practices around it. There’s lots of examples of bad code out there but thankfully there’s a growing base of good reference materials that show how to Do Things the Right Way too. Most of these focus on good code practices, though, and don’t think too much about something fundamental to the PHP language and key to any installation – the php.ini configuration.

PHP’s configuration has quite a few settings (and is getting more all the time) so it can be confusing to have to keep it all straight and be sure you’re “thinking secure” in your app’s setup. There’s lots of sites out there that offer recommendations about how you should set up your config file to follow along with the best security practices, but they’re either all the same thing (copy and pasted?) or refer to settings that are now deprecated. So, in an effort to make it easier for developers (and sysadmins) to set up a php.ini file with a more secure configuration, I created the “iniscan” tool (catchy name, huh?).

I want to thank Ed Finkler for the foundational work he did on the PHPSecInfo project a few years back. PHPSecInfo was a web-based tool that you could load in a browser and report back similar information as what the iniscan tool reports. A lot of the rules in the iniscan tool are inspired by the ones he defined.

The tool runs from the command line and evaluates the php.ini file you’ve given it and evaluates it based on a set of pre-defined rules to provide a pass/fail grade on your current configuration. The goal behind it was to create something that was easy to install and easy to use to reduce the barrier for adoption and lead to an increased awareness about what a hardened php.ini looks like.

You can install it using Composer and call the command line “scan” command to get the results. They look something like:

== Executing INI Scan [11.09.2013 01:51:13] ==

Results for /private/etc/php.ini:
============
Status | Severity | Key                      | Description
----------------------------------------------------------------------
PASS   | ERROR    | session.use_cookies      | Must use cookies to manage sessions
FAIL   | WARNING  | session.cookie_domain    | It is recommended that you set the default domain for cookies.
PASS   | ERROR    | session.cookie_httponly  | Setting session cookies to 'http only' makes them only readable by the browser
FAIL   | WARNING  | session.save_path        | Path /tmp is world writeable

[...more test results...]

15 passing
6 failure(s)

Each of the tests gets a pass/fail grade with a bit of color-coding to help the really bad issues stick out a bit more. It looks at settings like:

  • session.cookie_httponly
  • register_globals
  • safe_mode
  • allow_url_fopen
  • expose_php
  • register_long_arrays

…and more. The tool, by default, reports back the information in a “table” output directly back to the command line. There’s options you can pass in that will change the output format into something a bit more machine-friendly (like JSON and XML).

If this sounds interesting to you, check out the github repo for it and try out the latest version (v2.5 at the time of this post). I definitely welcome feedback so I can help make this an even better tool for the PHP community overall. Many thanks to the PHP community members that have already contributed back to the project – Eric Hogue, Jeremy Cook, Hari KT and Alexandru G!

iniscan