[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 108: Potential attack when using RST parameters from a targetsite - 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.
Artifact: spec / schema
Title: Potential attack when using RST parameters from a target site
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.
Same issue; WS-SecurityPolicy part
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:
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).