Re: More bollocks from biggots

Hi JF,

"JF Mezei" <jfmezei.spamnot@xxxxxxxxxxxxx> wrote in message
news:8cbf4$46119806$cef8887a$29108@xxxxxxxxxxxxxxx
More info on why Javascript is an evil security liability.

http://news.com.com/2061-10789_3-6172582.html?tag=nefd.aof

For anyone else who has the time to look this up (it's about five pages
before they start to tell you what they're talking about :-() can you please
give me an english version of the exact vulnerability scenario? "Evaluated
in the context of the malicious page" How? Only in one of these "mashup"s?
"Cross-site scripting" only? "JSON" only? "Client<--JavaScript-->Server"
only?

How is the malicious JavaScript staying in memory and o/riding contructor(s)
between _top pages? Or is it only in pages that write/evaluate/parse
something
executable from the server? (obviously outside of the normal html embeded
javascript that gets loaded with the page) The top level of DOM is the
Window isn't it? If I load a new page into window.top.location then are you
saying that the data and functionality in it are now vulnerable to dodgy JS
in another Window or Tab? I can understand that if you upload malicious JS
from somewhere then your history and cookies are fair game (and wikipedia
was explaining that if a "local" page is then loaded (presumable into a
(I)frame?) that page can be manipulated to give local-privs with IE) but I'd
just like to see an example of a top level window being set upon by a
pre-existing script session.

This particular vulnerability has been labelled "Javascript Hijacking" and
although
granted this is the end result, it was the hop skip and jump to get there
that lost me. I submit to you that although the symptoms manifested as
unpleasant JavaScript streaming out of your nostrils (and other orifaces
(orifii?)) the actual disease was, once again, that context-devoid,
fundamentally-flawed, piece o' ***, quasi-middleware, protocol: HTTP! (In
this case working in combo with some JS wrapper (JSON?)

Cookies? Bogus Session IDs? Browser's caching Username/Passwords? Multiple
Authorizations (potentially for each message)? Ajax
XMLHttpBollocks.Abort()? XML/Javascript/HTTP up and down the network again,
and again and again? How a multi-billion dollar/year industry can be
whirling around this pile of pooh, honestly escapes me! A Web-Server serves
up pages; don't expect it to be your middleware backbone anymore than
ODBC/JDBC!

Anyway, no one cares what I think so here's my question: - As I am now a
huge fan of Javascript/HTML/CSS/JavaApplets I would be extremely grateful if
someone could explain the above vulnerability (or A.N.Other) as it would
apply to a top level web-page that contains JavaScript but only
sends/receives
Application Data via a (at page-display time) pre-Authorized,
Connection-oriented, Context-Rich TCP/IP socket? No loading Javasctipt from
the server (except what comes in the page). No XMLHttpRequest. No JSON.
Diagrams are always good; maybe - (a) Arse (b) Elbow - and a laser pointer
:-)

Cheers Richard Maher

PS. I really like the idea of overriding the constructor for Object()! or
Array or String etc. That's gotta be worth some time!

PPS. Can anyone tell me how XHR inplements it's callback or upcall to the
browser (onreadystatechange())? If I were to have a seperate thread in an
Applet, is there anyway to craft a browser-acceptible event object and
somehow fireEvent() the result? Is the interface for mimicing the
Asynchronous part of AJAX and bridging Applet/Browser events out there
somewhere?

PPS. How are sites currently grabbing our windows login to use in Cookie
names? Java won't let us get it, so why does Javascript?

Just say no to Cookies!



.