David said:
Richard said:
On Mar 12, 1:47 am, Garrett Smith wrote:
Security Advisory to any Dojo users:
| If you have Dojo 0.4 through Dojo 1.4 installed on your site, you
| are strongly encouraged to read all of this message and take
|immediate action.
<URL:
http://dojotoolkit.org/blog/post/dylan/2010/03/dojo-security-advisory/
You may need to increase the font size or change the styles so the
text is darker. The site uses text color #555, with 12px fixed
font-size on white background. Depending on the user's vision and
monitor's device-to-pixel ratio, that may be unreadable (it was
for me).
JSONP is a security issue as well, and yet I don't see Dojo or
others abandoning that idea...
JSONP is not a security issue in itself. It is a point where a poor
implementation may introduce a security vulnerability, but properly
handled (suitably escaped[1] so that no data can become executable
code, not treating any data that does arrive as defining executable
code, and not making the mistake of thinking that javascript object
literals are JSON, rather than the restricted sub-set of object
literals that are (a very common misconception)) there should be no
risk.
And given the slap-dash nature of Dojo (and similar) projects, I think
it is a fair bet that most fall into the poor implementation category.
The Dojo code is full of comments that appear to be written by children
(e.g. "IE sux bad"). Doesn't inspire confidence that responsible
professionals are monitoring the effort. They seem to be willing to
dump any submission into the mix with only the feeble scrutiny of the
other participants. It is hard to imagine how companies get talked into
putting trust in something like that.
Here is the bug report:-
http://bugs.dojotoolkit.org/ticket/10773
It seems that it took six years (and outside intervention) to determine
that it is a stupid idea to do something like this:-
window.dojoUrl = "../../dojo/dojo.js";
window.testUrl = "";
window.testModule = "";
// parse out our test URL and our Dojo URL from the query string
var qstr = window.location.search.substr(1);
So this "qstr" variable could hold _any_ string. And why are they using
the non-standard substr method rather than substring?
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Objects/String/substr
"ECMA Version: None, although ECMA-262 ed. 3 has a non-normative section
suggesting uniform semantics for substr"
if(qstr.length){
var qparts = qstr.split("&");
for(var x=0; x<qparts.length; x++){
var tp = qparts[x].split("=");
if(tp[0] == "dojoUrl"){
window.dojoUrl = tp[1];
}
Do not augment host objects.
[...]
Here is one of the vulnerabilities. Clearly the "dojoUrl" is built from
the potentially malicious string (qstr).
document.write("<scr"+"ipt type='text/javascript' djConfig='isDebug:
true' src='"+dojoUrl+"'></scr"+"ipt>");
Never mind the clueless use of unnecessary concatenation or the
non-standard attribute, but they've dumped a URI without encoding it.
Having been through much of the Dojo code, I can confirm that multiple
rookie gaffes per line is the norm. As there are hundreds of files with
hundreds of lines each, it stands to reason that this thing should be
avoided like the plague. After all, it's not like they are splitting
atoms here.
And at the top of this file is an example of their comments, which often
indicate confusion as well as outright admissions of failure (e.g.
"don't work in Opera"):-
<!--
NOTE: we are INTENTIONALLY in quirks mode. It makes it much easier to
get a "full screen" UI w/ straightforward CSS.
-->
In what universe?
It is useful to note that this is not "IBM's toolkit" (a common
misconception). At least as much as the much-ballyhooed (and
ever-changing) widgets go, it's largely the work of "bill" and a few
similarly clueless cronies (and virtually nobody does any significant
work on the core, which they see as "solid"). I remember bumping into
this guy in the trac when he noticed how much I had changed in my branch
and warned me that he wouldn't accept any of the changes unless I could
demonstrate that they worked in "all browsers" on "all platforms". This
is ironic coming from a guy who uses more UA sniffs per function than
I've ever seen (and that's saying something). I remember others voiced
the same concern, but couldn't grasp that their code would never run in
"all browsers". It's all about what they can see and feel (in the
latest versions of a handful of browsers) and don't talk to them about
abstractions as it seems to induce headaches (judging from the typically
bitchy responses I got when pointing out outrageous gaps in their logic).
It's such a bizarre contradiction as this same guy chastised a bug
reporter for complaining that their app fell apart in IE8, pointing out
that the version of Dojo used did not claim to "support" IE8 (of course
not, IE8 wasn't available for marathon observation sessions when the
older version of Dojo was cobbled together). It's the same thing with
all of the five or so browsers they profess to "care" about (meaning the
ones they've peered at endlessly to determine how their code can appear
to "work" with them). If you used Dojo 1.3, your app has some shot of
"working" in IE7, Safari 3 and Opera 9, but if you use Dojo 1.4, it is
unlikely to stand up to the latter two (so tell all of your visitors to
hurry up and download Safari 4 or Opera 10). And if your visitors may
be using IE8, then _you_ better hurry up and upgrade to Dojo 1.4. Round
and round it goes and yet the Dojo developers are still oblivious to
their own insanity (what they call "pragmatism").
Regarding this ridiculous (and painfully obvious) security problem,
which apparently dates back six years, "bill" had this (very typical)
response:-
"Thanks for the reminder about encodeURIComponent(). I think for DOH
runner we'd need to use encodeURI() rather than encodeURIComponent(), to
let the "/" characters through."
Why did he need a reminder about encodeURIComponent in 2010? He goes on
to argue:-
"Like I said above, I don't think any of these values would legitimately
contain special characters, because these values are used to construct
file paths, and also because a theme name with (for example) a ">"
character would terribly break CSS selectors."
Legitimately? And as for passing "theme" names, to the present they
have exactly two of those, which makes me wonder why they bothered with
them at all. Both are full of CSS parse hacks and redundancies (theme
name repeated endlessly in each file) as well as classes named after
browsers (which are added by more browser sniffing). And while they are
busy adding more (so as to "compete" with other bloated and ill-advised
frameworks like YUI and ExtJS), nobody has been paying attention to the
swiss cheese-like code that implements them.
JFTR, you don't need theming for Web widgets. They very idea is silly
as it implies you would use the same source for every widget (in this
case the source is "bill"). If an enterprise is naive enough to use
some of his inaccessible form control replacements, does that mean they
should also use his crappy editor, popup menus, etc.?
They seem to have a hard time justifying these "themes" (or are they
skins?) in their own Wikipedia entry:-
http://en.wikipedia.org/wiki/Dojo_toolkit
"Skins can be used such as tundra, soria, and others in order to change
the look and feel of dijit.Editor along with all other Dojo elements
that are used within the same page."
Yep, "tundra" and "soria" are the two. I've never seen any others.
"Other online rich-text editor programs such as TinyMCE use independent
skinning which can be a disadvantage in comparison to a unified approach."
So the "reasoning" seems to be that you will have to actually create CSS
to make one widget look like another and it would be a be sounder
strategy to leave CSS to people who demonstrate no proficiency at all in
its creation and, as a side effect, be stuck with widgets implemented by
people who seemingly can't write a single line of Javascript without
committing numerous and obvious blunders.
But I digress. Here is one final related (and typically argumentative)
note from someone who is clearly unqualified to argue about browser
scripting:-
"So, one could argue that it's odd to call encodeUri...() on a value
that should never need encoding. But it could be argued either way, it's
a philosophical thing."
JFTR, I think this bunch (they all sound the same) would have made a
pretty lousy philosophers as well.
