Closed GoogleCodeExporter closed 8 years ago
Good point. This is fixed in version 1.28, coming soon.
Original comment by lcam...@gmail.com
on 31 Mar 2010 at 7:31
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
Yeah, sorry. Really fixed in 1.29.
Original comment by lcam...@gmail.com
on 2 Apr 2010 at 5:10
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
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
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
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
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
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
Original issue reported on code.google.com by
alex.d.r...@gmail.com
on 31 Mar 2010 at 10:54