Question

I’m familiar with the use of the context object design pattern – a lightweight context wrapper around objects passed between tiers.

If one were to use the context object to track taint (untrusted user input), or the origin tier, I could see how a receiving tier could dynamically filter, encode, or validate accordingly.

For example:
A user sends “HTTP/HTML” context data which will eventually be stored as a file on the system. The file save method could detect the context and decode HTML entities, assign a random identifier to the file upload, and associate the user action and the file-name in the database.

My question is: how is that any smarter than applying all filtering, encoding and validation by default? What cases exist where knowing the origin context improves security beyond just good input validation/encoding?

I’m working in Java/J2EE/Struts but this is generalizable to other languages and frameworks.

References:

http://www.corej2eepatterns.com/Patterns2ndEd/ContextObject.htm

http://www.cs.wustl.edu/~schmidt/PDF/Context-Object-Pattern.pdf

http://www.owasp.org/index.php/Category:OWASP_Security_Analysis_of_Core_J2EE_Design_Patterns_Project

With my thanks,

-Ben

Answer 1

I don’t know that taint tracking between application tiers is the best application of the Context Object pattern. As I understand it, a Context Object is an object that stays within a single tier and provides services to multiple messages passing through that tier.

Where I could see this being of use as a security mechanism is in the creation of an explicit security layer within your application. Imagine that as each user authenticates with your system, a Security Context Object is created within the security layer for that user. The Security Context Object contains a list of all that user’s permissions. Every request that enters the system from any user must first pass through the security layer and be evaluated against the user’s Security Context Object.

If the request is allowed, the security layer passes it up the stack to the higher layers for processing. If the request is denied, the security layer returns an error to the user and the rest of the application is none the wiser. Centralizing security concerns within the security layer prevents the scattering of security checks throughout the business and service layers.

In this case the Security Context Object implements the Context Object pattern. The context object is long-lived, providing context to multiple user requests, but is not visible to the higher or lower layers in the request stack.