-
Notifications
You must be signed in to change notification settings - Fork 317
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
Reconsider usage of Number
s in CSSResult (based on real life painful use cases)
#488
Comments
It may be possible to make this change, but we'll need to do a careful security review first. We're trying to be especially careful around security issues in CSS since it's particularly difficult to sanitize CSS. However, I want to make sure I understand the examples given above. The intention of So, you should be able to do something like this:
While this is slightly more verbose, it's definitely not as cumbersome as the example given. |
That indeed would mitigate the pain. But our aim mainly is to have a set of global variables that should be considered safe by default and can be applied without giving the impression they should be used with care. So I was hoping Defining string values with However definitely the best option for now. Thanks for the suggestion and hopefully the security review will turn out positively for us. |
My simple custom Context Menu element use-case would be:
where |
@tlouisse A minor one. ISE would prefer to just allow numbers through rather than get developers in the habit of sprinkling unsafeCss directives throughout their code. Primary risk of numbersStringifying a number can produce ("NaN", "Infinity", "-Infinity") or a string with chars in There is a risk of leaks with numbers combined with URLs:
Severity of attacker-controlled numbers
IMO the greater risk comes from a developer in the habit of routinely using unsafeCss allowing an input like |
Thanks a lot for the clarification |
@mikesamuel imho the idea is not to just allow numbers to pass through but to safely type check them and only allow if they are truely valid numbers. The check could be included here: https://github.com/Polymer/lit-element/blob/master/src/lib/css-tag.ts#L64 strawman proposal const textFromCSSResult = (value: CSSResult) => {
if (value instanceof CSSResult) {
return value.cssText;
} else if (typeof value === 'number' && isFinite(value) && value === value) {
// check for being a number but not (+/-) infinity or NaN
// (NaN is the only value in javascript which is not equal to itself)
// we use isFinite and value === value to stay compatible with IE11
return value;
} else {
throw new Error(
`Value passed to 'css' function must be a 'css' function result: ${
value}. Use 'unsafeCSS' to pass non-literal values, but
take care to ensure page security.`);
}
}; With such a check "valid" numbers should be save to use everywhere right? (also in the examples you posted if I am not mistaken - pls correct me if I am wrong)
I can could not agree more... once developers are in that habit they will not stop 🙈 |
If there is no security risks with allowing Infinity and NaN then I'd go for just a typeof check. |
friendly reminder 🤗 |
@daKmoR I did thumbs up your summary and proposal from last week, but now that I think about it, that's unlikely to trigger a Github notification. Sorry if that got lost in the noise. I +1 your proposal in #488 (comment) I'll defer to the maintainers on whether the place you cite is the best place to make the change, but I don't see anything wrong. Re #488 (comment) I see no security risk with allowing Infinity or NaN, so don't take a position on whether they should be passed/blocked. |
friendly reminder on this... any progress or anything we can help with? |
hey quick question if someone creates a merge request to allow for numbers as outlined here #488 (comment) how high would be the chance for that merge request to be merged? |
A PR for this would be welcome. Pending review I think the objections have been addressed so this seems fine. Thanks! |
So I took the code from #488 (comment) and put it into a Pull Request.
|
Description
Sorry to bother you again with the CSSResult variables issue, but I was hoping there is some room left for improvement of Developer Experience, after seeing the remark of @mikesamuel: #451 (comment)
We appreciate your considerations with regard to security, but we currently are experiencing some drawbacks as far as Developer Experience is concerned.
To illustrate this, see the following example (very verbose and thus harder to read and maintain):
https://stackblitz.com/edit/css-variables-for-computations?file=style%2Fmodules%2Fgrid-css-module_numbersNotAllowed.js
My apologies for annoying you with a question that was already asked before, but we just wanted to show you some of our 'real life implications'.
So the derived question then would be: can Numbers on their own be a security issue?
If not, we could rewrite our example above to:
https://stackblitz.com/edit/css-variables-for-computations?file=style%2Fmodules%2Fgrid-css-module_numbersAllowed.js
Live Demo
See above
The text was updated successfully, but these errors were encountered: