New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lots of false positives #455
Comments
Could you provide the output of the cURL command: |
sure:
|
Might be worth removing any output of the request's URL path in the 404 detection as suggested by @corelanc0d3r? |
The first post (which states that the response is a 404) is not coherent with the second one (response is a 403) ^^ If the final response (i.e after the potential redirects) is a 404, the scanner don't go further and the plugin is considered not present on the target. If it's a 200, 401, 403 or 301 (the 301 is only used for rspec as WebMock does not follow redirects), then the check against the custom 404 and homepage are performed. The exclusion of the content matches the --exclude-content-based pattern provided in the CLI is also performed there. If you really have a 404 as a response (but curl shows a 403), you could filter by using the |
the initial response, using a browser & burp, is 404 a scan with the exclude-content-based argument still produces the same results ( = lots of false positives) |
It's not normal then :/ Can't reproduce it locally, the --exclude-content works and if the response is a 404, it's ignored before the --exclude-content check :| Could you provide the full curl 'operations' ? Furthermore, do you know if this behaviour (custom 404 with part of the url in the form action) is caused by a plugin ? (I tried to look at the wpcf7 plugin w/o success) |
check your mail :) I don't know if this is caused by a plugin, I'll check with the website admin tomorrow and see if he can get me a list of active plugins |
Solution: The site's WAF blocked wpscan because of the user-agent (contains the word "scan"). Supplying a custom user-agent fixed the problem. |
wpscan, trying to detect vulnerable plugins, seems to report a lot of false positives.
Although the 404 page looks the same each time, some places in the html source seem to contain the URL, which means the page is different each time.
Example:
Request 1: http://fakedomain/wp-content/plugins/blah1
In source:
<form action="/wp-content/plugins/blah1#wpcf7-f301-t1-o1" method="post" class="wpcf7-form" novalidate="novalidate">
Request 2 : http://fakedomain/wp-content/plugins/blah2
In source:
<form action="/wp-content/plugins/blah2#wpcf7-f301-t1-o1" method="post" class="wpcf7-form" novalidate="novalidate">
Perhaps it would make sense to remove all references to the URL (full URL and/or just the path?) from the response before checking if it's a 404 or not ?
The text was updated successfully, but these errors were encountered: