[pLog-svn] Anti CSRF solution

[Matt Wood]

On Nov 25, 2007 4:26 PM, Ahmad Saleh <ahmadfds at gmail.com> wrote:
> Hi Matt
>
> I just have some questions and some notes about what you say here.
>
> > 2. Does not protect against CSRF attacks from your site, it infact
> > will release your "sensative" token to any actual CSRF attacks.
>
> What do you mean by "from your site"  ??
>
>
> >
> > 3. This will also likely confuse search engine crawlers.
>
> As Mark say, it just for admin pages, so there is no confusing for search
> engine.
>

The aim of this script is to make certain pages (and their metadata)
inaccessible in subsequent requests, whether it be from a link on your
site or a link from any other site by requiring a specific nonce to be
present in the request to that page.

I didn't read the whole thread, so my apologies to Mark. If this is
just for the admin pages, then I also have to say this would be an
esoteric layer of security. However the inclusion of a nonce into our
admin actions might have a few useful functional side effects.

Since LT has session based authentication, there are only two real
threats via CSRF to the admin section: one would be the theft of the
session id (via cookie or other means); the other would be a user that
is currently logged-into LT clicking or visiting a page with a very
targeted malicious request (delete a post).

The first is infeasible without specific web application
vulnerabilities... since without malicious javascript execution within
the LT installations domain (or some browser flaw), or in other words
a full blown XSS vulnerability, the theft of the session id (via
cookie) is much harder.

The second highlights a security flaw that many web applications
currently have (trusting any HTTP requests "if" a user is logged in).
But it is also rather difficult to exploit unless the user is foolish,
or there are other vulnerabilities in the LT domain and have a
targeted attacker.

The second attack is what CSRFx attempts to solve. However, since the
nonces CSRFx uses are valid on any URL within 30 minutes the
protection it provides is minimal. This type of nonce protection
should be tightly coupled with the action with which it is associated
(as per what Reto hinted at).

The functional benefits of an implementation like this would include:
a way to limit actions to only being executed once (For example,
double posting or something similar), enforcing request action
execution order (think ajax), and probably more.

-Matt