Package Instance

URL Redirection to Untrusted Site (Open Redirect)
`SimpleSAMLphp` allows remote attackers to bypass an open redirect protection mechanism via crafted authority data in a URL.

Information Exposure
SimpleSAMLphp contain an information disclosure vulnerability. The module controller in `SimpleSAML\Module` that processes requests for pages hosted by modules, has code to identify paths ending with `.php` and process those as PHP code. If no other suitable way of handling the given path exists, it presents the file to the browser. The check to identify paths ending with `.php` does not account for uppercase letters. If someone requests a path ending with e.g. `.PHP` and the server is serving the code from a case-insensitive file system, such as on Windows, the processing of the PHP code does not occur, and the source code is instead presented to the browser. An attacker may use this issue to gain access to the source code in third-party modules that is meant to be private, or even sensitive. However, the attack surface is considered small, as the attack will only work when SimpleSAMLphp serves such content from a file system that is not case-sensitive, such as on Windows.

SimpleSAMLphp Reflected Cross-site Scripting vulnerability
When sending a SAML message to another entity, SimpleSAMLphp will use the URL of the appropriate endpoint to redirect the user’s browser to it, or craft a form that will be automatically posted to it, depending on the SAML binding used. The URL that’s target of the message is fetched from the stored metadata for the given entity, and that metadata is trusted as correct.

However, if that metadata has been altered by a malicious party (either an attacker or a rogue administrator) to substitute the URLs of the endpoints with javascript code, SimpleSAMLphp was blindly using them without any validation, trusting the contents of the metadata. This would lead to a reflected XSS where the javascript code is sent inline to the web browser, and if SimpleSAMLphp is not using a strict Content Security Policy to forbid inline javascript (which is the case of the default user interface), then the code will be executed in the end user’s browser.

Incorrect signature verification of SAML 1 messages
An incorrect check of return values in the signature validation utilities allows an attacker to get invalid signatures accepted as valid by forcing an error during validation. get those messages accepted as valid and coming from a trusted entity. In practice, this means full capabilities to impersonate any individual at a given service provider. This vulnerability is not to be confused with the one described and related to SAML 2 messages.

Improper Certificate Validation
Signature validation bypass in simplesamlphp.

Cross-site Scripting
Reflected Cross-Site-Scripting in simplesamlphp.

Session Fixation
SimpleSAMLphp might allow attackers to obtain sensitive information, gain unauthorized access, or have unspecified other impacts by leveraging incorrect persistent NameID generation when an Identity Provider (IdP) is misconfigured.

Information Exposure
The `SimpleSAML_Session` class in SimpleSAMLphp allows remote attackers to conduct timing side-channel attacks by leveraging use of the standard comparison operator to compare secret material against user input.

Information Exposure
SimpleSAMLphp makes it easier for man-in-the-middle attackers to obtain sensitive information by leveraging use of the `aesEncrypt` and `aesDecrypt` methods in the `SimpleSAML/Utils/Crypto` class to protect session identifiers in replies to non-HTTPS service providers.

Invalid token creation and validation
The `SimpleSAML_Auth_TimeLimitedToken` class in SimpleSAMLphp allows attackers with access to a secret token to extend its validity period by manipulating the prepended time offset.

SimpleSAMLphp vulnerable to XXE in parsing SAML messages
When loading an (untrusted) XML document, for example the SAMLResponse, it's possible to induce an XXE.

Incorrect IV generation for encryption
The `aesEncrypt` method in `lib/SimpleSAML/Utils/Crypto` makes it easier for context-dependent attackers to bypass the encryption protection mechanism by leveraging use of the first bytes of the secret key as the initialization vector (IV).

Improper Verification of Cryptographic Signature
A SimpleSAMLphp Service Provider using SAML will regard as valid any unsigned SAML response containing more than one signed assertion, provided that the signature of at least one of the assertions is valid. Attributes contained in all the assertions received will be merged and the entityID of the first assertion received will be used, allowing an attacker to impersonate any user of any IdP given an assertion signed by the targeted IdP.

Cross-site Scripting
The consentAdmin module in SimpleSAMLphp is vulnerable to a Cross-Site Scripting attack, allowing an attacker to craft links that could execute arbitrary JavaScript code on the victim's web browser.

Duplicate Advisory: SimpleSAMLphp signature validation bypass
A signature validation bypass issue has been found in the `SimpleSAML_XML_Validator` class. This class performs the verification of the XML digital signature of a SAML 1 message with a given key.

When a SAML 1 authentication response message is received, it is processed to verify its authenticity, including a check for the signature or signatures included in the message. If the message is not signed but the assertions contained in it are, the signatures of those assertions signed will be verified. Unsigned assertions will not be verified. After verifying every signed element in the response, a list of valid nodes is built, holding the DOM nodes of those XML elements that are signed and whose signatures have been successfully verified.

Once this list is built, the assertions need to be processed individually. They are not processed until the getAttributes() method of the SimpleSAML_XML_Shib13_AuthnResponse class is called. This method iterates through the list of assertions contained in the response and makes sure they were validated in the previous signature verification step, by checking if their corresponding DOM nodes are in the list of those verified.

The vulnerability is due to lax comparison of the node being checked and the nodes in the verified list. The isNodeValidated() method of the SimpleSAML_XML_Validator class checks if a given DOM node is in the validNodes array by means of the standard in_array() function. This function, however, will return unexpected results due to the default lax behaviour when checking data types in PHP. In this case, the fact that there is a DOM node in the list is enough for in_array() to return true when looking for any DOM node. This means any unsigned assertion will be considered verified if there is at least one assertion with a valid signature in the message being processed.

This issue allows an attacker to generate a SAML 1 authentication response that contains two different assertions. The first assertion is the one the attacker wants the Service Provider to use, with custom attributes, expiration and even entityID (provided that the given entityID belongs to an Identity Provider that the Service Provider knows and trusts). The second is a legitimate assertion issued and signed by an Identity Provider trusted by the Service Provider. If the second assertion is still valid when sent by the attacker, SimpleSAMLphp will merge all the attributes found in both assertions, but the entityID registered for the authenticating third-party will be the one found in the first, tampered assertion. If the second (legitimate) assertion is already expired when the attacker sends it, only the attributes found in the tampered assertion will be used.

The issue can be easily fixed by passing a third parameter to the in_array() function, telling it to perform strict comparisons when checking if an object is found inside a given array. This way, when the code evaluates if the tampered assertion is included in the list of verified assertions, it fails and only the legitimate assertion is used, if possible (e.g. it is not expired).

Session fixation issue and authentication bypass
The `secureCompare` method in `lib/SimpleSAML/Utils/Crypto` when used with PHP, allows attackers to conduct session fixation attacks or possibly bypass authentication by leveraging missing character conversions before an XOR operation.