-
Notifications
You must be signed in to change notification settings - Fork 90
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
Filter Bypass #32
Comments
Hi, do we know when this issue will get fixed? Our security team has blocked the usage of antisamy 1.5.7 until this security vulnerability is fixed. |
Hi! Thanks' in advance! |
Hi @nahsra, could you give us some visibility of what your plans are regarding this issue? |
@karan-ramani could you expand on how you tested? I can't reproduce your issue. For instance adding this unit test in
|
@efge That is also what I see.
With as clean result message: CVE-2018-1000643 is using this issue as reference. |
Karan Ramani, Can you please reply to comments above on how to reproduce this issue? Many are reporting that this issue is not reproducible. Your report has gone into CVE database causing lot of automated tools that check for open vulnerabilities on third party software to report this issue as potential risk. |
Can you guys use the following payload and report back the output..? <img src=# onerror=alert(0)// |
@karan-ramani this gets sanitized to an empty string:
|
@karan-ramani please explain how you did your initial tests that led to opening this issue. |
@efge only in this case CleanResults getNumberOfErrors() is 0 and getErrorMessages() does not report anything despite actually finding something and cleaning it up. |
@HaraldWalker So, this is just a bug in error reporting and not a security issue as such as suspicious tags/attributes are getting cleaned up. Do you agree that this is not a security issue as Karan-ramani has reported it to be? @karan-ramani Can you please test again on ver 1.5.7 and let us know your results? If you see it cleaning the tags/attributes that could lead to XSS attacks, then request you to update your first post above so that CVE site can update its records about this being not XSS vulnerability. |
@idvishal depends on how someone uses the scan feature. I guess most of us use getCleanHTML() anyhow and in that case so far we have not been presented a reproducible scenario. But if someone would use it in a way where depending on errors reported it outputs the original html or the clean html, this corner case (single invalid/unclosed tag with javascript attributes) would then be a potential XSS issue. |
Thanks @HaraldWalker . We use getCleanHTML(), so we should be fine. @karan-ramani if you can confirm once that you didn't encounter this issue with getCleanHTML(), that will be great! |
Thanks for explaining it @HaraldWalker @idvishal yes you would ideally not encounter this issue if you use getCleanHTML().. issue is mainly with scan function.. scan function is useful to clean js making it ideal if you expect HTML in response. The application I tested was expecting a HTML text in response but without js to prevent script execution in browser. I would suggest not to use antisamy anymore as it is not actively maintained and there might be possible bypasses that are not yet identified/disclosed.. |
Thanks @karan-ramani. Can you please recommend the alternatives to antisamy? I see that OWASP HTML sanitizer is good but then the main issue is it works opposite to antisamy i.e. it blocks all HTML elements/attributes by default and you have to provide whitelist. So, that way it is not an easy switch for us. |
@idvishal If you want to use OWASP HTML Sanitizer, you may want to take a look at this: Reading through this thread and also inspecting the AntiSamy 1.5.7 code, I would suggest that CVE-2018-1000643 be closed or at least contested. At best, it is seriously misleading in the manner that it is written. The proper and expected use of AntiSamy in calling |
@idvishal I think it's a well drawn design decision to work with a whitelist and not a blacklist. When it comes to security, you have to be defensive. You cannot possibly foresee what vulnerabilities come with brand-new html elements. So yes, when new html elements appear and you wish to use them, you have to update your antisamy policy files. You cannot have security without having to maintain your application. |
H. Blankenship of the OWASP Foundation confirmed to me that this project is inactive and needs a new project leader. |
It does need new leadership. I'd kill for a new maintainer. It's not too much work. People aren't clamoring for new features. That being said, I agree with @kwwall on this issue. The getErrorMessages() API is not for security. The of act of deserializing arbitrary content into a structure will definitely cause some attacks based on incomplete markup to be filtered out, but there's no way to report them as they happen in the innards of another library. This is a false positive and the project will dispute the CVE. |
Whats the status on this? Seems like the CVE is still open https://www.cvedetails.com/cve/CVE-2018-1000643/ |
I've volunteered to help @nahsra maintain antisamy. I'm working on the 1.5.8. release now, including upgrades to the known vulnerable libraries. I've also asked MITRE to close this CVE (however they do that), but no response from them as of Apr 9, 2019). |
Hi, @idvishal and @roricolivares "do we know when this issue will get fixed? Our security team has blocked the usage of antisamy 1.5.7 until this security vulnerability is fixed." The issue is now marked as DISPUTED in the CVE, and I'm working with them to get it to REJECTED status. I might have to convince the person who requested the CVE to request it be rescinded. Do we know who requested it be created? |
The CVE opened for this has now been REJECTED: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000643. As such, SCA tools should stop flagging Antisamy with this non-issue. |
i have similar kind of problem, |
You question is not related to the original issue, and this issue is closed. Please open a new issue. |
Hi Did you find any solution for this? Or it is fixed any latest versions? |
Way back on 2019-04-19, @davewichers wrote (emphasis mine):
Unfortunately, that's not true for all SCA tools. Both Sonatype Lift and Sonatype NexusIQ are popular SCA tools that still report this. I even had our product support team at $dayjob report this as a bug in NexusIQ and Sonatype essentially came back with the "it's not a bug, it's a feature" line and told us we should use waivers for these REJECTED CVEs. |
Also, since I happen to be here and am commenting on this closed issue anyway, I think an important point needs to be made here. HTML sanitization, such as what AntiSamy performs (and I'm including CSS and JavaScript in that 'HTML'), is really intended as a defense-in-depth measure and there is no guarantee that it is fool-proof, in part because way too many browsers are too liberal in what they accept (Postel's Law). Working around such potentially unhealthy browser behavior (even if it is deliberate and well-intentioned), is an extremely difficult process. It is difficult because every browser version behaves slightly differently and it is aiming at moving target (rather than something more stable, such as the W3C HTML specifications). Attempting such browser bug workarounds would greatly add to the complexity of AntiSamy and as a result, the number of bugs it has as well as likely some measurable performance hit. So, if you want a "safe harbor", rely on other approaches such as doing your own application context-specific input data validation, appropriate contextual output encoding, and appropriate use of CSP headers tuned to your specific application. AntiSamy is not a silver bullet in slaying the XSS werewolf. In fact, as I've recently written, there is no silver bullet in XSS defense. In short, security libraries need to make reasonable tradeoffs, but ultimately the responsibility for dealing with vulnerabilities in browsers--should that be a concern--needs to be the responsibility of the application developer and not the library developers that application happens to be using, It's not rocket science to compare the |
Antisamy fails to filter (identify) 'HTML / HTML5 elements with events (onerror, onload, etc) when the tags are not closed with ">" character.
Modern browsers (tested with Firefox and Chrome) will autocomplete such tags and hence will execute the JavaScript leading to Cross-site Scripting - XSS
Example Payloads for better understanding -
I have tested using both - SAX and DOM, found the payloads to execute.
Karan Ramani
The text was updated successfully, but these errors were encountered: