[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-security
Subject:    Re: UI spoofing attacks
From:       David Hyatt <hyatt () netscape ! com>
Date:       1999-11-08 7:13:36
[Download RAW message or body]

that is exactly what we are doing.  you can still run remote xul.  you just
can't get to xpconnect and you can't access remote xul through a chrome url.

Dan203 wrote:

> Does this mean I won't be able to use XUL at all unless it's installed
> on the users hard drive??? What if I want to write a very simple web
> based app that opens a new window, only uses JavaScript to access the
> DOM, and uses XUL strictly for menus, toolbars, etc...? Am I still cut
> off? If so this sucks!!! Now I know I could simulate everything XUL does
> visually and structurally using XML, JavaScript, DOM and CSS but why
> reinvent the wheel. I think you should allow web page authors to load
> remote XUL files into new windows, and just cut off their access to
> XPConnect. This would eliminate the XPConnect security risk, but still
> allow web page authors access to the simplicity of the crossbrowser UI
> provided by XUL.
>
> Dan
>
> In article <381CE33F.E1A3DD29@postpagan.com>,
>   pete@postpagan.com (pete collins) wrote:
> > Mike Shaver wrote:
> >
> > > pete collins wrote:
> > > > Well then XUL and XP Connect = useless.  :-(
> > >
> > > Tell that to the people who are writing XP apps with that stuff
> _now_,
> > > like a browser, mail/news client, editor and IRC client.  They will
> be
> > > very interested in your argument, I'm sure.
> >
> > Oh come on you know what i am talking about . . .  Give me a break.
> >
> > > > The engineers of Netscape/AOL have developed a new technology that
> is
> > > > going to revolutionize application development,
> > > > and change the web and the world as we know it.
> > >
> > > Those would be the engineers of Mozilla.  Like David Hyatt, and Rob
> > > Ginda, and Ben Goodger.  Like you, maybe.  Grab your editor, I'll
> meet
> > > you at the tree.
> >
> > Good idea, but how about the back end of the editor that will require
> > dynamicly changed content (xul, js, html) driven by server apps, such
> as
> > GNU tools, Mysql, php, tcl, perl etc . . .
> > Or commercial server tools such as ASP, cold fusion, story server etc
> . .
> > This is the way web apps are currently developed.
> > Using client side browser runtime -- javascript and until M11 the new
> > mozilla XP Connect components,
> > To share in overall processing power over a network.
> >
> > > > "Goals
> > > > The XPToolkit has two major goals, in order of precedence
> > > > Make UIs easier to build
> > > > Make cross-platform applications easier to build"
> > > >
> > > > The only catch is that no one else will be allowed to use it . . .
> .
> > >
> > > Riiiight.  What keeps someone from writing a XUL app, again?  That
> they
> > > can't be bothered to write some packaging glue for it to stick it on
> the
> > > local disk?
> >
> > HUH??
> >
> > > If that's all, I have to confess that I'm not overly laden
> > > with sympathy.
> >
> > The point of a REMOTE app is to not rely on the client local disk for
> > dynamically creating, storing and retrieving content.
> > The package glue sits on the server, is parsed there and then recieved
> on
> > the client and parsed again client side with the browser.
> >
> > > > What are you guys on crack??
> > >
> > > Someone here is, I think.
> > >
> > > You can still build an app.  You can still use XUL and XPConnect.
> You
> > > just have to put your XUL on the local disk.  Write an XPInstall
> > > package, and it should be as simple as the user clicking and saying
> > > ``yes''.
> >
> > (Like i asked yesterday, where do i find out how to do this.)
> >
> > This hinders the advantage of having the latest code available to the
> end
> > user.
> > The exciting thing about this concept is that there is NO
> installation, NO
> > upgrading, nothing but a remote URL and the user having mozilla
> installed
> > on their local machine.
> > Be it mac, windows, any flavor of unix, beos, photon, Kiosk, space
> shuttle
> > food cart . . .
> >
> > > How were you going to get your entry into the chrome registry?
> >
> > I don't even know what the chrome registry is . . .
> >
> > > I think
> > > we've all been seeing that as an install-time configuration change,
> at
> > > which point why not install your app's XUL and JS locally?  Are you
> > > concerned about redeployment?  Should you also be concerned about
> people
> > > not being able to use your app when your web server goes down?
> >
> > That is what the internet and servers are all about.
> > Performing mission critical tasks to the business world.
> > If your laptop running some app locally bites the dust, who is really
> > screwed?
> > The local machine that is maintained by the end user, or a production
> > application server that is maintained by a technical staff, backed up
> > daily, running raid with 5 or 6 mirrors.
> >
> > You tell me who has a better chance of retrieving lost mission
> critical
> > data??
> >
> > The whole developement of Mozilla and mozilla tools are all server
> based!
> >
> > There seems to be a movement towards time sharing through remote
> > application deployment.
> > Mozilla did support this kind of advance. Until M11.
> > It seems with each milestone release  a door closes instead of opens.
> >
> > > > I thought the main goal of the mozilla project was to cell divide,
> > > > spawn off a multitude of UI's and cross platform  applications
> that
> > > > are going to change life as we know it?
> > >
> > > Was that your goal?
> >
> > Does it matter? Is this not a good thing??
> >
> > > I think you can still do a multitude of UIs and XP apps.
> >
> > How?  I really don't know . .
> >
> > > > Who's great idea was this?
> > >
> > > Those would be the people building the software you're bitching
> about, I
> > > think.
> >
> > When was i bitching about the software you guys have created?
> > I'm bitching about the fact that i can no longer use it!!!!
> >
> > > > I am utterly shocked and confused.
> > > >
> > > > Shouldn't this be a decision left to the mozilla community?
> > >
> > > It _is_ a decision left to the Mozilla community.  The parts of the
> > > Mozilla community that are implementing and designing these systems
> have
> > > decided what they want to implement and design for the 5.0 release.
> > > Imagine.  They've been talking about this for a long time, in the
> > > newsgroups, on IRC, etc.
> >
> > Well, forgive me man. I'm only on like 6 mozilla mailing lists. I
> forgot to
> > add security to those lists.
> > What is common knowledge to netscape folk is sometimes not as clear to
> > "black sheep" outside developers like myself.
> > You could have said some months back "Hey Pete, don't waste your time
> > developing a remote app using mozilla technology, because we don't
> want XP
> > Components to be used by remote files, even though they easily can"
> >
> > > If you would like to have the behaviour be otherwise, please send
> code
> > > that does the thing you want it to do, and discuss those changes in
> > > .xpfe and security.
> >
> > Well if need be, then i will take my two weeks vacation and try to
> code it.
> >
> > (I just know the wife and kids are not going to like this idea.)
> >
> > > Or maybe you could tell us some other XUL feature
> > > that you'd be willing to live without, in order to get this stuff
> > > working.
> >
> > Like i have said in other threads, I can live without having write
> access
> > to the clients local disk.
> > What is the security risk using: editorShell.InsertText(code) ???
> >
> > Why not block off whatever component that handles local file saving.
> > Remote apps do not need local disks to save files to, that is what the
> > server is for.
> >
> > > I can sorta see the value of allowing remote chrome-principalled
> > > XUL/JS/etc.,
> >
> > Well if you coded web apps for a living you would really see what i am
> > talking about!
> >
> > > but the mechanics of making it work securely are hard.
> >
> > This is all i am trying to learn dude.
> > But should i not voice my opinion to try to reveal something that
> perhaps
> > maybe is being overlooked?
> >
> > > Think about what it means for a user to add a remote-chrome app to
> their
> > > registry.  It doesn't mean ``I trust this given code from Pete
> Collins
> > > to do privileged things'', like it would if you installed a stable
> copy
> > > of it locally.  It means ``I trust whatever content will be at this
> URL
> > > in the future to do whatever it damned well pleases on my system,
> > > regardless of who put it there''.  I gotta admit, that scares me
> silly.
> >
> > But don't you see the potential of this situation?
> >
> > > I would never do that -- _maybe_ in an intranet setting, but even
> then
> > > someone would have to work hard to convince me -- and furthermore I
> > > would want _very_ strong cautionary langauge in the accept dialog.
> >
> > Like i said, if i can't write to your local drive then how much havoc
> can i
> > reap as a malicios developer??
> >
> > > FWIW, I think you can work around this issue, including ease of
> > > updating, by teaching your app to upgrade its own components when
> the
> > > user desired.
> >
> > Mike i am not trying to cause trouble.
> > But do you not see my point?
> >
> > pete
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

[prev in list] [next in list] [prev in thread] [next in thread]