This is a cross-site scripting vulnerability, yes, but client-side crypto does not necessitate cross-site scripting.
This implementation just so happens to not protect against it properly. There are legitimate arguments against client-side cryptography; this is not one of them.
The argument is that implementing crypto within an application that is designed to download and execute untrusted code from untrusted servers and has an extremely large attack service [1] is a difficult if not dangerous task.
I'm using Arduino + TC4 shield for PID and interfacing w/ thermocouples, SSR, and opto-isolators (for front panel switch sensing). Serial to RasPi to web sockets for the frontend.
Also, using sha1_hex(secret+...) and calling it HMAC is a slippery slope (see http://netifera.com/research/flickr_api_signature_forgery.pd...). Although it's seemingly not exploitable due to the structure of the data, look into using a proper HMAC (RFC 2104) to prevent length-extension attacks.
Whoah. That is a good catch. I admit, I skimmed this, saw "hmac_for", thought "I'm not a Perl programmer", and assumed it was HMAC.
Guys, fix this ASAP. SHA1(secret || data) (secret-prefix MAC) is totally insecure. (In practice, every valid forgery to this MAC is going to look like x-y-z-useragent-GIBBERISH-evil-content, but you don't want to be relying on that for your security).
Thank you! This will be closed up by end of this week. As I wrote in the article and in the presentation, one of main points of open sourcing it is to have people smarter than myself look at the crypto and protocols to find any issues like this. It should be fairly easy to close up.