Cookie Forcing protection made easy

I wrote a post about CSRF tool and readers noticed an intentional mistake in it — storing a token in a plain cookie can be exploited with cookie forcing (like cookie tossing we saw on github, but works everywhere). TL;DR With MITM attackers can replace or expire any cookie (write-only)

Actually I don't think it's mistake in CSRF protection design, I still think problem is about horrible cookies design. But we got to deal with current situation, and taking into account this feature I came up to concise and effective protection.

At first glance it might look ugly. But web is ugly so it's OK.

Step 1. We simply put csrf_token value into session. Wait, we do not store it in database, because it's pointless. We do not store it in signed cookie either like Rails do (this is also overwork).
I propose to literally store csrf_token in session cookie:
sid=123qweMySeSsIon--321csRFtoKeN
You only need a middleware on top of the stack slicing the token after --.

Step 2. Attacker still can fixate the whole session cookie value (sid + csrf token). So always refresh csrf_token after login to make sure csrf_token wasn't fixated.

Can you see anything simpler than this trick? I guess everything using two separate cookies will require signatures and cryptography with server secret. Too much work for a design mistake W3C made.

Although CSRF protection on its own is not popular, cookie forcing protection is way less popular — don't be surprised how many websites/frameworks are vulnerable. How to check: it is vulnerable if you can replace csrf_token cookie (use Edit This Cookie) not breaking session or csrf_token remains same after login.

For example Django framework (csrftoken cookie is not integrated with session), twitter (doesn't refresh authenticity_token after log in, so it can be fixated), etc.

Google Reader is dead, make sure to follow me on another website.

Camjacking: Click and say Cheese

on reddit/HN
This post in based on an interesting trick by @typicalrabbit.

UPD: This has been known since 2011, but not fixed yet. Why?! I made a PoC to demonstrate the severity.

TL;DR this works precisely like regular clickjacking - you click on a transparent flash object, it allows access to Camera/Audio channel. Voila, attacker sees and hears you.

This is not a stable exploit (tested on Mac and Chrome. I do use Mac and Chrome so this is a big deal anyway).

Your photo can be saved on our servers but we don't do this in the PoC. (Well, we had an idea to charge $1 for deleting a photo but it would not be fun for you). Donations are welcome though.

Proof of Concept (not safe for work a bit)

Wait a minute! Hire us for security stuff.