[Owasp-dotnet] Application and Execution Context Identities

mikeiscool michaelslists at gmail.com
Mon Aug 7 20:00:59 EDT 2006


On 8/8/06, Eric Swanson <email at iseric.com> wrote:
>  I have been researching issues with validating application identity and
> execution context (environment) recently.
>
> What are your thoughts/comments/suggestions/etc?
> (interested in platform independant solutions as well as specific
> guidelines/toolkits/libraries/software/etc.)
>
> One of the most difficult scenarios I have brainstormed has been:
> A client has a Microsoft-based website hosted by a 3rd party.  The host
> exposes a SQL Server database so that the client can connect remotely.  The
> client's website stores a single encrypted connection string to communicate
> with the database.  Now, if an attacker were to obtain all of the website's
> files, they could execute the application from a completely different
> domain, including writing their own code to interface with the application.
>
> *This example can be extended to any publically exposed service that
> requires authentication parameters, but relies on the application to provide
> them without requiring user interaction (web services, XML-RPC, AJAX,
> remoting, etc.).
>
> I have identified a couple of ways to help protect an application from
> out-of-context execution, but none of them are fail-safe:
>
>
> Store and communicate an application identifier somewhere other than the
> website file system that the website code can access.  This may not be
> possible in many hosted environments.  This also does not protect your
> application from someone with access to this "secret" location, or a
> compromised system.
>
> Store and communicate a list of trusted domains and IPs.  These can be
> spoofed.  Web farms and network communications can also introduce elements
> of complexity.
>  Additionally, many programmers do not take the time to secure execution of
> their code in a web environment (i.e. once someone obtains the website's
> code they often have "free reign" over the code's execution).  As you can
> see, the concern isn't simply the application-supplied authentication
> credentials (like a database connection string), but the direct manipulation
> of an application's code execution (like writing a custom class to
> initialize the website's data access layer and carry out a series of
> unsavory commands).
>
> Ideally, all of a website's support services (databases, application server
> APIs, etc.) would only be exposed on an internal network not available to
> the public so that communications inherently depend on internal execution
> context.  However, the reality is much different.

As usual the answer to how to secure a hardcoded file is to keep the
password of the server. If your attack scenario is someone stealing
the source code [i.e some file download attack, or stolen backup tapes
or something], then it's trivial to protect it with a required 'server
initialisation' phase.

That is, until you have visit: https://foo/setKey.whatever and entered
in the application key, the system cannot run.

The app will then use the key, decrypt the connection string or
whatever else, and then release the key. We can then narrow the attack
scenario down to someone accessing a live running server and copying
the runtime to disk, or finding the connection string in memory. Alot
harder then simplying getting source files ...


> Eric Swanson
> http://www.ericis.com/

-- mic




More information about the Owasp-dotnet mailing list