Flag iframe buster html files that already exist in the Adbusters plugin

[nickdaugherty]

These should not be used directly in a theme, as they often have vulnerabilities, which are more easily addressed when using the Adbusters plugin.

[GaryJones]

Reference: Adbusters plugin on GitHub

Adbusters does not appear to be part of the vip-go-mu-plugins list.

Buster list.

@nickdaugherty Can you please give some examples of code you'd expect in themes, that we could look for, and example of code which shouldn't be reported?

[GaryJones]

Closing for lack of feedback. Can be re-opened if feedback arrives and it's still something that should be flagged.

[nickdaugherty]

@GaryJones sorry about that, I must have missed your initial ping.

The files that Adbusters looks for are here:

https://github.com/Automattic/Adbusters/tree/master/templates

Essentially we want to ensure that VIP code is not including those files directly and is instead using the Adbusters plugin. I suppose that would look like submoduling Adbusters into the custom PHPCS check, and comparing the files in templates against the scanned code.

Adbusters is not an mu-plugin, as not every VIP site needs it. But those that do use iframe busters for ad networks should be using it as it makes fixing and finding security bugs much easier.

[jrfnl]

I've had a quick look at this. As it is, the issue isn't very actionable as there are no code-samples or anything.

Am I correct when I draw the following conclusions based on the above + the linked content ? Or am I missing the point completely ?

• This requires a new sniff.
• The sniff would need to look at inline HTML code (and other text strings which may contain HTML code) and search for <iframe> elements.
• If found, the sniff should check whether the src is one of the typical file names from the list @GaryJones referenced above, probably just based on the file name without the subdirectory name.
• If a reference to one of those file names is found, it should be flagged for manual inspection with a reference to the Adbusters plugin.

I suppose that would look like submoduling Adbusters into the custom PHPCS check, and comparing the files in templates against the scanned code.

I'm not sure I understand the reasoning for this: if the file is the same, there is basically no real issue. The problem occurs when the file isn't the same, as the file may have vulnerabilities which have already been addressed in the Adbusters plugin.

The only benefit I could see in doing the file compare is that the sniff could throw an error when the file is verified to be the same, and a warning "needs manual inspection" if the file isn't 100% the same.

I expect that doing the file compare is doable, though would recommend it to be "future scope", i.e. after the initial sniff has been created & added to VIPCS.

The way I envision a file compare, would be to:

• add the Adbusters plugin as a Composer require
• then if a reference to one of the flagged files is found and the path to the file within the customer code is resolvable by PHPCS
• read the file in the customer code the corresponding file from the Adbusters plugin
• do a whitespace replace on the content of both to get rid of whitespace differences
• and compare the content of the files.

If not 100% the same, a text compare could be executed to see if there is any overlap at all. If no overlap, the file may not need to be flagged. If an overlap of more than x% (arbitrary number, tbd), the warning could be an error ?

[mjangda]

I vote to just close this. Adbusters isn't really maintained any more.