SolomonSklash / chomp-scan

A scripted pipeline of tools to streamline the bug bounty/penetration test reconnaissance phase, so you can focus on chomping bugs.
https://www.solomonsklash.io/chomp-scan-update.html
GNU General Public License v3.0
393 stars 76 forks source link

update #40

Closed Sy3Omda closed 5 years ago

Sy3Omda commented 5 years ago

changes in ffuf as i know from ffuf github -fc string = Filter HTTP status codes from response So i think it is better to filter needed status codes only which would be 200,302 okay but 301 Moved Permanently !! why would i need this status code url in info gathering ? and let`s agreed we all get status code info from https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

Sy3Omda commented 5 years ago

I like most of these changes, especially the threads for bfac. I didn't realize it could use threads. However, there are some changes I don't think are needed.

  • For bfac, the default detection technique is already all.
  • I like excluding 400 status codes, but in the interest of providing as much info as possible, I think 403s should stay. Their existence could provide information, even though they are not accessible. Same with 503s. Everything else looks great, and I appreciate your contributions.

I agree with you. 403,503 should stay BUT ARE YOU SURE For bfac, the default detection technique is already all. as i know --detection-technique all uses both methods for HTTP Status Code checks, and the HTTP Content-Length. as mentioned in author github https://github.com/mazen160/bfac#frequently-asked-questions

Sy3Omda commented 5 years ago

changes in DIRSEARCH I think it is better to add 404 Not Found code to exclude from results.

SolomonSklash commented 5 years ago

Ok, so for ffuf. I looked at the options and at which status codes I am including. Here's what I think we should do. Instead of using -fc and -mc, which excludes and matches status codes, let's just exclude the response codes we definitely don't want to see, and everything else should be included by default. So which codes do we exclude? I think 301, 302, 404. Everything else could have some value or be useful. What do you think?

For bfac, try running bfac -h. Here's the output:

Technique to verify the availability of the file. (options: status_code, content_length, all)  (default: all)

This says that the default is already to use all detection techniques. So I think we're good here.

For dirsearch, you're right, we need to exclude 404. Good catch. I think we can add 301 as well, to match the codes for ffuf.

Will you submit each change as a separate pull request? That way it's easier for me to follow the changes and keep track of what's going on.

Thanks for all your input, really appreciate it!

Sy3Omda commented 5 years ago

Ok, so for ffuf. I looked at the options and at which status codes I am including. Here's what I think we should do. Instead of using -fc and -mc, which excludes and matches status codes, let's just exclude the response codes we definitely don't want to see, and everything else should be included by default. So which codes do we exclude? I think 301, 302, 404. Everything else could have some value or be useful. What do you think?

For bfac, try running bfac -h. Here's the output:

Technique to verify the availability of the file. (options: status_code, content_length, all)  (default: all)

This says that the default is already to use all detection techniques. So I think we're good here.

For dirsearch, you're right, we need to exclude 404. Good catch. I think we can add 301 as well, to match the codes for ffuf.

Will you submit each change as a separate pull request? That way it's easier for me to follow the changes and keep track of what's going on.

Thanks for all your input, really appreciate it!

I agree with you some status codes is informative however it come out with service unavailable for example. for pull request !! apology my ignorance using github couz this the first time BUT i will comment my notice in separated pull request later.

SolomonSklash commented 5 years ago

No worries. I'm not very familiar with merging pull requests in GitHub, other people may know how to handle it but I don't.