Semantic Tests for XSRF

I've been noodling over ways to implement a semantic check for XSRF, and unfortunately, unless you're in a place where you have a single development environment and well-defined methods for dealing with things, there's not a good one (that I've discovered yet).

Most of the ideas I've worked through have started on the presentation side. On the presentation side, a single type of check gets coverage from black box and white box testing. The rules I had come up with initially became very complex as I tried to reduce false-negatives.

The idea is similar to the OWASP CSRF Guard, except the benefit of the CSRF Guard is that they know the business rules, so it doesn't have to be generic.

• For all forms, find hidden inputs with a name with token in it, and a value with a suitable amount of entropy
• If the previous test fails on any form, test to see if there's a token in the action of the form. Blackbox, refresh the page to see if that token changes. Whitebox, use logic tests to determine if the token is generated automatically with a sufficient random library.
• If the previous test fails, perform the same test on the names of the elements in the form. This is susceptible to false negatives because lots of places will allow editing several "rows" on a single page, so the element names would include the key of the row in the names for each element in the row.
• For all links on the page, if there are parameters, determine if there is more than one, if one of them looks like a token. (This is also very susceptible to false negatives because many frameworks use path info rather than parameters to pass values back).

So no matter what I came up with, the more I tried to be generic, the more false negatives I would get because "suitably random" values could end up in the form anywhere.

I think I'm gonna love XSRF - the more we try to automate the discovery of it, the more we realize that there just exist flaws that take a real person to find.