Forms w/o an action attribute are not submitted

[GoogleCodeExporter]

Hi Michal,

I noticed that if there is a form on a webpage which looks like
<form method="post">
  ... form content ...
</form>
then skipfish completely ignores this form and don't even tries to submit 
anything. Even when I used the auto-complete rules for this form.

Once I've added the action attribute it started submitting this form.

I guess many forms omit action being supposed that it'll be submmitted to 
the current location.

Original issue reported on code.google.com by alex.d.r...@gmail.com on 31 Mar 2010 at 10:54

[GoogleCodeExporter]

Good point. This is fixed in version 1.28, coming soon.

Original comment by lcam...@gmail.com on 31 Mar 2010 at 7:31

• Changed state: Fixed

[GoogleCodeExporter]

FYI:
Just downloaded the newest 1.28b and the bug does NOT seem to be fixed. It 
still 
ignores such kind of forms:
<form method="post">
or
<form action="" method="post">

Original comment by alex.d.r...@gmail.com on 2 Apr 2010 at 8:27

[GoogleCodeExporter]

Yeah, sorry. Really fixed in 1.29.

Original comment by lcam...@gmail.com on 2 Apr 2010 at 5:10

[GoogleCodeExporter]

That's weird... but it still doesn't seem to be fixed. Checked on this forms:
<form method="post">
and
<form method="post" action="">

Original comment by alex.d.r...@gmail.com on 5 Apr 2010 at 12:57

[GoogleCodeExporter]

Both cases work for me. Please double check you're using the current version, 
and that 
the page with the form itself is being crawled. You can use 'make debug' to get 
a raw 
crawl log, too.

Original comment by lcam...@gmail.com on 5 Apr 2010 at 5:06

[GoogleCodeExporter]

Hmm... I think I got it. It didn't work b/c I used -I param.
However it's probably a bug b/c my -I value is matching the form's URL.

It starts to submit when I either remove -I or add -I="" (empty string) 

Original comment by alex.d.r...@gmail.com on 5 Apr 2010 at 5:41

[GoogleCodeExporter]

Michal,

If you don't think that this is a bug, can you please tell me how can I check 
the 
exact set of pages www.site.com/xxx1, www.site.com/xxx2, www.site.com/xxx3, ... 
so 
that skipfish will send the forms on the pages listed and will ignore all other 
URLs.

When I try this: `skipfish -I 'xxx' www.site.com/xxx1` it doesn't see the auth 
forms 
due to the bug described above

When I try `skipfish -I 'xxx' -I '' www.site.com/xxx1` it starts submitting the 
forms 
but it also crawls every other page on the site (e.g. www.site.com/yyy) which 
is not 
desired.

Thanks.

Original comment by alex.d.r...@gmail.com on 6 Apr 2010 at 9:36

[GoogleCodeExporter]

It would be a bug, but I can't reproduce: providing -I rules that *both* allow 
the 
scanner to reach and parse the page containing the form, and then allow the 
scanner 
to submit to form target, should work. I just tested it in the scenario you 
described, and I could not reproduce.

There's one corner case where you might be running into a problem: if the form 
is in 
index.html, and you have -I http://www.example.com/index.html; skipfish will 
attempt 
to fetch / on the server first for the purpose of calibrating 404 checks - and 
will 
not explicitly parse /index.html later on, because the response will be 
identical 
with what it already examined. However, the form returned on / will have a 
submit 
target that does not match the -I rule, and will not be submitted.

If that sounds like your problem... well, that's sort of the price of not 
providing 
action= URLs on forms, I am not sure how to address it without causing side 
effects.

Original comment by lcam...@gmail.com on 6 Apr 2010 at 9:50

[GoogleCodeExporter]

Yeah, that's exactly my case. What's a pity.
Actually I'm going to test a part of a site which shows login form on every 
request 
page until user is logged in. So it shows the same form for /xxx and / until 
user is 
logged in. This is technically just as your index.html example.

Ok, I believe that's not an easy fix so I'll skip trying to make this scan for 
now. 
However in my personal feelings that's not a very rare case when a huge portals 
can 
show the same login page on any request until you're logged in. Probably 
grabbing 
cookies can help in such cases (but not in mine - cookies expire too fast). But 
at 
the same time such behavior isn't obvious until the close investigation.

Anyway, thanks for your help, and thanks for the great tool - it's still very, 
very 
helpful and efficient.

Original comment by alex.d.r...@gmail.com on 6 Apr 2010 at 11:46