[WEB SECURITY] document.domain / application security perimeter

Arian J. Evans arian.evans at anachronic.com
Tue May 13 14:21:04 EDT 2008


This is an excellent point about what I tend to
call "emergent behaviors" in pools of applications.

I've seen too many times over the years where
someone with n+10 applications, let alone someone
with n+50 applications, glues them together in
some fashion as the years go by.

Independently App A and App B may test out
fairly securely, or at least to a level of "acceptable
Risk" by business definition.

However, the minute they are glued together
in any fashion (and in this case, sharing a
domain could be enough) you have to treat
them all with the highest Risk profile as App
A can often lead to compromise of App B.

This is one area that both Threat Modeling
and Black Box testing shine. You could
of course find and fix all these vulns in
source, but the *implications* are what
drive corporate actions and these aren't
often evidenced until you have n + 2
apps running together with some glue.

This is also a reason an enterprise with
more than 2 sensitive applications needs
to be testing them in a holistic manner using
a platform that can cross-correlate vulns.
[insert bias here: since I work on a platform
that does this </disclaimer>]

I'm not sure if any desktop testing software
does this today, but cross-correlating impact
will only become more important in the future,
as more apps glue together (take all your
2.0 JS widgets) and there are too many
vulns for people to "fix them all"

Thanks again for this food for thought. You
made me think of some new JS-space
injection tests I want to try.

-ae

On Tue, May 13, 2008 at 12:35 AM, application.secure
application.secure <application.secure at gmail.com> wrote:
>
>
> Hello,
>
> I 've recently faced up to the document.domain usage in an application that
> we review.
> Developpers use this javascript command to allow javascript communication
> between 2 differents subdomains in the company.
>  In this case that was not really a security problem.
>
> But in point of view of an attacker this feature could be interesting.
> Imagine a big company  with 2 differents applications hosted on 2
> subdomains.
> application 1 => subdomain1.company.com
>  application 2 => subdomain2.company.com
>
> The first application is an e-commerce which is critical for application
> security (company spends time and money to secure this application).
> The second one is developped and managed by marketing service and is less
> critical.
>
> The first application is well protected against XSS(complete input
> validation) but it contains one issue: somewhere in the application you can
> inject and execute document.domain="company.com"
>
> The second one contains a lot of XSS basic issues so you can inject and
> execute a lots of XSS commands.
>
> By initializing document.domain=company.com in the second application, all
> XSS injected in this application can access the first application.
> The attacker has full control of application 1 via application 2.
>
> One small issue in your application extends your security perimeter.



-- 
-- 
Arian J. Evans.

I spend most of my money on motorcycles, mistresses, and martinis. The
rest of it I squander.

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list