[Owasp-dotnet] Application and Execution Context Identities
email at iseric.com
Mon Aug 7 19:51:46 EDT 2006
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-dotnet