[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue: Potential attack when using RST parameters from a target site - WS-Trust part
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON
THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has
occurred. Protocol: ws-trust Artifact: spec /
schema Type: design Title: Potential
attack when using RST parameters from a target site Description: When requestor inserts parameters into an RST request
which come from a third party – for example relying party policy –
there is a potential for an attack. Currently both requestor RST parameters and
third party RST parameters are mixed together as a direct children of the
wst:RequestSecurityToken element. This prevents STS to differentiate the RST
parameters based on their source. This means that both kinds of RST parameters
are trusted in the same way by the STS. This can open a potential attack vector
because the third party is given control over the content of the RST message
that the requestor sends to the STS and the STS cannot detect which parameters
came from which source in order to determine how much it should trust a
particular RST parameter. To mitigate the attack the RST should differentiate
between parameters originated by the requestor and parameters not originated by
the requestor. Related issues: Same issue; WS-SecurityPolicy part Proposed Resolution: We introduce a new parameter container within the RST
which holds parameters not originated by the requestor in the section 3.1 of
WS-Trust specification: /wst:RequestSecurityToken/wst:SecondaryParameters
If specified, this optional
element contains zero or more valid RST parameters (except
wst:SecondaryParameter) for which the requestor is not the originator. The STS processes parameters that
are direct children of the wst:RequestSecurityToken element. If a
parameter is not specified as a direct child, the STS MAY look for the
parameter within the wst:SecondaryParameters element (if present). The
STS MAY filter secondary parameters if it doesn't trust them or feels they are
inappropriate or introduce risk (or based on its own policy). Note that an alternate approach is to decorate RST
parameters but this makes processing more complex because of potential
instancing issues and may not be possible due to schema issues for RST
extensions (requiring additional wrapper elements anyway). |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]