Meaning of "HTML form with no apparent XSRF protection"

[GoogleCodeExporter]

These were all for the URL http://x.x.x.x:4000/foo/search?q=1.

I guess the high-level question is: what is this referring to, a form on the 
page specified or the search form that led to this URL? I'm guessing the former 
(the search action is just a GET).

In the responses, I couldn't find any POST forms that didn't have a hidden 
authentication token field. The token doesn't change, though - is that what's 
being complained about? It's constant for the session. We're (deliberately) not 
dynamically generating tokens that e.g. time-bound the form validity, if that's 
what's implicitly being suggested.

Original issue reported on code.google.com by yaa...@gmail.com on 22 Oct 2010 at 11:58

[GoogleCodeExporter]

Please don't file questions as bugs; feel free to ping me at lcamtuf@gmail.com, 
instead.

All HTML forms with no XSRF protection are listed in the report, and the 
specified URL is the location at which that form appeared in HTML source. It's 
up to you to review this list and decide which ones are of any concern, and 
which ones aren't, because this can't be settled programatically. 

Token detection is done heuristically - so if the form in question does have 
such a token, this may be a false positive; in this case, it would be good to 
see the format of this token, and the framework that generated it.

Original comment by lcam...@gmail.com on 23 Oct 2010 at 12:45

• Changed state: Done

[GoogleCodeExporter]

<div style="display: none;"><input id="_authentication_token" 
name="_authentication_token" type="hidden" 
value="166285680026022364863639886916273215517" /></div>

The framework is Pylons.

Original comment by yaa...@gmail.com on 23 Oct 2010 at 1:31

[GoogleCodeExporter]

I confirmed that 130874260013274 is a valid XSRF token in skipfish 1.69 beta. 

There must be some other problem with this; is that the only form on the page?

What version of skipfish are you using?

Original comment by lcam...@gmail.com on 26 Oct 2010 at 8:45

[GoogleCodeExporter]

Err, 166285680026022364863639886916273215517 even.

Original comment by lcam...@gmail.com on 26 Oct 2010 at 10:27

[GoogleCodeExporter]

Yes, there's one other form earlier on the page, and it has no auth token but 
it's a GET form.

I'm using skipfish 1.69b.

One thing I noticed is that for some reason null characters are appearing in 
the response - could this be, e.g., prematurely terminating skipfish's 
analysis? I'm not sure how this is possible, but they're there in the .dat 
files and in the skipfish web interface.

$ head -49 /tmp/skipfish/c0/i0/response.dat|tail -1|xxd
0000000: 2020 2020 3c66 6f72 6d20 6d65 7468 6f64      <form method
0000010: 3d22 4745 5422 2061 6374 696f 6e3d 222f  ="GET" action="/
0000020: xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx  xxx.xxx.xxx.xxx/
0000030: 7365 6172 6368 2220 6964 3d22 7365 6172  search" id="sear
0000040: 6368 5f66 6f72 6d22 000a                 ch_form"..

Original comment by yaa...@gmail.com on 26 Oct 2010 at 11:57

[GoogleCodeExporter]

Yes, skipfish also complains about no XSRF tokens on GET forms. While in 
principle, GET forms should not be state-changing, way over 50% of all web apps 
ignore it, so I decided it's better to design it this way.

Yeah, that \x00 is a limitation of the analyzer, I need to get that fixed (it 
has no bearing on the outcome, though - just on logging).

Original comment by lcam...@gmail.com on 27 Oct 2010 at 12:02