Add rel="noopener" to anchor if target="_blank" is set => security enhancement

[dab-github]

Add rel="noopener" to anker if target="_blank" is set
Based on the OWASP article
https://owasp.org/www-community/attacks/Reverse_Tabnabbing
it would be nice if the noopener attribute would be set automatically if the target blank attribute is in use.

This is very similar to the nofollow setting in antisamy

Example
<a href="https://example.com" target="_blank"> => <a href="https://example.com" target="_blank" rel="noopener">

[davewichers]

@spassarop - what do you think about this request?

[spassarop]

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?

[davewichers]

@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).

[spassarop]

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.

[davewichers]

@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?).

[spassarop]

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.

[davewichers]

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.

[spassarop]

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.

[davewichers]

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:

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.

[spassarop]

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.

[davewichers]

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.

[spassarop]

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.

[davewichers]

OK. These seem OK to me. Please implement (with test cases) and create a pull request. Thanks! And Happy New Year!

[spassarop]

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?

[davewichers]

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) ?

[davewichers]

@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.

[spassarop]

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.

[davewichers]

OK. So let's not bother with that 2nd, way more complex warning.

[davewichers]

I merged pull request #124, as such I think this has been addressed.

[davewichers]

Closing this issue as these changes went out with the 1.6.5 release I just pushed.