Hi Dinis,
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.
<snip>
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
email)
- 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
sandboxed environment_.
<snip>
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.
<snip>
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.
cheers,
--
Stephen de Vries
Corsaire Ltd
E-mail: stephen@corsaire.com
Tel: +44 1483 226014
Fax: +44 1483 226068
Web: http://www.corsaire.com
-------------------------------------------------------------------------
This List Sponsored by: SpiDynamics
ALERT: "How A Hacker Launches A Web Application Attack!"
Step-by-Step - SPI Dynamics White Paper
Learn how to defend against Web Application Attacks with real-world
examples of recent hacking methods such as: SQL Injection, Cross Site
Scripting and Parameter Manipulation
https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
--------------------------------------------------------------------------
