A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Talk:Sanitization rules: Difference between revisions
Jump to navigation
Jump to search
Regarding the CSS
JamesMSnell (talk | contribs) No edit summary |
JamesMSnell (talk | contribs) No edit summary |
||
| Line 5: | Line 5: | ||
* Data URIs should be santizable on a per-MIME type basis. Until a vulnerability is found for text/plain mime types data URIs should be allowed, but other MIME types should be not allowed by default. Other, safer types could then be allowed via white list. -- [[User:Enricopulatzo|Enricopulatzo]] 16:49, 9 August 2007 (UTC) | * Data URIs should be santizable on a per-MIME type basis. Until a vulnerability is found for text/plain mime types data URIs should be allowed, but other MIME types should be not allowed by default. Other, safer types could then be allowed via white list. -- [[User:Enricopulatzo|Enricopulatzo]] 16:49, 9 August 2007 (UTC) | ||
** The word "default" puzzles me here. The common use case here is small GIFs, JPEGs, and PNGs to be directly embedded in places like CSS and <img> tags. If the associated MIME-types were to be white listed, under what condition would they '''not''' be allowed through? -- [[User:Rubys|Rubys]] 10:30, 10 August 2007 (UTC) | ** The word "default" puzzles me here. The common use case here is small GIFs, JPEGs, and PNGs to be directly embedded in places like CSS and <img> tags. If the associated MIME-types were to be white listed, under what condition would they '''not''' be allowed through? -- [[User:Rubys|Rubys]] 10:30, 10 August 2007 (UTC) | ||
** Whitelisting data url content-types seems like a good idea. Whether to apply sanitization to the encoded content is up to the sanitizer. White-listed content-types that may require additional sanitization could be flagged somehow. | ** Whitelisting data url content-types seems like a good idea. Whether to apply sanitization to the encoded content is up to the sanitizer. White-listed content-types that may require additional sanitization could be flagged somehow. [[User:JamesMSnell|JamesMSnell]] | ||
== Regarding the CSS <code>url()</code> == | == Regarding the CSS <code>url()</code> == | ||
Revision as of 20:23, 10 August 2007
Is the data URI scheme safe?
- Rob Sayre says no and refers to a wikipedia article; however, I cannot see anything in the article that indicates the scheme is not safe.
- Looking at that wikipedia page,
datacould only be added if it were followed by an asterisk, kinda like the 756* that I see popping up all over the place these days. In particular, I don't see the use case which would justify the investment in sanitizingtext/htmlencoded as a data URI. Not that it would be difficult, just hard to justify. Perhaps a section could be added which lists safe content types when included in data URIs. -- Rubys 03:48, 9 August 2007 (UTC)
- Looking at that wikipedia page,
- Data URIs should be santizable on a per-MIME type basis. Until a vulnerability is found for text/plain mime types data URIs should be allowed, but other MIME types should be not allowed by default. Other, safer types could then be allowed via white list. -- Enricopulatzo 16:49, 9 August 2007 (UTC)
- The word "default" puzzles me here. The common use case here is small GIFs, JPEGs, and PNGs to be directly embedded in places like CSS and <img> tags. If the associated MIME-types were to be white listed, under what condition would they not be allowed through? -- Rubys 10:30, 10 August 2007 (UTC)
- Whitelisting data url content-types seems like a good idea. Whether to apply sanitization to the encoded content is up to the sanitizer. White-listed content-types that may require additional sanitization could be flagged somehow. JamesMSnell
Regarding the CSS url()
As I understand the proposal, all url() properties are stripped or ignored. Why is this important? If it's to keep people from linking to malicious scripts only, then you've made it difficult for designers to link in background images.
Could we not dereference the URI to determine if it's safe (ie: a valid image, not a script). "Safe" files are then stored on the server doing the sanitization, preventing users from swapping the innocent resource for a malicious one.
--Roberthahn 12:55, 10 August 2007 (UTC)