Tag Archives: Computing

Secure localStorage? Now that’s a good question!

Nicholas Zakas posted today a very very interesting post about one of the most interesting and useful features in HTML5 – localStorage. What’s really impressing is that everybody’s using it, including me, with no fear of security. But security is never strong enough, so it’s quite interesting to listen up the guru!

I recently posted a localStorage wrapper for jQuery in form of a simple plugin. What I miss there is the security.

Definitely I’ve to change it a bit!

Should I do Something Only Because Crockford Says So?

Crockford says: “Don’t do that, please stop doing it!?” It may be related to JavaScript, YUI, CSS or whatever. PPK recently posted about browser prefixes with the same intonation. OK, fine, it’s difficult to maintain, it’s ugly but my job is to make the site look as nice as possible.

I agree with Crokford that only with copy/paste now JavaScript has the reputation of badly standardized language with no programmers that understand it at all. It’s true, but however this maybe made JavaScript so popular, now all the libraries come with that abstraction in mind and this gap seems to be smaller.

In addition I’ll say that’s fine if Crockford or PPK say something like that, but the primary goal of every web developer is not to be in good relations with Crockford, but to satisfy clients! I’d like to repeat – clients!

Secure Forms with Zend Framework

Maybe the correct title is not “with Zend Framework”, but “with PHP”, because the general approach I used is purely PHP and no Zend Framework dependency is used. However let me mention that ZF allows you to build forms with Zend_Form, which gives you an abstraction over the HTML forms with many goodies like validation, filtering and protection.

Zend_Form and Zend_Form_Element_Hash

Although the technique I’m using is doing the same thing, note that in ZF there’s a Zend_Form_Element_Hash which generates and validates the form, thus protecting you from CSRF attacks. The thing is that I didn’t use it because the form I’m protecting is not generated with Zend_Form, and I cannot benefit from everything ZF is giving to me. However you can easily reproduce the basic strategy with every form and every framework till it’s written in PHP.

What’s the solution?

It’s pretty simple and it’s described many many times around the web, simply generate a random hash, a possible solution is to use uniqid in combination with mt_rand and md5, thus you’d get quite strong hash.

Step two is to pass this generated hash, also stored in the session in a hidden value of the form. Of course now the most asked question is: but that’s visible to the source and thus everybody will have a valid hash.

There’s the trick. OK everybody will have a valid hash, but on submit the hash is validated against the SESSION variable, and as you know the session is specified between the browser (client) and the web server. Although the attacker may have a valid hash he must execute the attacking script from the same domain, possibly with the same browser, which makes the task rather difficult.

An Example

Let me show a breve example, it may help make things clearer.

1. First step – start the session

<?php
session_start();
?>

2. Second step – validate the form against the $_SESSION and generate a valid token

<?php
if (isset($_POST['name']) && $_POST['token'] == $_SESSION['token'])
    echo $_POST['name'];
else
    echo 'dont hack';
 
$_SESSION['token'] = md5(uniqid('test', true));
?>

3. Third step – make a form

<form method="POST" action="">
<input type="hidden" value="<?php echo $_SESSION['token'] ?>" name="token" />
<input type="text" name="name" value="stoimen" />
<input type="submit" name="submit" />
</form>

Demo here.

For more to test this you may try to make the same form somewhere else on the web and to point the action to http://www.stoimen.com/projects/php.secure.forms/! Without the session validation it’s absolutely sure you can post on the attacked server.

P.S. Now I’ve to admit that this have nothing to do with Zend Framework, however it’s good practice and thus may be used with every framework.

jQuery: what about this.title?

In my last post I was talking about the short way to access the id attribute:

this.id;
this.attr('id'); // this is the same but slower

Beside the most important thing that this is the slower notation, you get also larger notation, which in JavaScript is really pain.

What’s interesting is that you can access almost every attribute of an element with that notation. Take a look at the following example:

<img src="image.jpg" title="test" />

and than

$('element').title

This is much faster and quite nice in place of

$('element').attr('title');