[Dclug] problem in the sandbox (javascript vulnerability)

[Tim]

> the link should be http://www.backports.org/dokuwiki/doku.php
> <http://www.backports.org/dokuwiki/doku.php> 
> at "Security update for egroupware" is reference to
> "Cross-site scripting (XSS) vulnerability in index.php in phpSysInfo"

I see what you're talking about now.


> http://en.wikipedia.org/wiki/Cross-site_scripting
> <http://en.wikipedia.org/wiki/Cross-site_scripting>  states
> "When Netscape first introduced the JavaScript language, they realized
> the security risks of allowing a Web server to send executable code to a
> browser (even if only in a browser sandbox). One key problem with this
> is the case where users have more than one browser window open . . ."

Heh, glad you found that page, since I wrote at least half of it. ;-)


> This was the statement that had me concerned.
> At work we have a Java "web application" that opens up a few windows and
> if some of these are closed the rest of the "application" looses track
> of things, pops-up error messages.
> When I took the java language class in college (1999) the sandbox theory
> of security for applets offered a logic we could deal with.  Also there
> is the logic that the web browser is sandboxed, can't write to disk.
> Now we see XSS allows complete take-over with code injection.
> My question is whether the XSS vulnerability results from "same origin
> policy" more or less expanding the sandbox not to one page, but now to
> multiple pages that exchange code?  The sandbox logic is simple and
> practical to use, but it appears maybe too simple to use.

Generally XSS vulnerabilities result in a compromise of the same-origin
policy.  While local client-side sandboxes can sometimes be attacked
more effectively by leveraging cross-site scripting, it's generally the
site-to-site access controls that are circumvented in an XSS attack.

I'm not overly familiar with how Java applets enforce various sandboxing
techniques, but generally XSS is an issue of script injection into HTML
pages.  Java could be leveraged in an attack, but it's typically
JavaScript that's used (completely different technology, despite the
similar name, as I'm sure you know).

In summary, the chief concern with a vulnerability such as this is that
someone could find some way to inject script into the page and convince
other users to see that script, which could then compromise those
victims' sessions on that website.  Except in very specific cases,
end-user machines would not be at risk, just their access to the
vulnerable site.

HTH,
tim