[WEB SECURITY] On sandboxes, and why you should care
Stephen de Vries
stephen at corsaire.com
Fri Mar 31 03:00:41 EST 2006
I think you're overestimating the effectiveness of a sandbox in
preventing common web app vulnerabilities, and you're instead
focussing on the tiny fraction of specific attacks that can be
stopped with sandboxes. The fundamental point of departure between
our points of view is that I would argue that, the crown jewels are
already inside the sandbox! So spending time and effort to
strengthen the walls isn't going to do any real good in preventing an
attacker from getting hold of them.
> Also remember that more and more we will have to deal with malicious
> developers, or with malicious attackers that are able to inject
> malicious code into a website via:
> - a library used by a developer
> - a compromised developer account details (which tend to be
> sent by
> - a compromised developer computer (infected via Spyware) which
> allows the malicious attacker to control remotely that computer and
> (for example) path Eclipse or Visual Studio in memory so that every
> time a piece of code its submitted (checked-in) , the malicious
> payloads are inserted.
I don't follow your argument here. You're saying that by running in
a sandbox we would prevent a developer with malicious intent from
executing evil code(?). Granted that a sandbox may limit specific
operations such as writing or reading from the OS or making network
connections, but that doesn't mean you would prevent them from
accessing all the private data in the database or from allowing one
user to view another's data. Sandboxing is not going to make any
difference here, but external controls such as vetting your
developers and auditing the code would make a very real contribution
to improving the security.
> If you add up the number of people that have the capability to put one
> line of malicious code on a web server, you will see that this is a
> very large number indeed.
And that one line of malicious code can do a lot of damage _even in a
> A couple more examples of ways malicious code can be uploaded to the
> server: SQL Injection, XSS (payload deployed to the admin section),
> authorization vulnerabilities which allow the editing of files on the
> server (via for example the CMS (content management system)),
> manipulating params which control which method is executed (when
> Reflection is used to perform late binding on method calls based on
> the commands received) ,Social engineering, etc...
> Sometimes you will even find CMS (Content Management Systems) that
> provide power users (or 'area x' admins) with powerful customization
> features which when exploited (or not, depending if this is a
> 'feature') allow the injection of code.
> Do you really think that it is a good idea to have your entire data
> center security and CIA (Confidentiality, Integrity and Availability)
> depended on such extraordinary set of circumstances?
> So the first main security benefit that we have with using Sandboxes
> is: Containment, Damage Limitation, and Risk Reduction (you went from
> full data center compromise to a local and limited problem)
This only applies to environment where the value (to an attacker) of
compromising the data centre and web server is more than the value of
compromising the application itself. In the majority of web
applications, the data stored by the app itself is the nazi gold -
not the webserver or surrounding infrastructure. So sandboxing the
app will not add any protection to the stuff I care about most: my data.
> So let's look at another application (App B) which has the same
> functionality but, is executed in three Sandboxes:
> - Sandbox A) 450,000 lines of code executed in very restricted
> Sandbox (let's say Asp.Net Low Trust)
> - Sandbox B) 48,000 lines of code executed in secure Sandbox (let's
> say customized version of Asp.Net Medium Trust)
> - Sandbox C) 2,000 lines of code executed in a Sandbox which allows
> calls to unmanaged code.
> Given the same 1 week, you (as the security consultant auditing this
> application) will spend most of your time in Sandbox C) code, less on
> Sandbox B) code and even less on Sandbox A) code. Why? because only a
> vulnerability in Sandbox C) would allow the compromise of the entire
> App / Server / Datacenter.
I disagree. Any one of those 450,000 lines of perfectly sandboxed
and verifiable code could contain an SQL injection attack that would
compromise my entire database. They could also contain access
control flaws that let unauthenticated users access private
information. Or allow an attacker to use an XSS flaw to steal a
session cookie. Running in a sandbox would not prevent _any_ of
these serious security issues, all of which could compromise the
security of my data.
To summarise, sandboxing an app is useful in preventing specific
attacks such as executing OS commands, making unauthorized
connections and accessing arbitrary system resources but it will not
do anything to prevent the vast majority of serious security issues
affecting web apps, because the valuable stuff is inside the sandbox.
Stephen de Vries
E-mail: stephen at corsaire.com
Tel: +44 1483 226014
Fax: +44 1483 226068
The Web Security Mailing List
The Web Security Mailing List Archives
More information about the websecurity