-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
html/template: does not recognize rgb() as a CSS color #25446
Comments
I had thought any template.HTML-typed value will be output directly. |
This may be a bug as I'd expect css function syntax to be allowed. However, if you use |
I don't know this area, but if this is ultimately deemed not a bug, somebody should consider what documentation could be added to clarify this for future users. |
It happens because |
(a better way may be find css standards) I don't think encouraging people to use |
@ianlancetaylor does this need to be fixed? I'll have a look at it if it needs one. |
@jamdagni86 Frankly, I don't know. |
@daviddengcn said
I agree that The tests (code) give a sense of what is currently recognized. |
@mikesamuel - one approach to fix this is to figure out if the value is a safe CSS function call. If it is, then we'll have to make sure the function call is of a valid syntax. Do we have a parser somewhere which I can use? If you had other thoughts, please let me know. |
@jamdagni86 the current implementation just ranges over the decoded bytes and detects potentially dangerous characters, so there is no parser to use. Switching to a parser to allow certain functions would imply a complete rewrite of that logic, and would very likely introduce issues and potential vulnerabilities in code that is currently protected by that check (e.g. existing code with a globally defined and vulnerable I don't think switching to an allowed-list can be easily done in a secure way, and would probably not be considered backward compatible. |
Apparently we will get more functions:
And this is not considering the already existing ones:
These are some options we could go for:
Are there any opinions on how to approach this? |
Documentation for this already exists, actually. In the CSS type docs, the
I'm not sure how difficult CSS parsing is, but I wonder how added complexity (and potential for bugs) this will add the |
Do you think it is reasonable to just add something to the doc for the CSS type? In my opinion since most of the inputs are numbers this is very unlikely to cause vulnerabilities even if users have to disable escaping. |
@empijei I think it's safe to assume that numeric inputs to functions are safe. I don't see any greater risk for info leakage due to numbers in functions than numbers directly in positioning rules. For functions that take strings, we'd need to know whether the string will be assumed to be a URL. An easy first cut would be to just
|
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?tip
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?does not matter
What did you do?
An code fragment to reproduced is here: https://play.golang.org/p/r8LOFN_roBo
Using
string
instead oftemplate.HTML
produces the same result.What did you expect to see?
color: rgb(10,20,30)
What did you see instead?
color: ZgotmplZ
The text was updated successfully, but these errors were encountered: