I’m not trying to invite attackers by posting this. My goal is to provide a (hopefully) working example from a real world, high-traffic site. I think the people exploiting XSS have a fairly good idea what they are doing and, too often, the people attempting to secure their sites don’t. Since AMO is open source I’m not sharing anything that isn’t available already anyway (side note: please don’t depend on security by obscurity).

Firstly, this chunk of code sits in CakePHP’s bootstrap.php and runs very close to the start of every request:

if (array_key_exists('url',$_GET) &&
    !preg_match('/\/api\//', $_GET['url']) &&
    preg_match('/[^\w\d\/\.\-_!: ]/u',$_GET['url'])) {
    header("HTTP/1.1 400 Bad Request");
    exit;
}

Since a lot of XSS attacks are launched from the URL we implemented this simple white list of characters we’ll allow. If anything outside of that white-list is in the URL we return an invalid request header and die. This isn’t a lot of protection but it does narrow the field of what our application expects and has to deal with (particularly with control characters, high level ASCII, etc.).

The second, and more important section of code is in our app_controller class. We wrote a custom sanitize() function that any string going into one of our views gets run through:

$sanitize_patterns = array(
    'patterns'      => array("/%/u", "/\(/u", "/\)/u", "/\+/u", "/-/u"),
    'replacements'  => array("%", "(", ")", "+", "-")
    );

........

$data = iconv('UTF-8', 'UTF-8//IGNORE', $data);
$data = htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
$data = preg_replace($sanitize_patterns['patterns'], $sanitize_patterns['replacements'], $data);

This code has several important parts and I’ll start with the functions. The first function that modifies the actual data is iconv(). We ask it to convert our data from UTF-8 to UTF-8 which seems unnecessary but the “//IGNORE” part is important – that means it will throw out any characters it can’t represent appropriately. This was added to prevent a proof of concept attack that exploited a C0 ASCII control code character to break the output (discovered on the sla.ckers.org forums).

The next function, htmlspecialchars(), is a pretty well known function and converts special characters to their ASCII equivalents. The second parameter specifically asks it to encode single quotes.

Lastly we use the array of patterns and replacements declared at the beginning to encode a few final symbols, like parenthesis and the percentage sign, into HTML entities.

This system has worked fairly well for a few years now and as issues are discovered we make changes to it. If you’re looking for the latest code please be sure to check our repository. And, as always, if you find any kind of exploit on AMO please let me know!

What we mail back consists of the anonymous ballot, a secrecy envelope, and an outer envelope. The outer envelope has a bar code which identifies who is voting and it also requires a signature on the outside of the envelope. Once the fact the person has voted is counted (note: not what they voted) the outer envelope is discarded and anonymity takes over.

I’ve never liked having to sign the outside of the envelope. It’s always seemed like one more way someone could rip off a signature relatively easily.

Is it that big of a deal though? We sign all kinds of stuff and my general attitude has been that no one really looks at signatures these days anyway. Mix that idea with other people coming to the same conclusion, add my general laziness and I guess I let my signature slop around on my ballot envelope. Also, apparently they actually look at those. I got a letter in the mail today that said:

We were able to match your signature and your ballot was counted from this election, however it appears that your signature has changed since you last registered to vote.

They include another registration card for me to update my signature. I’m curious how they matched my signature despite it changing and, since they could match my signature, why am I being asked to sign another card? My guess is it failed a computerized test and had to be reviewed in person. That just raises the question, why can’t they scan the new signature and add it to the list of matches in the computer?

Anyway, it’s the first time my signature has mattered in a long time and seems to bring relevance to my original concern – putting it on the outside of an envelope makes it that much easier to copy.

On the SVN server the first thing we did was to create a special Verbatim user that can commit to SVN via SSH using a generated key. We copied this key to the Verbatim host which allowed us to commit as the verbatim user without typing a username or password.

The only thing that was added to the Verbatim code was a patch that Dan Schafer cooked up that sets an SVN revision property, translate:author, to the name of the current user. When the user clicks “commit” this property is set and sent along with the commit.

At this point we could commit from the application but it still goes to the application as the Verbatim user. We used SVN’s hooks to take the next step.

The first script we changed was the pre-revprop-change hook. This controls what special revision properties a user can modify when they commit. Our script adds the ability to modify svn:author and translate:author. Before allowing the modifications the script checks if the user committing is the special verbatim user to prevent anyone from committing as someone else.

Next we added a post-commit script that looks for the translate:author property. If it’s found it will take that value, replace svn:author, and remove translate:author; effectively making whatever was in translate:author the real author. This is a non-versioned change which means there is no commit that needs to happen – the new author is set immediately.

With these scripts in place we can commit as anyone from the application and everyone’s credentials stay encrypted and secure.

I don’t know anyone that has the “I submit information that’s not encrypted” option checked. We used to prompt for submitting information that was unencrypted, next we added an option on the dialog that disabled the warning (and was checked by default), and finally we removed the warning by default all together. People submit so much information via searches, surveys, voting, sending quick messages, etc. that it would just get in the way and be ignored.

I’ve noticed lately that a lot of sites are showing login forms on unencrypted pages but submitting them via SSL to their target pages. This is a secure method of logging in but it’s started to train me to not look for a secure connection before I log in and that’s not a good idea in the long run.

I think our current option is too broad, so I’m proposing that we add an option that says “I submit credentials that aren’t encrypted” or a sub-option for the current text that says something about “unless I’m sending a password.”

In more technical language: If a user POSTs a form containing an input of type=”password” to a non-encrypted page we should show a warning.

This would mean regular searches, filling in surveys, anonymous voting and polls would all pass transparently if unencrypted, but when you got to a form with a password you would be warned.

I bounced this idea off a channel in IRC and no one said I was nuts so I figured I’d take it here. It seems like too small of a feature to make an add-on out of but I might if I get some free time. What do you think?