You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The TLDR is that XML canonicalization may result in a different value being signed from the one being retrieved.
264
+
The target of this is the NameID in the Subject of the SAMLResponse Assertion
265
+
266
+
Example:
267
+
The following Subject
268
+
```<Subject>
269
+
<NameID>user@user.com<!---->.evil.com</NameID>
270
+
</Subject>```
271
+
would get canonicalized to
272
+
```
273
+
<Subject>
274
+
<NameID>user@user.com.evil.com</NameID>
275
+
</Subject>
276
+
```
277
+
Many XML parsers have a behavior where they pull the first text element, so in the example with the comment, a vulnerable XML parser would return `user@user.com`, ignoring the text after the comment.
278
+
Knowing this, a user (user@user.com.evil.com) can attack a vulnerable SP by manipulating their signed SAMLResponse with a comment that turns their username into another one.
279
+
*/
280
+
281
+
// To show that we are not vulnerable, we want to prove that we get the canonicalized value using our parser
282
+
_, el, err:=parseResponse([]byte(commentInjectionAttackResponse))
283
+
require.NoError(t, err)
284
+
decodedResponse:=&types.Response{}
285
+
err=xmlUnmarshalElement(el, decodedResponse)
286
+
require.NoError(t, err)
287
+
require.Equal(t, "phoebe.simon@scaleft.com.evil.com", decodedResponse.Assertions[0].Subject.NameID.Value, "The full, canonacalized NameID should be returned.")
0 commit comments