I wanted to know if there's any way to get CSS Style XSS on modern browsers?
For example, on older IE browsers the following is susceptible:
<div style="width:expression(prompt('XSS'))">
No. As this example perfectly illustrates, Javascript (or any scripting) has no place in CSS, therefore XSS (the second S is for 'Scripting') is not possible. CSS should be declarative only, and is when implemented conforming to the W3 standards. Dynamic expressions are now done with calc which can only evaluate simple mathematical expressions, without resorting to the JS engine.
expression was an IE-only hack to facilitate specific features until W3 came up with an alternative. As calc appeared, expression was deprecated. Starting with IE11, expression is no longer supported in the Internet Zone. It was announced in 2008 that it would end up this way, specifically citing 'to reduce the attack surface' as one of the core reasons. In older versions than IE11 it has already been for quite a while only supported in quirks mode and IE7 emulation mode anyway.
Summarizing: CSS has no place for Javascript, and as such cannot be attacked with XSS when implemented properly as it is in every current browser.
Related
As I'm sure you all know, Internet Explorer can handle simple gradients. Here is a snippet from Twitter Bootstrap, for example:
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#e6e6e6', GradientType=0);
However, I've seen some people use two CSS rules (one for IE < 8 and one for IE 8), like so:
filter:progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f'); /* For Internet Explorer 5.5 - 7 */
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f')"; /* For Internet Explorer 8 */
My question is, is the second rule really necessary? Twitter Bootstrap is quite thorough, yet it doesn't use any "-ms-filter" rules. According to this page, the -ms-filter attribute is an extension to CSS, and can be used as a synonym for filter in IE8 Standards mode.
My suggestion:
Use CSS3Pie -- http://css3pie.com/
This is a JavaScript library for IE6, IE7 and IE8 that patches in support for several CSS3 features, including gradients.
Yes, you can use the horrible IE-specific filter styles if you want, but CSS3Pie allows you to use standard CSS styles for these features. Much easier.
To actually answer your direct question:
Yes, the -ms-filter style is usually required. IE8 will always us it instead of filter, which is used primarily for IE6 and IE7. In some cases filter will work in IE8, but not all, so it's best to use -ms-filter to ensure IE8 compatibility.
[EDITED]
Why did they change it? Because when they released IE8, Microsoft made a big point of trying to be "standards compliant".
For a browser to be standard-compliant, it should use a vendor prefix for any CSS property it supports that is not a finalized W3C standard. So by adding the -ms- prefix, Microsoft were trying to (belatedly) undo their pollution of the global CSS namespace.
In addition, the quotes were added, because the old filter syntax without the quotes was invalid CSS (mainly because of the colon after progid), and caused issues with some browsers. (I had an instance some time ago with Firefox 3.6 where it was dropping all styles following a filter style that rotated an element - took ages to work out what was happening).
The fact that Microsoft retained backward compatibility with the original filter syntax, was largely a matter of pragmatism. MS couldn't afford to break all the sites using the old syntax. But there was a strong implication from Microsoft that developers should use both because they would drop support for the old filter style in subsequent versions of IE. As it turned out, they dropped support for both filter and -ms-filer in one fell swoop, but the implications given at the release of IE8 were sufficient for it to become recommended practice to provide both syntaxes in your stylesheet.
At the time when IE8 was released, XHTML was the new flavor of the month, and writing code that validated perfectly was top of the list for a lot of developers. This was probably a strong driving force in the change of syntax to include the quotes. Because of the stray colons, it is impossible to write CSS that validates using the old filter style. Using the new -ms-filter styles instead allowed people to write valid CSS. As good ideas go, this one didn't really work out because of course people had to keep using the old syntax anyway, but the intent was good.
It's worth pointing out that other proprietary styles were given the same treatment. For example, you can use -ms-behavior in IE8 instead of the old behavior style. No-one uses it. Why? I don't really know.
Another fact worth knowing is that the W3C are in the process of standardizing a CSS property called filter. It will do a completely different job to the Microsoft filter style, and work completely differently. If/when it is standardized and browsers start supporting it, there will be an explicit clash between the two syntaxes.
Seems like you answered your own question. Yes they're needed. Microsoft trying to get more in line with the standards means that some versions of IE have their own slightly different syntax rules for the filter property.
In IE7 just filter: followed by the progid:DXIma... etc will work. But for IE8+ there is the IE7 fallback it may use in compatibility mode, and the more proper -ms- prefixed property for filter, denoting a vendor specific css property, and its value inside qoutes.
What harm would it do to leave it in?
If the browser doesn't understand the line of CSS it will just ignore it.
Those two lines of CSS are almost identical. I would hazard a guess that Microsoft decided to change the syntax for proprietary CSS from IE8 onwards utilising the - (hyphen) prefix which other browsers have been using for yonks.
Technically the CSS isn't W3C compliant either way, so another line of proprietary CSS can do no harm.
It's not worth trying to understand IE at the best of times!
Similar to disabling JavaScript in browsers, is there a way to disable support for various CSS3 properties in Firefox or Chrome to quickly confirm a page is rendering OK if support for certain properties isn't there? I know it's only a presentation layer, but I'm just hoping there's a more efficient way to test against this without using old browsers, especially if Modernizr is being utilised.
A project called deCSS3 manages to disable a large majority of CSS3 properties through the use of a bookmarklet that overrides and neutralises their usage with !important rules.
A recent addition to the project is "Modernizr class toggling" for an added level of testing when Modernizr is utilised.
Even if there were a way to do so, would it help? Each browser has its own quirks, so there is no guarantee that e.g.:
Firefox - CSS3 = Older Browser
CSS3 isn't a set of additions to CSS2, it replaces CSS2. The backgrounds and borders module in CSS3 includes border and background as well as border-radius and box-shadow. If you 'turn off' CSS3 you turn off all CSS, and even if you could disable the new stuff Tom's answer is correct - that wouldn't leave you testing anything that actually exists in the real world.
If you need a way to "turn off CSS3" then I don't think you're thinking about/implementing progressive enhancement/graceful degradation properly. You should be starting with non-CSS3 stuff, then enhancing your site with it. When you build the non-CSS3 foundation and test it in your target browsers, then adding CSS3 shouldn't change anything (browsers ignore styles they don't recognize). If you sandbox your CSS3 in its own stylesheet, then you can tell old versions of IE to completely ignore it (or, if you're using stuff that's only partially supported in IE9, can tell all versions of IE to ignore it) to save a download.
That said, CSS is handled by the core rendering engine, so in order to view a page without CSS3, you have to view it in a browser that doesn't support CSS3. It sucks, it means you have to have several browsers, and even virtual machines (or physical machines) to test very well, but such is the state of web development, unfortunately. Theoretically, you should be testing in several browsers, anyway, and already know that IE6-8 have their own quirks that don't even relate to CSS3, and should already be set up to test them (so, therefore, if you need to test old versions of other browsers, you can install them in your IE test environment).
There's a useful add-on for Firefox called "User Agent Switcher" which allows you to bump your browser rendering down to an older version of IE (the iPhone rendering is also pretty useful). That should help you double check.
I dont understand why the HTML5 website I am working on is different in all browsers. I know it must be CSS, but I dont know what.
on Chrome: http://slackmoehrle.com/chrome.png
on Safari: http://slackmoehrle.com/safari.png
on IE 7: http://slackmoehrle.com/ie7.png
on FireFox Mac: http://slackmoehrle.com/firefox.png
the style sheet can be found here: http://slackmoehrle.com/css.css
Can anyone shed any insight?
Many are saying that browser detection is not a good method, but I dont see what to do to make this all work in the various browsers
UPDATE:
without using a CSS reset: http://slackmoehrle.com/test/without-reset/
with using a CSS reset: http://slackmoehrle.com/test/with-reset/
Have a look at using a CSS reset stylesheet
My personal favorite is Meyer's: http://meyerweb.com/eric/tools/css/reset/
The only real problem with browser detection is the fact that if newer version of browser will support some new features (rounded borders for example), but you still will be doing some workarounds.
Better approach is to use feature detection, so you will be able to use some specific browser capabilities if it has support of them and some graceful degradation pattern when something isn't supported.
For CSS most pragmatic approach is to have reset CSS included for all browsers, then have some common CSS rules which look the same in all browser and additional CSS files for different browsers which contain rules that should be different for different engines.
From my latest experience it's almost always possible to maintain only two versions of these DIFF files - one for Firefox, Safari, Chrome and another for IE family. And use feature detection for JS.
First of all, no version of IE can handle the new elements of HTML5 without javascript help. Only modern browsers can and IE is not a modern browser.
As far as the other browsers go, I'll have to look more but I've not had any issue with any sites I've done but, then, I don't use CSS resets and set all the CSS on the elements myself.
Should we use IE's CSS Dynamic properties?
I read IE8+ would not support these.
What is the best strategy to handle this?
If you mean CSS expressions, you should avoid them because they're slow.
Your question about how to avoid them is pretty vague. It would be easier to answer a more specific question. But here's a vague answer: Javascript. :)
They are very useful to solve incompatibility problems with older versions of IE, for example to get png transparency in IE6. I always (when needed...) include style-sheets using these functionalities in IE's conditional comments.
The dynamic properties wasn't anything that really took off. It could be used in applications that targeted IE only (i.e. intranets and such), but as it never became a standard and no other browser supports it, it never came into wide use on the web.
I haven't read what you say about IE8 not supporting dynamic properties, and I haven't tried it, but it sounds very plausible that the will not be supported when the browser renders a page in standards compliant mode. They will probably be supported in quirks mode for a few versions longer.
As of right now I believe only Firefox support -moz-border-radius property. I am surprised that twitter uses it.
Are any other browsers planning on supporting this or does CSS3 have something like this in the works?
Edit: I also found -webkit-border-top-left-radius and then the CSS3 version
So when is CSS3 coming out?
CSS3 has border-radius.
For now, Mozilla- and WebKit-based browsers have experimental support, -moz-border-radius and -webkit-border-radius. It's not bad to use them now, as long as you understand they are temporary measures until they are properly implemented. I would expect it's not too long before you see full support for border-radius in Mozilla, Firefox and IE. (Well, hopefully IE.)
Update: as of August 2016, with border-radius being natively available in all native desktop browsers (and most mobile browsers, not to mention), the stringency of using -moz-border-radius, -webkit-border-radius and similar is being slowly relaxed.
Because the CSS3 spec hasn't been finalised, Mozilla and Webkit decided to implement their own method of rounded corners, doing it in the correct way, by adding the vendor-specific tag at the front.
This is done so that when the CSS3 is FINALLY released, should they change how border-radius is supposed to work (eg: the order of the parameters), then none of the sites using the vendor-specific methods will be broken. Mozilla and WebKit can just go ahead and implement the W3C style and developers can slowly move over to that.
It's not too surprising that you're seeing some websites using it, especially for something like rounded corners where it's not going to make a massive difference to the user experience. And I mean, it's just IE users who are missing out, and they deserve everything they get.
It bugs me when people talk about CSS3 coming out. It's not a complete spec like the previous ones. It has been broken up into separate modules that may increment their versions independently.
So Selectors Level 4 may make Recommendation before CSS Backgrounds and Borders Level 3 does.
So, will CSS3 arrive? Eventually, but not all a once. So don't wait for it, start using it now (where applicable).
CSS3 has something like this in the works.
According to this, IE 8 will not support border-radius.
Any CSS property that starts with a dash (e.g. -moz, -webkit) is a browser-specific property.
This allows browser vendors to experiment with new CSS properties. Doing so is a common part of the process for writing new CSS specs, to allow web developers to see how the properties work and raise issues.
Hence you’ll find a lot of CSS 3 properties, like border-radius currently implemented in some browsers with vendor-specific extensions.
There’s nothing particularly wrong with using these on production sites, as long as you’re aware they’ll only work in the one browser.
CSS 3 should be out any decade now :)
Browser-based properties are only meant for interim fixes for that particular browser, and are supposed to be deprecated when either the W3C adopts them into CSS, or not. I wouldn't rely on them to be cross-browser or even be kept for the particular browser.