|
|
|
|
|
Zimki 1.12 released |
|
|
|
|
|
|
Stig Brautaset
on Tue Jun 12 2007 15:27:18 GMT+0100 (GMT)
We've just released Zimki 1.12, mainly containing changes under the hood. However, as part of our ongoing effort to keep your data out of harm's way we've also introduced another security measure. The first part of this is that all HTTP POST requests now require a cryptographic token. The second part is that all calls that change state in the portal have to be POSTs.
Together, these measures guard against cross-site scripting attacks. Without them, you could put some client side code on site A that posts a request to site B which does something malicious. Client side code running client-side on site A cannot read authentication data stored in a cookie issued by site B. However, if poor Alice happens to be logged into site B at the time, the request could be honoured and her data deleted.
This is where the token comes in. Site B is augmented such that requests that change state on the server requires a secret token. Forms on site B come with a hidden field with the correct nonce filled in, so normal users don't see a change. The only impact is that people can no longer destroy or hijack your data from a client-side POST operation from a different web site.
|
| comments: |
Daniel LaLiberte |
on Wed Jul 04 2007 17:47:14 GMT+0100 (GMT)
How does this POST requirement for changing state on the server impact AJAX types of applications?
Requiring POST to cause a change on the server makes perfect sense regarding the intended semantics of POST vs GET. (PUT is another option by the way.) But we should be able to POST changes without replacing the entire page, to support better user interaction. Is this still possible?
|
Tom Insam |
on Thu Jul 05 2007 10:18:13 GMT+0100 (GMT)
These changes apply _only_ to the Zimki portal, not anything you build yourself in Zimki. You're perfectly able to do the same thing yourself for your applications, of course, but we're not enforcing it on you.
|
|
leave a comment
|
|
|
|