Some ideas!

[bp0lr]

Hi mate! I want to hear your opinion about some things.

1) I believe the best option could be to move out the xss scanner to his own bav to have a better understanding of what you are trying to find. Then we can split again xss on differents bav modules for each type. (blind, etc). Whit this, we will also need to move detection and extra checks to his own files. I honestly feel that the code on scan.go is a bit complicated to follow.

2) Would be great to have the possibility (via configuration or using a command-line flag ) to disable some feature like parameter mining, parameter analysis, or Static analysis. Sometimes you just want to test on the current parameter list and each default option adds a lot of extra HTTP queries and that could finish on your ip blocked/banned.

let me know. :)

[github-actions[bot]]

Thank you for your first issue report :D

[hahwul]

@bp0lr Hi mate :D

Ultimately, that's good, but eventually it'll be a scanner that can diagnose something comprehensive.

This is the direction I initially considered. I was going to create/using a number of scanners that could diagnose each individual vulnerability. (e.g dalfox, blahblah, ~~ and using gospider, gobuster, etc...)

and a combined scanner. (using go-module!) Of course, it's very big project, so it's going very slowly.

Oh, and dalfox support on/off with flags for functions that use some resources! However, parameter analysis is the most basic logic, so I didn't exclude it. Without this, the XSS Scan itself is meaningless.)

[hahwul]

@bp0lr If we consider the change to an integrated scanner within this project, it's probably going to be a big work. The design direction itself is different.

Maybe... we need to separate them all by scanning module, and we need to create a number of module to verify them. (e.g for RCE, delay check, oob check, pattern base check)

At this size, it may be simpler to create a new project and use the xss section as a dalfox module (this is the direction I've considered).

[hahwul]

@bp0lr HI mate, I want to ask for an opinion. If you look at the current on/off options --only-discovery has this type of option naming. How about adding options in skip-blah blah format? For example...

--skip-xss-scanning
--skip-mining-dom
--skip-mining-dict
...

The output side is in no-blahblah format(e.g --no-color no-spinner), but I don't know which wording is more suitable.

Formats I just thought of...

• --skip-blahblah
• --no-blahblah
• --pass-blahblah

It is also related to this issue https://github.com/hahwul/dalfox/issues/126

[hahwul]

@bp0lr And, I'm planning to release 2.2.0 next week, but if you have any reference to the development content or schedule, please let me know!

[bp0lr]

@bp0lr Hi mate :D

Ultimately, that's good, but eventually it'll be a scanner that can diagnose something comprehensive.

This is the direction I initially considered. I was going to create/using a number of scanners that could diagnose each individual vulnerability. (e.g dalfox, blahblah, ~~ and using gospider, gobuster, etc...)

and a combined scanner. (using go-module!) Of course, it's very big project, so it's going very slowly.

sure, I understand your point. I think you are right, we already have tools to search/confirm many vulnerability types, there is no point in starting a new big project to do the same than others. Maybe will be better to focus on have the best XSS scanner with some nice extra features.

Oh, and dalfox support on/off with flags for functions that use some resources! However, parameter analysis is the most basic logic, so I didn't exclude it. Without this, the XSS Scan itself is meaningless.)

I'm going to test and review how many queries dalfox sent before start the XSS scan in self.

[bp0lr]

@bp0lr If we consider the change to an integrated scanner within this project, it's probably going to be a big work. The design direction itself is different.

Maybe... we need to separate them all by scanning module, and we need to create a number of module to verify them. (e.g for RCE, delay check, oob check, pattern base check)

At this size, it may be simpler to create a new project and use the xss section as a dalfox module (this is the direction I've considered).

having in mind what you said, maybe we can move out the xss logic from scan.go and have his own module. Would be much easier for adding new features or testing logic. This will separate the "detection / found" logic also.

[bp0lr]

@bp0lr HI mate, I want to ask for an opinion. If you look at the current on/off options --only-discovery has this type of option naming. How about adding options in skip-blah blah format? For example...

--skip-xss-scanning
--skip-mining-dom
--skip-mining-dict
...

I love the --skip-something notation. looks very clear about what you are going to do.

126

I think this is what I was talking about in my first msg. dalfox keeps trying to find new injection points doing a parameter mining even when you disable the option. That will add a lot of new requests to the scan and make it much slower.

[bp0lr]

@bp0lr And, I'm planning to release 2.2.0 next week, but if you have any reference to the development content or schedule, please let me know!

great! I will love to see the new features. thanks mate!! 💯

[hahwul]

@bp0lr Thank you so much for all your opinions and ideas! As you said, I will try harder to be the best XSS tool!

I'll release 2.2.0 after apply --skip-something notation! Have a nice week and be safe from COVID!

Thanks mate 😘

[bp0lr]

great!! just let me know how can I help!

💯