My first knee-jerk is "who is using scriptlets in 2017?" and then "who is doing server-side dynamic css?"

I would like a lot more info about this before I treat it as a bug. As it stands, if its an application that's taking HTML and CSS from the user, then this should have been previously run through an HTML sanitizer and then would be considered good data. If its color only, I would encode for HTML attribute in this case. I believe this isn't bug, but user naivete.

@xeno6696 I'm not really sure this should be closed as I have recently seen code that has done stuff like this. Admittedly, it's not common, but AFAIK, it's legit as far as W3C specs are concerned. The question is, is this still a problem in ESAPI 2.x? I ask because this was reported against ESAPI 1.4.4 and lot's have changed since then. Maybe we should at least add a test case for it. I've added a "help wanted" tag if you don't want to address it, but I am re-opening it.

Changing priority to Low because there are workarounds available, such as using a color name or via rgb() triples. So this shouldn't be a show stopper. If you are going back to add in ESAPI to this, then you can also rewrite you <style> tags or CSS to work around the issue.

I'm running into this same issue on ESAPI 2.1.0.1.

I guess my question would be is there some kind of best practice for using the encodeForCSS() method?

Also, I was poking through the source and noticed in DefaultEncoder.java "immune" characters are tracked for the different codecs. Currently, none are supplied for CSS. Would adding '#' make sense? I am not well versed in the security implications of not encoding that character so I thought I would throw that out there.

How about enhancing encoder to skip for color code in hexadecimal?

We can scan for # followed by 3 or 6 HEX and skip the coding for it.

According to CSS spec https://www.w3.org/TR/CSS21/syndata.html#color-units
The format of an RGB value in hexadecimal notation is a '#' immediately followed by either three or six hexadecimal characters.

I will work but it will then be less strict.
We may want to avoid encoded string &#[0-9][0-9];

I will work but it will then be less strict.
We may want to avoid encoded string &#[0-9][0-9];

In an HTML context sure, but I don't think that would break anything in the CSS side. The immunity that @planetlevel is referring to is unique to each specific codec in play--it's not global such that allowing # for css somehow whitelists it for HTML.

In checking out the grammar, I noted that the only other case where we're using the # symbol is in reference to selectors. And a couple of uri character references, of course, which in both cases # is legal in a URI.

To be more confident, I'd want to study more CSS style attacks if they surround the # char, but my initial impression is that @planetlevel is correct and it would have a minimal impact on security.

Have been spending some time to research and it seems # alone cannot inject CSS style attacks.

Should we confirm to use immutable character?

What unit tests did you write to come to this conclusion? I’m selfishly asking because we should add them to our test suite.

I can think about some normal test cases but not CSS style attacks tho.

@kwwall BeEF is really more of a post-exploitation toolkit. By the time you have the hook in your session there's nothing in the DOM that can't be rewritten.

These values are still not supported... rgb(255,0,0) and rgb(100%,0%,10%)
Need some more work

Propose not to support rgb as it will require immune 2 more characters and hex can be a easy workaround.

With 74a38b0 having been merged into develop what work is left to be done on this issue?

@jeremiahjstacey PR #453 did address this in part, but adding the '#' to the char array for IMMUNE_CSS, but based on @jackycct commens about it not supporting rgb triplets like rgb(255,0,0), rgb(100%,0%,10%) I wasn't sure if we wanted to consider this closed or not so it was left open.

P.S.- We'd want the CI run against our 'develop' branch.
@xeno6696 -- Do you think we should consider this closed or not? My gut is leaning towards making this issue as closed and if we want to address the rgb triplets in CSS not working as expected that we should create a new separate issue to address only that. What say you?

Can't believe I missed responding here. I think this is closed for now and we worry about the triplets later.