PHPKB SAML SSO Security Compliance

1.1.1. Denial of Service:

The SAML protocol is susceptible to a denial of service (DOS) attack. Handling a SAML request is potentially a very expensive operation, including parsing the request message (typically involving construction of a DOM tree), database/assertion store lookup (potentially on an unindexed key),construction of a response message, and potentially one or more digital signature operations. Thus, the effort required by an attacker generating requests is much lower than the effort needed to handle those requests.

1.1.2. Requiring Signed Requests

PHPKB SAML SSO plugin/module signs request, also narrows the order of the asymmetry between the work done by the SAML plugin and responder. The additional work required of the responder to verify the signature is a relatively small percentage of the total work required of the responder, while the process of calculating the digital signature represents a relatively large amount of work for the requester. Narrowing this asymmetry decreases the risk associated with a DOS attack. Note, however, that an attacker can theoretically capture a signed message and then replay it continually, getting around this requirement. This situation can be avoided by requiring the use of the XML Signature element <ds:SignatureProperties> containing a timestamp; the timestamp can then be used to determine if the signature is recent. So the narrower the window of valid signature after the issue of response, the higher security you have against replay denial of service attacks.

2.1. HTTP Redirect binding

2.1.2. Denial of Service

Threat: Malicious redirects to Identity Provider or Service Provider targets.

Description: A spurious entity could issue a redirect to a user agent so that the user agent would access a resource that disrupts Single Sign-On. For example, an attacker could redirect the user agent to a logout resource of a service provider causing the Principal to be logged out of all existing authentication sessions.

Countermeasures: Access to resources that produce side effects are specified with a transient qualifier that must correspond to the current authentication session. Alternatively, a confirmation dialog could be interposed that relies on a transient qualifier with similar semantics.

2.2. HTTP POST binding

2.2.1. Stolen Assertion

Threat: If an eavesdropper can copy the real user’s SAML response and included assertions, then the eavesdropper could construct an appropriate POST body and be able to impersonate the user at the destination site.

Countermeasures: We maintain confidentiality whenever a response is communicated between SAML SSO plugin and the user’s browser. This provides protection against an eavesdropper obtaining a real user’s SAML response and assertions. If an eavesdropper defeats the measures used to ensure confidentiality, additional countermeasures are available:

1. The Identity Provider and Service Provider sites SHOULD make some reasonable effort to ensure that clock settings at both sites differ by at most a few minutes. Many forms of time synchronization service are available, both over the Internet and from proprietary sources.
2. When a non-SSO SAML profile uses the POST binding it must ensure that the receiver can perform timely subject confirmation. To this end, a SAML authentication assertion for the principal MUST be included in the POSTed form response.
3. Values for NotBefore and NotOnOrAfter attributes of SSO assertions SHOULD have the shortest possible validity period consistent with successful communication of the assertion from Identity Provider to Service Provider site. This is typically on the order of a few minutes. This ensures that a stolen assertion can only be used successfully within a small time frame.
4. The PHPKB SAML SSO plugin checks the validity period of all assertions obtained from the Identity Provider site and reject expired assertions. We choose to implement a stricter test of validity for SSO assertions, such as requiring the assertion’s IssueInstant or AuthnInstant attribute value to be within a few minutes of the time at which the assertion is received at the Service Provider site.
5. If a received authentication statement includes a <saml:SubjectLocality> element with the IP address of the user, the Service Provider site MAY check the browser IP address against the IP address contained in the authentication statement.

2.2.2. Forged Assertion

Threat: A malicious user, or the browser user, could forge or alter a SAML assertion.

Countermeasures: The browser/POST profile requires the SAML response carrying SAML assertions to be signed, thus providing both message integrity and authentication. The PHPKB SAML SSO plugin verifies the signature and authenticate the issuer.

2.2.3. Browser State Exposure

Threat: The browser/POST profile involves uploading of assertions from the web browser to a Service Provider site. This information is available as part of the web browser state and is usually stored in persistent storage on the user system in a completely unsecured fashion. The threat here is that the assertion may be “reused” at some later point in time.

Countermeasures: Assertions communicated using this profile must always have short lifetimes and should have a <OneTimeUse> SAML assertion <Conditions> element. Service Provider sites are expected to ensure that the assertions are not re-used.

2.2.4. Replay

Threat: Replay attacks amount to re-submission of the form in order to access a protected resource fraudulently.

Countermeasures: The PHPKB SAML SSO plugin mandates that the assertions transferred have the one-use property, preventing replay attacks from succeeding.

2.2.5. Modification or Exposure of state information

Threat: Relay state tampering or fabrication. Some of the messages may carry a <RelayState> element, which is recommended to be integrity-protected by the producer and optionally confidentiality-protected. If these practices are not followed, an adversary could trigger unwanted side effects. In addition, by not confidentiality-protecting the value of this element, a legitimate system entity could inadvertently expose information to the Identity Provider or a passive attacker.

Countermeasure: Follow the recommended practice of confidentiality- and integrity- protecting the RelayState data. Note: Because the value of this element is both produced and consumed by the same system entity, symmetric cryptographic primitives could be utilized.

3.1. Web Browser Single Sign-On (SSO) Profiles

Note that user authentication at the source site is explicitly out of scope, as are issues related to this source site authentication. The key notion is that the source system entity must be able to ascertain that the authenticated client system entity that it is interacting with is the same as the one in the next interaction step. One way to accomplish this is for these initial steps to be performed using TLS as a session layer underneath the protocol being used for this initial interaction (likely HTTP).

3.1.1. SSO Profile

3.1.1.1. Message Modification

Threat: The possibility of alteration of the messages in the stream exists for this set of profiles. Some potential undesirable results are as follows:

1. Alteration of the initial request can result in rejection at the SAML issuer, or creation of an artifact targeted at a different resource than the one requested
2. Alteration of the artifact can result in denial of service at the SAML consumer.
3. Alteration of the assertions themselves while in transit could result in all kinds of bad results (if they are unsigned) or denial of service (if they are signed and the consumer rejects them).

Countermeasures: To avoid message modification, the traffic needs to be transported by means of a system that guarantees message integrity from endpoint to endpoint. For the web browser-based profiles, the recommended method of providing message integrity in transit is the use of HTTP over TLS/SSL with a cipher suite that provides data integrity checking.

3.1.2. Single Logout Profile

Threat: Passive attacker can collect a Principal’s name identifier. During the initial steps, a passive attacker can collect the <LogoutRequest> information when it is issued in the redirect. Exposing these data poses a privacy threat.

Countermeasures: All exchanges should be conducted over a secure transport such as SSL or TLS.

Threat: An Unsigned <LogoutRequest> could be injected by a spurious system entity thus denying service to the Principal. Assuming that the NameID can be deduced or derived then it is conceivable that the user agent could be directed to deliver a fabricated <LogoutRequest> message.

Countermeasures: PHPKB SAML SSO plugin/module signs the <LogoutRequest> message. The Identity Provider can also verify the identity of a Principal in the absence of a signed request.

3.2. Name Identifier Management Profiles

Threat: Allow system entities to correlate information or otherwise inappropriately expose identity information, harming privacy.

Countermeasures: IDP must take care to use different name identifiers with different service providers for the same principal. The IDP should encrypt the name identifier it returns to the service provider, allowing subsequent interactions to use an opaque identifier.

3.2.1. Attribute Profiles

Threats related to bindings associated with attribute profiles are discussed above. No additional profile-specific threats are known.