Interesting but would truing off XSS scripting in ,htaccess make a difference?
Evil CSS injection bug warning: Don't let hackers cross paths with your website
Developers should check their websites for path-relative stylesheet import (PRSSI) vulnerabilities, which can allow miscreants to hijack web pages and steal login cookies, security researchers have urged. PRSSI flaws were documented by Gareth Heyes early last year; he calls them relative path overwrites. The trick is to lure …
COMMENTS
-
Friday 20th February 2015 11:59 GMT Doctor_Wibble
I've obviously missed something critical here - how is it that a browser requesting something that doesn't exist is being given anything other than a 404 or some handler thereof? If you haven't gone past the last slash then it's still a path and not a file so why is a file being sent?
I know there used to be severe problems for browsers that couldn't handle a 404 when a script src was supposed to be coming from somewhere that didn't have it, is this a similar thing resulting from a bit of duff coding, potentially at both ends?
-
Friday 20th February 2015 12:32 GMT The Mole
Its a webserver serving a dynamic page there's no need for the url to bare any relation to files on a file system at all. The website may be configued to pass anything after showthreads.php into the php script - which the script may then just ignore.
The route of the problem would seem to be the browser is way too lenient with parsing css and will pull definitions out of any old junk.
-
Friday 20th February 2015 12:43 GMT Kubla Cant
The route of the problem would seem to be the browser is way too lenient with parsing css and will pull definitions out of any old junk.
You shouldn't rely on browsers for security. The problem is that the server hasn't parsed the request URL properly. I just seems to have scanned it from the left until it found something that looks like the script name and assumed that anything after is a querystring. I can't believe many servers do this.
BTW, the expression is "root of the problem". The analogy is to plants, not navigation.
-
Friday 20th February 2015 13:37 GMT John G Imrie
The problem is that the server hasn't parsed the request URL properly.
Sorry the web server has parsed the URL properly.
A URL is <scheme> "://" <server-name> ":" <server-port> <script-path> <extra-path> "?" <query-string>
See that extra-path bit.
The URL to resource translator in a web server can do several things but once it decides to walk the file system it will go down the URL until it finds something that maps to a file rather than a directory. Anything else is passed through to the file. In the old days of CGI scripting it ended up in the PATH_INFO environment variable.
-
Friday 20th February 2015 14:56 GMT Doctor_Wibble
Re: The problem is that the server hasn't parsed the request URL properly.
> See that extra-path bit.
I have to say I've never used it, and if something isn't part of locating the object being requested then it really ought to be put as a parameter and TBH this particular 'feature' strikes me as being more of a kludge than anything else.
Doesn't mean it's not a useful thing, I just don't recall seeing that in any definition of 'URL' but maybe my books are too old.
-
-
-
-
-
Friday 20th February 2015 12:40 GMT Mage
There are related vulnerabilities
I've seen emails alleging to be from linkedin with links that have linkedin's real domain at start of URL that are meant to load something else.
Very many plugins for Drupal and Wordpress are STILL being written with cross site scripting, rights elevation or sql flaws.
There is obviously something wrong with the way Web applications are being developed and deployed.
-
Saturday 21st February 2015 02:30 GMT Anonymous Coward
Eh?
From my naive reading of the article without going to the source, how on earth does "mysite" cause trouble via "somesite".
I presume that the author meant that the link called "mysite.ninja" would actually link to "mysite.ninja" in a special way. Many forums show what a link really points to and browsers will show it on mouse over as well.
SpamAssassin and ClamAV with Sane Security extras etc will almost certainly take a dim view of these links in emails BTW. I'm sure that McAfee, Norton, Sophos etc will also get upset
-
Saturday 21st February 2015 10:23 GMT Tannin
Just another IE bug
Two points:
1 If you have something to say, please say it. As things stand, the article hints at a few things and skates glibly over a few more, but doesn't actually say anything of substance. At least not that I can detect. Has any other reader managed to figure out exactly what is being said here? (If anything.) One is left to trawl the links looking for the bacon in the sandwich.
2: Having learned (I think) what the vulnerability is (no thanks to the vague Reg article), I'm damned if I can figure out what the excuse is for calling it a "CSS vulnerability" instead of what it apparently is, just another IE vulnerability which (so far as I can glean) applies only to a version of IE so ancient that one might as well write up new bugs in Netscape Navigator 4.
What is the excuse (if any) for calling an IE bug a "CSS bug"? I am left to presume that the only purpose is to scam a headline few clicks, 'coz an actual CSS vulnerability would be important must-read news, where finding another bug in the long-obsolete nine-year-old Internet Explorer 7 is like finding a lump of horse poo in a dungheap. It's hardly news.
PS: If there *is* in fact some substantial backing to justify the rather hysterical headline, and it *isn't* just another ancient IE bug, please have the goodness to tell someone about it. You could start with Reg readers.
-
Tuesday 24th February 2015 11:40 GMT albinowax
Re: Just another IE bug
There are two things here, the attack technique and the vulnerability in phpBB3.
The attack technique itself works in all modern browsers - expression() support definitely isn't a requirement. It's often possible to hijack accounts using generic, cross-browser CSS. See the 'Malicious CSS' section in http://blog.portswigger.net/2015/02/prssi.html for more info on this, and also http://p42.us/css/ .
The phpBB3 vulnerability is IE specific since phpBB uses a modern doctype, but it works in IE11. The proof of concept in the linked post doesn't use expression(), because as you say this would limit it to older IE versions. Expression() is actually supported in IE10 and under, but only under the right conditions, which phpBB3 doesn't have.
Hope that makes sense!
-