Comments (20)
@spassarop - what do you think about this request?
from antisamy.
I thought about it already and wrote it down to implement it someday in both AntiSamys. As we would need to discuss it before I never brought it up. That would mitigate reverse tabnabbing vulnerabilities where the target URL can take control of the calling tab.
However, there is one more attribute that could need to be added, noreferrer
: https://hackernoon.com/prevent-reverse-tabnabbing-attacks-with-proper-noopener-noreferrer-and-nofollow-attribution-z14d3zbh
This can be done with a new directive maybe. Modifying the nofollow
one may be intrusive on all existing policies and user's. What is your point of view?
from antisamy.
@nahsra - Arshan, can you weigh in on this discussion? If you think we should do something right away, I'd like to get this included in the 1.6.4 release, if we can do it quickly. If this is complex, then I guess we should push out the 1.6.4 release now, as it addresses a CVE, and work on this for 1.6.5 (or other future release).
from antisamy.
Adding the attributes with a directive is relatively fast, that does not care if there is a target="_blank". That should require extra logic looking for that specific attribute and value. At least those controls would be on the same place that the nofollowAnchors
logic.
Anyway, in my opinion we should release 1.6.4 as soon as possible and address this in the next release.
from antisamy.
@spassarop - We are trying to get 1.6.5 out soon. Any chance we can implement any of the fixes proposed here? (At least the easy ones?).
from antisamy.
As I said before, adding noopener
with the same directive as nofollow
may be intrusive. If we add a new directive like noopenerAnchors
true by default in the policies then it's almost copy/paste in the same code area. However this is the OWASP recommendation:
For HTML links:
- To cut this back link, add the attribute rel="noopener" on the tag used to create the link from the parent page to the child page. This attribute value cuts the link, but depending on the browser, lets referrer information be present in the request to the child page.
- To also remove the referrer information use this attribute value: rel="noopener noreferrer".
If we let noreferrer
to also be present, that would be 3 similar directives in total. When using the default policies, all links will then have rel="nofollow noopener noreferrer"
. All of them would be optional but present by default, tests must be tweaked. If that's OK to you I can do that.
One more thing, that previous approach does not care if target="_blank"
is set, they just appear. For AntiSamy to care, there must be some documented behavior that says the noopener
/noreferrer
will appear automatically if their directives are set to true and target is _blank
. Of course, that logic must be implemented when adding this attribute values.
from antisamy.
How about, for safety's sake, we add these two settings as optional, but can be set by policy changes? And/or code changes? i.e., our first implementation adds support for this behavior but does not make it that way by default. And maybe we can add a warning when we notice this situation occurring, with those flags off. We are already doing something similar when we check schema validation (per the thing you noticed a while ago). So maybe we can add this feature in the same way, warning when its not enabled, and indicating it will eventually be ON by default.
from antisamy.
Well yeah, it could be false by default with a log. Directives can be added to the default policies anyway with false so they can be noted there.
This however does not conclude if they will be isolated or with logic related to the target
value.
from antisamy.
I don't understand what you mean by: "This however does not conclude if they will be isolated or with logic related to the target value." Regarding the warnings, I think there should be 2 levels of them:
- That this policy is NOT enabled by default, and should be (a startup warning), and
- Each time the specific scenario is hit that these settings would apply to, it should warn them again (at runtime).
If we implement 2) we should probably also provide a switch to turn the runtime warnings off, as they could be annoying if they really don't want these features enabled by default.
from antisamy.
I'll explain better. The vulnerability that can be abused in this issue must meet this requirements:
- Anchor with
target="_blank"
. - Absence of "noopener".
The solutions we are talking about, independently of default values and directives, follow the current behavior of the "nofollow" adding logic. This logic is to add the "nofollow" just if the directive is present with the value true, it does not care about target
presence or value.
So the decision here that must be taken is whether just add the attributes when the new directives are present with "true" or to read the attribute list looking for "target", check if it has "_blank" as value and then check the directive value (or in a different order).
The "noreferrer" is an additional protection for the "noopener" case. Am I being clear now? If we do not check "target" it can be done relatively fast, on the contrary it will take more time.
from antisamy.
If I understand this right, can we add the noreferrer protection (with noopener) without fear of breaking backward compatibility? If so, let's do that.
Regarding 'nofollow' - how much slower could it be to search for it? And certainly it seems like it would be much faster to first: 1) See if the directive value has this enabled, and only if so 2) search for target's with: "_blank". That way, if it is OFF (which is the default), it is barely slower at all.
from antisamy.
It won't break compatibility, just an addition.
To find a target value, it would require only element.getAttributes().getNamedItem("target").getNodeValue()
to get the value (with the corresponding checks). Current logic is:
if (processAttributes(ele, tagName, tag, currentStackDepth)) return; // can't process any more if we
if (isNofollowAnchors && "a".equals(tagNameLowerCase)) {
ele.setAttribute("rel", "nofollow");
}
That last if would require the new logic checking if "isNoOpenerAndReferrer" or something like that and the "_blank" value check. Then setting "nofollow" (or not) and "noopener noreferrer" (or not). I'll need to stop for today but if you leave a comment I'll answer tomorrow.
from antisamy.
OK. These seem OK to me. Please implement (with test cases) and create a pull request. Thanks! And Happy New Year!
from antisamy.
Regarding the warnings, I think there should be 2 levels of them:
1. That this policy is NOT enabled by default, and should be (a startup warning), and 2. Each time the specific scenario is hit that these settings would apply to, it should warn them again (at runtime).
If we implement 2) we should probably also provide a switch to turn the runtime warnings off, as they could be annoying if they really don't want these features enabled by default.
How do you implement that switch?
from antisamy.
If we implement 2) we should probably also provide a switch to turn the runtime warnings off, as they could be annoying if they really don't want these features enabled by default.
How do you implement that switch?
I'm seeing language specific translation properties files here: https://github.com/nahsra/antisamy/tree/main/src/main/resources. But we could add a new generic, antisamy.properties file with one property in it for this scenario which has a default value of true, but it could be set to false to turn this warning off. Using properties files to configure Java apps is very common in Java. Our antisamy.properties file would be bundled with the jar, but a user can create their own antisamy.properties file in their config and it will override the bundled properties file. That's how they work.
Update: To implement 2. you need to act as if these features are always ON, search for the situation where to apply them, and just before applying them, a) if the feature is on, apply it, b) if the feature is off AND the suppression flag is not set, generate a warning that this feature is NOT enabled and there was input where it was relevant (And maybe some info about when/where it was relevant?). And if this seems too complicated to implement, then maybe we shouldn't bother with warnings for situation 2) ?
from antisamy.
@dab-github - Can you look at pull request #124 or the 1.6.5 branch if we've already merged it, to see if this change does what you want? Obviously you'd have to enable this new feature in your policy to turn it on as its off by default.
from antisamy.
Well I mean, it looks like a lot for a warning on a scenario that's adding stuff to the input. AntiSamy tends to at maximum remove attributes/tags after validation, not to add them. The nofollow
case is the only exception to this and the new changes are more exceptions to keep filling the input.
It is a good improvement, but a warning for every target="_blank"
link can be a lot, specially with the current info we're logging in the PR (same for every warning). Adding something like the whole actual tag (for example) to provide more info is not accurate (mostly on SAX parsing). In my opinion, the Policy warning is enough for the general case.
from antisamy.
OK. So let's not bother with that 2nd, way more complex warning.
from antisamy.
I merged pull request #124, as such I think this has been addressed.
from antisamy.
Closing this issue as these changes went out with the 1.6.5 release I just pushed.
from antisamy.
Related Issues (20)
- 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
- CVE-2022-24891 HOT 7
- 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
- Dealing with Security Vulnerabilities CVE-2023-26119 HOT 13
- AntiSamy encodes unknown tags despite not being configured that way HOT 6
- GraalVM Support HOT 4
- noopenerAndNoreferrerAnchors policy directive seems disabled by default in 1.7.2 version HOT 2
- How to find if vulnerable script is present in the input HOT 8
- Is there a way to not encode certain HTML Entities? HOT 6
- antisamy:1.7.3 contains batik-css:1.16 that has CVE-2022-44729 vulnerability 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.