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
+38-1Lines changed: 38 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -148,6 +148,37 @@ environment is not secure and will be exposed to attacks.
148
148
149
149
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.
150
150
151
+
152
+
### Avoiding Open Redirect attacks ###
153
+
154
+
Some implementations uses the RelayState parameter as a way to control the flow when SSO and SLO succeeded. So basically the
155
+
user is redirected to the value of the RelayState.
156
+
157
+
If you are using Signature Validation on the HTTP-Redirect binding, you will have the RelayState value integrity covered, otherwise, and
158
+
on HTTP-POST binding, you can't trust the RelayState so before
159
+
executing the validation, you need to verify that its value belong
160
+
a trusted and expected URL.
161
+
162
+
Read more about Open Redirect [CWE-601](https://cwe.mitre.org/data/definitions/601.html).
163
+
164
+
165
+
### Avoiding Reply attacks ###
166
+
167
+
A reply attack is basically try to reuse an intercepted valid SAML Message in order to impersonate a SAML action (SSO or SLO).
168
+
169
+
SAML Messages have a limited timelife (NotBefore, NotOnOrAfter) that
170
+
make harder this kind of attacks, but they are still possible.
171
+
172
+
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
173
+
to be stored the amount of time of the SAML Message life time, so
174
+
we don't need to store all processed message/assertion Ids, but the most recent ones.
175
+
176
+
The OneLogin_Saml2_Auth class contains the [getLastRequestID](https://github.com/onelogin/php-saml/blob/b8214b74dd72960fa6aa88ab454667c64cea935c/src/Saml2/Auth.php#L657), [getLastMessageId](https://github.com/onelogin/php-saml/blob/b8214b74dd72960fa6aa88ab454667c64cea935c/src/Saml2/Auth.php#L762) and [getLastAssertionId](https://github.com/onelogin/php-saml/blob/b8214b74dd72960fa6aa88ab454667c64cea935c/src/Saml2/Auth.php#L770) methods to retrieve the IDs
177
+
178
+
Checking that the ID of the current Message/Assertion does not exists in the list of the ones already processed will prevent reply
@@ -1384,6 +1419,8 @@ Auxiliary class that contains several methods to retrieve and process IdP metada
1384
1419
*`parseXML` - Get IdP Metadata Info from XML.
1385
1420
*`injectIntoSettings` - Inject metadata info into php-saml settings array.
1386
1421
1422
+
The class does not validate in any way the URL that is introduced on methods like parseRemoteXML in order to retrieve the remove XML. Usually is the same administrator that handles the Service Provider the ones that set the URL that should belong to a trusted third-party IdP.
1423
+
But there are other scenarios, like a SAAS app where the administrator of the app delegates on other administrators. In such case, extra protection should be taken in order to validate such URL inputs and avoid attacks like SSRF.
1387
1424
1388
1425
For more info, look at the source code; each method is documented and details
1389
1426
about what it does and how to use it are provided. Make sure to also check the doc folder where
0 commit comments