-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion about security #3394
Comments
Contextual auto-escaping is hard, because Twig is not aware of the format being output (it is not tied to outputting HTML). anything outside the Twig syntax markers ( |
Where do you see Twig going in the future? Will it be a proper/secure templating engine, or something that's very basic/simple (requiring the developer to know about, and be responsible for, escaping in every context). In a way Twig already has some awareness of the context, as I'm concerned that many developers are using Twig as a way to get the job done, and they are assuming it's escaping everything correctly. |
First, let's keep in mind that Twig is not an HTML template system, but a template system that can also use for HTML generation. Most people are using Twig for HTML, but it's not limited to HTML. Regarding auto-escaping, and as @stof already mentioned, we would need to parse the HTML to understand the context, something we don't do at all right now. A few years back, there was a discussion about this but nobody stepped up. Go templating system has something like what you describe, but to my knowledge, no other Twig like templating system has it. In any case, that would represent a huge amount of work and would probably slow down compilation a lot. That's not something I will work on in the forseeable future, so I'm closing here for now. If you want to give it a try, don't hesitate to ping me if I can help. |
I'm not familiar with how Twig works, but I've just made a quick mock up (only took a couple of hours to write, please don't use in production), but it's able to determine a variables parent tag, and if/which attribute it's in.
Tested with:
I'm getting 0.00024 seconds for this to complete, and I don't think it needs to be re-done when Twig is using cached templates. Personally I'd like:
I wouldn't expect the first version to be perfect... but if the basic parts are in place, security researchers can find exceptions, then the implementation in Twig can be changed/improved, and that improves the security for every single website that uses Twig. |
I'm glad to see Twig auto-escaping values by default (with
html
), but I'd like to discuss the future, and how Twig could prevent the most common security issues that affect the web today.Going on the basis that Twig is used by thousands of developers, with many being unaware of the security issues they are introducing into their projects, I believe it's Twig's job to fix these issues (developer training has not worked, where many assume that
html
auto escaping solves everything, e.g. #2623).The main issue is following up on the discussion on Contextual Auto-Escaping, where it's very easy for developers to get this wrong:
https://twigfiddle.com/ss6qc3
In this example, the developer is not aware of how dangerous inline JavaScript is, and isn't using
html_attr
on an un-quoted attribute (this example "works" with the values you expect, but it's still wrong).Secondly, I'm trying to introduce a concept into PHP where we can identify trusted developer strings (aka "literals", which have been defined within the PHP script) which need to be used for HTML templates, SQL strings, CLI strings; and keep those completely separate from user controlled (attacker tainted) strings. Where, in the case of HTML, we need a trusted templating system to carefully combine these 2 data sources in a safe/context-aware way.
The text was updated successfully, but these errors were encountered: