Re: More bollocks from biggots

Richard Maher wrote:
"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?

As I read it then it works as follows.

It is a vulnerability in web sites that:
- uses cookies for session maintenance
- uses AJAX
- support HTTP GET for AJAX requests
- has known URL's for AJAX requests either because it is
a public web site or because someone has inside knowledge
- use JSON as transport format instead of XML (then it is
really AJAJ and not AJAX but ...)
- does not "protect" the JSON

It works like:
- innocent user login into the vulnerable web site and
get a valid session
- after that he goes to a malicious web site
- the malicious web site send a page with some JavaScript
- that JavaScript:
- hook in some code to run if an object with a
field name "x" is created
- insert a SCRIPT tag in the HTML pointing to an AJAX request
URL in the vulnerable web site
- the browsers requests the URL and executes it because it is a
SCRIPT tag
- as part of that execution an object is created
- because the object has a field "x" the hook code is executed
and send a copy of the data to the malicious web site

Best workaround:
- use XML as transport

Second best workaround:
- "protect" the JSON data so it can not be executed by a
SCRIPT tag

How is the malicious JavaScript staying in memory and o/riding contructor(s)
between _top pages?

It is not.

Or is it only in pages that write/evaluate/parse
something
executable from the server?

It is in a page from a malicious web site and uses a hole in the
web app from the vulnerable web site.

(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?

Read above.

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?)

It is not a HTTP problem. It is not a JavaScript problem.

It is a problem with JSON. And to some extent a problem of
poor checking in the server side web app.

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!


It is a way of doing a client application.

It is quite popular.

That bugs are found rarely kills a concept (very little IT would
exist if that were the case).

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
:-)

Your app is not at risk for this problem.

Arne
.