wpdetect
wpdetect copied to clipboard
IamLizu
Made some improvements
** What did I do? **
- Added multi-threading support
- Added standard input as a possible way to supply targets to the tool
- Made some optimizations
Hey @serialfuzzer, great work man. But if you could maintain the project installation steps and other instructions, I can merge the PR and publish the new version in PyPi.
Hi @IamLizu, Thank you! :) I will make some more changes to optimise it and then I'll let you know here.
Hi @IamLizu,
Does these changes look good or you want to add something to it? I'm going to do a speedrun to implement features listed below
To implement
- Use 1000 requests per thread
- Each request should be sent in an asynchronous way
- Implement two methods: i. Fast (Some false positives but blazingly fast) ii. Slow (Highly accurate but slow)
Fast mode (default) Will send 1 request and analyse it for wordpress patterns
Slow mode Will send multiple requests and analyse it for wordpress patterns
User interface design -slow option should trigger the scans in slow mode -t option should specify the number of threads
Input options Three methods to supply input:
File Standard input Command line argument If all of the input methods contains values then combine the targets from all the sources instead of priotizing one and ignoring other
Some additional optimisations Remove duplicates from the targets container to avoid sending multiple requests to the same URL
Create test scripts
Just realised that multithreading in Python does no good due to the GIL. Regardless, we can keep the code changes in hopes that one day, python maintainers would launch a thread-safe environment. I need to update the slow method now. Slow method will use the old legacy function
I looked into the changes a bit from here and I think we do not need to include the local installing instruction. Let's keep the pip one only.
And for an example URL to test the sites, let's not use iamlizu.com because that no longer have WordPress.
Hi, @IamLizu Sure, you can start reviewing the code.
Let's use https://www.malcare.com/ then. I'll update the readme
Using multiple-threads is making it slower by couple of seconds. I think it's because of the GIL. I think requests has to be sent all at once in a multi-threading asynchronous way and then use multiprocessing to to parse those results for wordpress patterns.
Due to behavior in above mentioned comment, I have set the default number of threads to 1.
I am thinking of removing the README.rst and use the README.md. Seems duplicate, I don't know why I did it back then. Probably because I couldn't figure out something. But we can just remove it now.
Also, I am think of migrating to hatchling build system instead of setuptools. But I will do this myself after merging your PR.
Hi @IamLizu,
Thank you for reviewing.
I will start making the changes now. Also, it's a good idea to make it backwards compatible.
We are using click to parse CLI arguments and options. The entire code base has been rewritten
The difference between old engine and current engine:
Old engine:
- Send multiple requests to observe if a site is wordpress or not
New engine:
- Send one request to observe if a site is wordpress or not
However, the legacy feature will be implemented as slow method of scanning. It has not been incorporated into the codebase yet which is the reason why mode is not documented in Readme.md. However, the script works perfectly with increased speed under default configuration in new method.
I have also implemented the --silent flag. When, --silent flag is sent, the tool will not output banners or additional information besides the URLs using wordpress.
Why I did this?
If an user wants to fetch all the subdomains using wordpress and then bruteforce for information disclosing files than they could just do
$ cat subdomains | wpdetect --silent | bruteforceSensitiveFiles
I think we should also add -v option that displays current version. What is your opinion on this?
I noticed the use of click. I have also used it in another library.
The silent and v flags are good. I am still at work. I will review these tonight.
I am also thinking that --ports flag should be added at some point. Maybe let the user specify which ports to scan too?
Second thought: This won't be a good idea. Let's keep the tools segmented. A user could just add another port in their input file. For example:
https://google.com:1337/ https://youtube.com:8080
@serialfuzzer I feel that we need a place to discuss our plans and visions in a bit more organized way. I would love if you please join this following discord channel.
https://discord.gg/g4hReRSsgN