-
Notifications
You must be signed in to change notification settings - Fork 144
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Implement support for backend.allow_unsafe_markdown and improve suppo…
…rt for Swoole
- Loading branch information
Luke Towers
committed
May 26, 2020
1 parent
f85039b
commit 6ae19a6
Showing
2 changed files
with
33 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit has been pushed to rainlab/blog/master whereas the new "allow_unsafe_markdown" permission has not been released on master on OctoberCMS causing our blog writers no longer be able to use HTML in blog posts while the next October release is not out. :/ :/
6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aurelien-roy You'll need to rollback the Blog version to 1.4.0 or use the
develop
build of October. Although, I'm curious as to which HTML your blog writers are using, asHtml::clean
doesn't strip all HTML, just some potentially unsafe HTML.6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aurelien-roy yes, please let us know ASAP what markup is affected, HTML::clean should only be removing potential XSS.
6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LukeTowers @bennothommo Nothing anormal. The HTML contains iframe, which is a blocked tag (Usage: embed videos from various streaming platforms).
6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @aurelien-roy - given this is a security fix, you will need to use the
develop
build of October for now then, to be able to take advantage of the new permission.6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bennothommo do you think we should modify Html::clean() to support passing tags that are allowed through so that we can allow iframes in blog content for less privileged authors? iframes are pretty commonly used for embedding content.
6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LukeTowers If I may ask, why is October rolling its own version of
Html::clean
instead of using a robust library like HTML Purifier that is built specifically for this task?6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@msimkunas because it's overkill for our needs and would require adding a pretty heavy dependency & interaction layer. We will be modifying our method to support specifying what tags are stripped out which will fix the iframe issue.
6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LukeTowers I'm afraid I don't follow. How does the use case in question not warrant the usage of an external library? I understand the reluctance to include a new dependency into the project, however, you're dealing with potentially unsafe user input here. Shouldn't it be properly sanitized?
This obviously depends on the threat model you have in mind. Rolling a homemade HTML parser seems like an acceptable solution when you trust the end user enough to not abuse rich text inputs like this. While this is somewhat okay in case of superusers, there may very well be other backend users with restricted permissions that you wouldn't want messing around with your inputs. I believe it's perfectly reasonable to not extend the same trust level to such users and the approach to validating their inputs should reflect that.
6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@msimkunas we've wanted to avoid adding such a heavy dependency to the project for a while, the existing solution has been developed over several years and gets updated whenever a new issue is found while remaining relatively lightweight. For the most part it works, providing 99.some arbitrary amount of 9s% security (whereas HTMLPurifier would add some amount more of arbitrary 9s), and part of why it works is because it's used for situations where the user is already partly trusted. Untrusted user input coming from a backend user with a valid account and access to that input is already more trusted than just any random request coming from the internet.
However, I do agree that October could provide a better developer experience by integrating with HTMLPurifier natively, so we'll be implementing a
Html::purify()
method to do so in a way that isn't as complex to use as the library happens to be natively.6ae19a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LukeTowers Thanks for clarifying this. At the moment I'm using a plugin from the marketplace which adds the HTML Purifier as a Twig filter and it works very well. Here's hoping that this gets native support in the future!