Re: More bollocks from biggots

Hi Arne,

Thanks for the reply (I've only just noticed it) and also for the other one
a while back.

It is a vulnerability in web sites that:
- uses cookies for session maintenance
: : : :
It is not a HTTP problem.

My point was that if a more stateful, connection-oriented, and context-rich
protocol was deployed then most of the band-aids, fencing-wire, and
duct-tape, required to shoe-horn HTTP into the role of application middlware
protocol would be made redundant. That is, if you don't have to cache a
password, substitute a cookie for a password, or just leave the barn door
open, then the scope for exploitation will have been somewhat reduced.

Given your explanation of the vulnerability in this particular case, it
looks like no one was doing themselves any favours on the security front,
but I'm guessing that your definition of the vulnerability requirements was
a tad on the narrow side. Is it not fair to say that if you choose to
execute uploaded Javascript then that Javascript will always be able to
assume any user's active network-wide persona(e)? (whether that takes the
form of Session-IDs, or cookies, or domain pre-authorization(s), or anything
else) In other words, if you don't close, disconnect, void, expire, *all*
credentials, connections, and any other protectable resources *before* you
leave trusted-page are you not *inevitably* courting trouble? (Let alone
data loss/theft)

[Best] workaround:
- use XML as transport

God help us!

It is a way of doing a client application.

It is quite popular.

So's McDonalds; and for a lot of the same reasons. (*Please* don't bring up
a McDonalds-bashing thread to go with the Global-Warning and
Guerrilla-philately threads! I eat a big-mac every now and then (and am
quite partial to a B&E McMuffin on the way to the beach) it's just that
McDonalds is what it is and so is HTTP)

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

Agreed, but no one talks long distance through two soup cans an a piece o'
string anymore do they? Things progress. Maybe a better analogy is to AJAX
and flicker-free partial updates; are any tree-huggers gonna cling
deperately to the Submit button? Things move on. Analogue TVs, Phones. .
..another pointless analogy :-)

Your app is not at risk for this problem.

Aaah, but how will you know for sure unless you test it :-)

Thanks again.

Cheers Richard Maher

"Arne Vajhøj" <arne@xxxxxxxxxx> wrote in message
news:4615b04f$0$90271$14726298@xxxxxxxxxxxxxxxxxx
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


.