shortcode in html comments ignored

This explanation works for me:

https://core.trac.www.ads-software.com/ticket/34575#comment:4

The last thing I want is someone injecting malicious code to my site via a shortcode in a comment.

aaroncampbell was kind enough to go into more detail after I posted this forum thread. But I do not agree with your point about comments. As far as I know shortcodes are not processed in comments.

And I do think not all sites have the security risks he mentions about contributors. Some sites are well organized with only a few allowed authors/administrators who do know what they are doing. And disallowing them previously functioning features is to big of an impact in my opinion. At least give a way for those sites to keep working the way they were.

Without more information on the real security issues I don’t know whether my use of the nested content in shortcodes is really a problem in certain situations. So now I don’t really have any incentive to go look for alternatives for any real reason other than that you forced me too.

I’m still on the fence whether I should start using another type of templating engine for my requirements. But the way shortcodes used to function did not give me any reason to look into this.

Hey @distinct, I see that you placed a similar comment on the ticket itself. I think it makes sense to keep conversation all in one place, and since that ticket is closed and unlikely to reopen, lets go ahead and try to keep it here.

You’re probably not going to find a lot of actual code detailing the security issue, for obvious reasons. Having said that, we do in fact have security concerns. You are right that it might not affect all sites (such as a site with all trusted users that all know exactly what they are doing and have a good grasp of HTML in general), but that doesn’t change the fact that we need to keep this security hardening in core for all other sites.

Since shortcodes won’t work inside HTML tags or comments, if you need something to function in those areas you’ll have to find another option.

Yeah, Aaron, I didn’t know if you would find this topic. Should have mentioned it there. But you made your way here anyway.

I don’t completely agree that the security issue should not be detailed. Security through obscurity is not a good practice. But I guess you don’t want to make it too easy for attackers to exploit unupdated sites (though those would probably have a lot more security holes). If the reason not to explain the security problem is because the current changes to the shortcode system still don’t fix it, we might have a more serious problem ??

But details aside, I don’t see how breaking a lot of sites without a way (filter or define) to revert to old behaviour for sites that don’t have the security problem is a good thing. You should at least keep feature parity.
Of course such filters or defines should come with a big WARNING, but that comes with the territory.

I’m a bit scared about the future of the shortcodes, but for now I have circumvented my problem by preprocessing the post_content with ‘<!– [shortcode] –>’ to become ‘[shortcode]’
This of course only works for certain cases, but at least it keeps the Visual editor from wrapping it in paragraphs and breaking the table. And should still work with the current shortcode status.

This looks like the beginning of a templating engine, so I might search for some lightweight variant that might give me what I need here. No need to reinvent the wheel.

It’s not security through obscurity so much as it is giving as much time as possible for sites to update before releasing more specifics than we have to.

Honestly, I have to disagree with you on one part. No matter how many sites break (which I think we actually broke an especially small percentage of sites), I don’t think WordPress should have a core method for making something insecure.