Escape inline event attributes instead of remove them

[edlmo]

Hi,
I found myself on this situation where I have a valid non executable HTML with inline events, which were removed by the filter. At first sight this should be the expected behavior, but in my case I'm using the filter on user input data that documents HTML code, so these events are expected if the affected tags are inside of <pre> or <code> ones.

I believe this line https://github.com/MasterRO94/laravel-xss-filter/blob/master/src/Cleaner.php#L74 can be safely replace with

$string = preg_replace_callback($this->invalidHtmlInlineListenersPattern, [$this, 'escapeEqualSign'], $string);

// ...
protected function escapeEqualSign(array $matches): string
	{
		return str_replace('=', '=', $matches[0]);
	}

But I'm not sure about how to prevent the javascript:code attack using escaped replacements.
Let me know what do you think and if you believe this is enough to propose a pull request (or feel free to apply the changes directly if you like).

BTW, thanks for your work on this middleware.

[MasterRO94]

Hi,
Thanks for the feedback.
I don't remember why decide to remove inline listeners instead of escape. This would be a big change for such a small package. Tests should be updated.
I'll take a look what I can do here, but I think this behavior can be configurable.

[MasterRO94]

@edlmo
Hi, I've just released v1.3 with support escaping inline event listeners via config file. This is disabled by default.
Let me know does this fit your needs 😉

[edlmo]

Hi @MasterRO94
Thanks! Yes this works for me. But please, take into consideration that this escape method won't work on issues like the reported on #2 as I commented above. I tried escaping the colon symbol as well but it gets executed anyways. Replacing colons by something like space+colon or something like that could work, but will also modify the original displayed content, so I'm not sure what the right fix should be there.
Anyways, thanks for the config setting to allow escaping the inline events :)