Comments (7)
@onemoreflag - I don't think there's anything to fix in AntiSamy. ESAPI had a slightly different (and very behind) AntiSamy policy file than an of the AntiSamy policy files that come with AntiSamy itself. The problem was a malformed regular expression that was originally correct but someone added a '~' at the end and it inadvertently changed the meaning of the regex. I see something similar on line 25 of tinymce.xml, but that line is commented out and thus should be harmless.
This it is not clear what code or policy file you think needs to be fixed. If you find it, please be more specific and it it is a security vulnerability, please practice responsible disclosure by following these steps outlined by the AntiSamy development team rather than reporting it as a GitHub issue. Failure to do that could put other projects that use AntiSamy at risk.
Thanks in advance for your cooperation.
from antisamy.
@onemoreflag - One additional thing... if you have found an Software Composition Analysis tool that is reporting this against AntiSamy (rather than against older versions of ESAPI, for which I am one of the project co-leads), the SCA is likely at fault. Please let the AntiSamy team know if this is being flagged by some SCA tool so that the AntiSamy team can contest it as a false positive. Thanks.
from antisamy.
@kwwall My project uses Antisamy, So I'm more concerned about whether it has security holes.
You can confirm if there is a problem, I will also dig into whether the same vulnerability exists
Hope it doesn't affect Antisamy
from antisamy.
@onemoreflag - Ultimately, since some customization of AntiSamy policy rules is generally expected, only you can test your own specific policy files for the sort of typos that were found in ESAPI. (It's much less common that ESAPI users tweak their AntiSamy policy files as our documentation doesn't call that out as an option. In fact, in my observation over the past 10+ years, I would say it is rare.)
There is sufficient information provided in ESAPI Security Bulletin 8 for you to construct your own specific tests against javascript:
URLs, but based just on its name, it wouldn't surprise me one bit if at least the "antisamy-anythinggoes.xml" policy file allows that.
Ultimately, security is responsibility of those who are using the dependencies as library providers, no matter how conscientious or how skilled they are at AppSec, can't do it all. Clients of libraries must be using them as intended (which hopefully is sufficiently and accurately documented). Anytime there are configurations that may be tweaked for a given library, that goes double, because library providers cannot possibly test all possible configuration variations.
That said, if you do find a vulnerability in AntiSamy, please report if via these steps outlined by the AntiSamy development team rather than reporting it as a GitHub issue. As I mentioned previously, failure to do that could put other projects that use AntiSamy at risk.
from antisamy.
@kwwall ok
from antisamy.
@onemoreflag - I finally got around to testing all 6 of the sample AntiSamy policy files under https://github.com/nahsra/antisamy/tree/main/src/main/resources using the same test that I did to confirm that CVE-2022-24891 had been remediated for ESAPI. For each of the 6 Antisamy policy files, I used the respective policy file along with the SAX scanner to scan the tainted input string of:
String taintedInput = "<a href=\"javascript:alert(1)\">This is safe from XSS. Trust us!</a>";
to return a CleanResults
object and then examined the cleansed output of CleanResults.getCleanHTML()
. In all cases, the javascript:
URL was stripped out. There were two variations of cleansed output, depending on the specific policy used for the scanning.
The 2 policy files "antisamy-slashdot.xml" and ""antisamy-tinymce.xml" both returned This is safe from XSS. Trust us!
as the cleansed string result, whereas the other 4 policy files ("antisamy.xml", "antisamy-anythinggoes.xml", "antisamy-ebay.xml", and "antisamy-myspace.xml") all returned <a>This is safe from XSS. Trust us!</a>
as the cleansed string. I'm no sure the reason for the difference, but my guess is that "antisamy-slashdot.xml" and ""antisamy-tinymce.xml" don't allow anchor tags at all.
But the important thing here is that in ALL CASES, all of the Antisamy sample policy files returned safe output, i.e., no JavaScript was returned in the cleansed results returned by CleanResults.getCleanHTML()
.
@davewichers and @spassarop - I don't think there is anything further to do here. I suggest that you close this issue without any code changes to AntiSamy.
from antisamy.
Thanks @kwwall and @spassarop for all your research here. Per your recommendation I'm closing this. I guess this means I can release a new release that upgrades the one vulnerable dependency that exists in the current release.
from antisamy.
Related Issues (20)
- Improve Unit Test Coverage
- how to edit the antisamy.xml to support the css-style "-webkit-border-radius" or "-moz-border-radius" HOT 6
- require-closing-tags is not supported by antsamy.xsd HOT 5
- Change in behavior between 1.6.4 and 1.6.5 for getErrorMessages HOT 7
- Commit details for CVE-2022-28366? HOT 4
- Remove all deprecated APIs/features in prep for 1.7.0 release HOT 1
- ASHTMLSerializer uses deprecated HTMLSerializer. Replace with TrAX.
- AntiSamy converting single quotes to double quotes for font-family which is causing issue while rendering HOT 6
- AntiSamy not detecting XSS for anchor tag HOT 10
- CssHandler test case failure on Windows HOT 5
- Incorrect 'Contributing' link on OWASP wiki page HOT 1
- Javadoc cleanup
- 2 enhancement HOT 2
- 1 enhancement with api HOT 2
- Removing Xerces dependency? HOT 3
- Does Antisamy has support for custom css properties " --* " and css-function " var() " and how to define it in the antisamy policy file? HOT 10
- Enabled noopenerAndNoreferrerAnchors policy drops nofollow HOT 7
- Covering all cases of "rel" attribute in "anchor" tag is quite verbose HOT 3
- Investigate replacing Batik CSS HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from antisamy.