保护 Web 服务免遭“XML 注入”
目前，我们的客户来自许多不同的公司，他们访问我们的网络服务。许多新客户属于特许经营权的一部分，并且希望访问同一特许经营权内的公司数据。
之前，我们将存储在其身份验证凭证中的公司 ID 的哈希值与他们请求数据的公司 ID 的哈希值进行比较，从而确保每个公司无法向其他公司请求数据。但是，此方法将不再起作用，因为客户端可能需要访问另一个客户端的数据。
问题是，防止“XML 注入”（如果它被称为“XML 注入”）的“最佳方法”是什么？在“XML 注入”中，有人可以拦截发送的 Web 请求并修改 XML，意图查看竞争对手的数据。
到目前为止，我想到的唯一方法是维护服务器端客户端层次结构（例如，客户端 A/B/C 是特许经营权 A 的一部分），以便我们知道谁是哪个特许经营权的一部分，并在检索数据之前进行显式检查。
我注意到很多关于如何保护网络服务访问的问题，这不是我要问的。
Currently we have clients that belong many different companies who access our web services. A number of new clients are part of a franchise and want access to company data within the same franchise.
Previously we compared a hash of the company id stored in their authentication credential to the hash of the id of the company they were requesting data for, thus ensuring each company could not request data for another company. However, this method will no longer work as a client may need to access another clients data.
The question is, what is the "best way" to prevent 'XML Injection' (if that's what it is called) where someone could intercept the sent web request and modify the XML with intent to look at a competitors data.
The only method I've come up with so far is to maintain a server side client hierarchy (e.g. Client A/B/C are part of Franchise A) so we know who is part of which franchise and explicitly check before the data is retrieved.
I've noticed many questions on how to secure web service access, this is not what I'm asking.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你似乎有两个问题。
阻止 HTTP 请求被拦截以及第三方使用凭证
这将是中间人攻击。
解决方案很简单，通过 HTTPS 而不是纯 HTTP 传输数据来使用加密。
阻止一个客户端未经许可访问另一客户端的数据
这是一个不同的问题，这是解决它的正确方法。
存储每个用户可以访问的数据集的列表（或其他数据结构）。对于每个请求，将请求的数据与访问用户的凭据与访问控制列表进行比较。
You seem to have two problems.
Stopping the HTTP request being intercepted and credentials being used by a third party
This would be a man-in-the-middle attack.
The solution is simple, use encryption by transferring the data over HTTPS instead of plain HTTP.
Stopping one client from accessing the data of another client without permission
This is a different problem, and that is the correct approach to solve it.
Store a list (or other data structure) of which sets of data can be accessed by each user. On each request, compare the requested data combined with the credentials of the accessing user with the access control list.
不要试图在已有的“损坏的”凭证检查之上添加额外的复杂性。相反，修复凭据检查。
问题是什么？您用来检查访问的“凭据令牌”是公司 ID（它的哈希值，但没有任何区别）。
如何修复它？干脆不要使用公司 ID——使用更好的东西来代替。
例如：当有人针对您的 Web 服务进行身份验证时，不要根据他们的公司 ID 向他们提供身份验证令牌。给他们一个“访问域”的身份验证令牌（让我们在这里创建一个抽象实体）。让数据库中的每个公司以一对多关系映射到任意数量的“访问域”。
每当有人请求数据时，请查看哪些访问域包含该数据（例如，检查所请求数据的公司位于哪些域中）。如果凭证令牌授权访问这些域中的任何一个，请继续提供数据。
这只是当前凭证基础设施的基本扩展，它将满足您的需求，同时保持无会话状态（我想缺乏会话状态正是系统最初被设计成这样的原因）。
当然请注意：
Don't try to fit an extra layer of complexity over the "broken" credential check you already have. Fix the credential check instead.
What is the problem? The "credential token" you use to check access is the company id (a hash of it, but it doesn't make any difference).
How to fix it? Simply don't use the company id -- use something better instead.
So for example: when someone authenticates against your web service, don't give them an auth token based on their company id. Give them an auth token of (let's create an abstract entity here) an "access domain". Have each company in your database be mapped in a one-to-many relationship to any number of "access domains".
Whenever someone asks for data, see which access domains include that data (e.g. check what domains the company whose data is requested is in). If the credential token authorizes access to any of these domains, go ahead and provide the data.
This is just a basic extension of your current credential infrastructure that will serve your needs while remaining sessionless (I imagine lack of session state is exactly why the system was designed like that in the first place).
Of course note that: