--001517588560d841ef04713e3daf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Yep, sounds quite dangerous to me as well...

Another security problem might come from you allowing
users to manipulate the DOM (which I guess is one of the features you plan
on implementing, since without that, there isn't really much you can do in
JS
except some alerts maybe :-).

I'd definitely forbid that.
1. they could inject arbitrary text on the website, including spam,
links etc. and start phishing attacks and
2. due to the browsers executing every least bit of javascript they find,
they could just inject a string containing <script> tags, executing
any JS they want and steal user sessions, forward private data etc. etc.

IMHO it's already hard enough protecting the webapp from attacks from
the outside, but you also introduce an attackvector from the inside.

Greetz!

2009/8/16 Aaron Patterson <aaron / tenderlovemaking.com>

> On Sun, Aug 16, 2009 at 03:00:12PM +0900, pharrington wrote:
> > On Aug 15, 9:35 pm, Mongoose Sir mongoose <mongoos... / gmail.com>
> > wrote:
> > > Hello,
> > >
> > > I'm working on a site that is implementing similar functionality to _A
> > > Certain Large Social Networking Site_'s Apps feature.
> > >
> > > Application developers will be able to write apps in a hybrid HTML /
> > > "FooML" / JavaScript syntax.
> > >
> > > This will get parsed by my servers (as the man in the middle) and then
> > > shoved back to the user's browser as HTML.
> > >
> > > Now, my normal inclination is just to dive in and start coding away > > >
> > > But I figured one of the smart people here might have some good
> pointers
> > > on where to start.
> > >
> > > The tricky problems, as I see them:
> > >
> > > * Allowing access to some JavaScript functionality while stripping out
> > > malicious calls (document.cookies ?)
> > > * Also: how to deal with Base64 / eval / other tomfoolery that
> attackers
> > > might attempt
>

--001517588560d841ef04713e3daf--