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
Copy file name to clipboardExpand all lines: README.md
+35Lines changed: 35 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -178,6 +178,37 @@ environment is not secure and will be exposed to attacks.
178
178
179
179
In production also we highly recommended to register on the settings the IdP certificate instead of using the fingerprint method. The fingerprint, is a hash, so at the end is open to a collision attack that can end on a signature validation bypass. Other SAML toolkits deprecated that mechanism, we maintain it for compatibility and also to be used on test environment.
180
180
181
+
182
+
### Avoiding Open Redirect attacks ###
183
+
184
+
Some implementations uses the RelayState parameter as a way to control the flow when SSO and SLO succeeded. So basically the
185
+
user is redirected to the value of the RelayState.
186
+
187
+
If you are using Signature Validation on the HTTP-Redirect binding, you will have the RelayState value integrity covered, otherwise, and
188
+
on HTTP-POST binding, you can't trust the RelayState so before
189
+
executing the validation, you need to verify that its value belong
190
+
a trusted and expected URL.
191
+
192
+
Read more about Open Redirect [CWE-601](https://cwe.mitre.org/data/definitions/601.html).
193
+
194
+
195
+
### Avoiding Reply attacks ###
196
+
197
+
A reply attack is basically try to reuse an intercepted valid SAML Message in order to impersonate a SAML action (SSO or SLO).
198
+
199
+
SAML Messages have a limited timelife (NotBefore, NotOnOrAfter) that
200
+
make harder this kind of attacks, but they are still possible.
201
+
202
+
In order to avoid them, the SP can keep a list of SAML Messages or Assertion IDs alredy valdidated and processed. Those values only need
203
+
to be stored the amount of time of the SAML Message life time, so
204
+
we don't need to store all processed message/assertion Ids, but the most recent ones.
205
+
206
+
The OneLogin_Saml2_Auth class contains the [getLastRequestID](https://github.com/onelogin/php-saml/blob/f08bc1e8321cc8b855481153a26b9ed57a5201c2/lib/Saml2/Auth.php#L623), [getLastMessageId](https://github.com/onelogin/php-saml/blob/f08bc1e8321cc8b855481153a26b9ed57a5201c2/lib/Saml2/Auth.php#L709) and [getLastAssertionId](https://github.com/onelogin/php-saml/blob/f08bc1e8321cc8b855481153a26b9ed57a5201c2/lib/Saml2/Auth.php#L717) methods to retrieve the IDs
207
+
208
+
Checking that the ID of the current Message/Assertion does not exists in the list of the ones already processed will prevent reply
0 commit comments