StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>This approach obviously makes assumptions and is not invincible. All calculations are done on the client, and the server does some background checks to find out if the request could have been forged. Like any other client-based approach, this is not deterministic but makes it very hard for a lying client.</p> <p>The main assumption is that long-lived HTTP connections are much faster for transmitting data, even negligible in some cases depending on the application context. It is used in most online trading systems as stock prices can change multiple times within a second, and this is the fastest way to transmit current price to users. You can read up more about <a href="http://en.wikipedia.org/wiki/Comet_(programming)" rel="noreferrer">HTTP Streaming or Comet</a> here.</p> <p>Start by creating a <a href="http://en.wikipedia.org/wiki/Reverse_Ajax" rel="noreferrer">full-duplex</a> ajax connection between the client and server. The server has a dedicated line to talk to the client, and the client can obviously talk to the server. The server sends the puzzle, and other messages to the client on this dedicated line. The client is supposed to confirm the receipt of each message to the server along with its local timestamp.</p> <p>On the server generate random tokens (could be just distinct integers) after the puzzle has been sent, record the time when each token was generated, and pass it over to the client. The client sees the message, and is supposed to immediately relay this token back along with it's local time of receipt. To make it unpredictable for the client, generate these server tokens at random intervals, say between <code>1</code> and <code>n</code> ms.</p> <p>There would be three types of messages that the client sends to the server:</p> <pre><code>PUZZLE_RECEIVED TOKEN_RECEIVED PUZZLE_COMPLETED </code></pre> <p>And two types of messages that the server sends to the client:</p> <pre><code>PUZZLE_SENT TOKEN_SENT </code></pre> <p>There <em>could</em> be a lot of time variation in the messages send from the client to the server, but much lesser in the other direction (and that's a very fair assumption, hey - we have to start somewhere).</p> <p>Now when the server receives a receipt to a message it sent, record the client time contained in that message. Since the token was also relayed back in this message, we can match it with the corresponding token on the server. At the end of the puzzle, the client sends a <code>PUZZLE_COMPLETED</code> message with local time to the server. The time to complete the puzzle would be:</p> <pre><code>PUZZLE_COMPLETED.time - PUZZLE_RECEIVED.time </code></pre> <p>Then double check by calculating the time difference in each message's sent vs received times.</p> <pre><code>PUZZLE_RECEIVED.time - PUZZLE_SENT.time TOKEN_RECEIVED.time - TOKEN_SENT.time </code></pre> <p>A high variance in these times implies that the response could have been forged. Besides simple variance, there is lots of statistical analysis you can do on this data to look for odd patterns.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload