“上下文对象”是如何实现的？使用设计模式来增强安全性？
我熟悉上下文对象设计模式的使用 - 围绕层之间传递的对象的轻量级上下文包装器。
如果要使用上下文对象来跟踪污点（不受信任的用户输入）或原始层，我可以看到接收层如何相应地动态过滤、编码或验证。
例如： 用户发送“HTTP/HTML”上下文数据，该数据最终将作为文件存储在系统上。文件保存方法可以检测上下文并解码 HTML 实体，为文件上传分配随机标识符，并将用户操作与数据库中的文件名关联起来。
我的问题是：这比默认情况下应用所有过滤、编码和验证更聪明吗？在哪些情况下，了解源上下文可以提高安全性，而不仅仅是良好的输入验证/编码？
我正在使用 Java/J2EE/Struts，但这可以推广到其他语言和框架。
参考文献：
http://www.corej2eepatterns.com/Patterns2ndEd/ContextObject.htm
< a href="http://www.cs.wustl.edu/~schmidt/PDF/Context-Object-Pattern.pdf" rel="nofollow noreferrer">http://www.cs.wustl.edu/~schmidt /PDF/Context-Object-Pattern.pdf
谢谢，
-Ben
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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.