Skip to content
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

false positive #10

Open
ghost opened this issue May 1, 2018 · 3 comments
Open

false positive #10

ghost opened this issue May 1, 2018 · 3 comments

Comments

@ghost
Copy link

ghost commented May 1, 2018

Does this tool reported False Positives before?? I came across two endpoints reported vulnb for XSS but i was not able to check that manually! so i thought it might be false positive.

can you help out please?

Thanks

@elkokc
Copy link
Owner

elkokc commented May 1, 2018

Hi!
Yes, there are some cases that actually may give false-positive error. So, its better to make manuall tests, before submit your finding.

@shvetsovalex
Copy link
Collaborator

Hi, Buffer0overflow!
Please, can you describe endpoints with false positive reports? We want to impove our plugin, so it will be very useful if you describe false positive situations.

Thanks

@ghost
Copy link
Author

ghost commented Jun 4, 2018

Hi shvetsovalex ,
I came across several false positives with reflector where i can see it was possible to avoid.
below is one example ;

  • inside cookies values - below is taken from the report inside burp ;
    ==========================
    Issue detail
    Reflected parameters in ALL:
    vuid - reflected 3 times
    ==========================
    the tool functionality as i understand it is to search for certain pattern inside requests , then check responses - if same pattern found , then it will report possible XSS injection.
    i have enabled aggressive mode and context check in plugin options , but still got this false positive because the server sanitized <> chars - the plugin reporting could be improved as i think if it checks for <>;'/" chars inside responses and see if they are escaped or not.
    what i was not able to understand is why context analyze was not able to do this test in such scenario and check for special char reflections thus avoid reporting such cases.

other example ;

  • inside a header
    ============================
    Issue detail
    Reflected parameters in HEADERS:
    context%5Btype%5D - reflected 2 times
    ============================
    This was little more naive to report by the tool as the request body included a certain word " report" , then this report reflected by in response as part of URL address https://xx.xxxx.net/api/30/csp-**report**/?sentry_key=xxxxxxx

there are more reports i came across but i was working on temp project inside burp and didn't same them.

i have to say that i like the tool a lot and i think scope for improve is big. I'm also a beginner who started a few months ago in hacking and infosec , so my assessment might not be as you expect from pros.

Thanks and regards,
B0overflow

@ghost ghost closed this as completed Jun 4, 2018
@ghost ghost reopened this Jun 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants