1 / 22

Model-checking Driven Security Testing of Web-based Applications

. A ANTSSAR. Model-checking Driven Security Testing of Web-based Applications. Giancarlo Pellegrino giancarlo.pellegrino@sap.com A joint work with: A. Armando armando@dist.unige.it R. Carbone carbone@dist.unige.it L. Compagna luca.compagna@sap.com K. Li kequi.li@sap.com.

palmer
Télécharger la présentation

Model-checking Driven Security Testing of Web-based Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A ANTSSAR Model-checking Driven Security Testing of Web-based Applications Giancarlo Pellegrino giancarlo.pellegrino@sap.com A joint work with: A. Armando armando@dist.unige.it R. Carbone carbone@dist.unige.it L. Compagnaluca.compagna@sap.com K. Li kequi.li@sap.com http://www.avantssar.eu/ • International Workshop • on Modeling and Detection of Vulnerabilities • April 10th, 2010

  2. Agenda • Introduction • A motivating example • Model-checking driven security testing of web-base applications • Our approach • Automatic Test Sequence Generation • Automatic Test Execution Engine • Assessment • Conclusions

  3. Introduction • A variety of techniques exists to unveil security flaws: • Automated reasoning techniques Model-checking • Detect flaws in the logic of distributed applications, but • no support to test actual implementations • Security Testing  penetration testing • Detect low-level vulnerabilities on the actual system, but • heavily relies on the user’s expertise • but they are normally used in isolation • Our contribution: • Combines Model-Checking with Security Testing • Model-Checking Driven Security Testing of Web-based Applications! • Automatic test cases extraction and execution • Assessment on a real world use case

  4. Case study: SAML-based SSO for G. Apps • Requirements: • Hospital takes advantage of web-based services to handle its basic IT services (email, calendar, …) • Keeps the control of the identity management • Employees are authenticated once to access to these outsourced services • Solution: • SAML-based Single Sign-On for Google Apps • Besides SP services (i.e. Docs, Gmail, Calendar), Google offers an easy-to-be-deployed IdPservice

  5. SAML Web Browser SSO profile: outline Google (SP) Doctor (C) Hospital (IdP) Google Calendar resource? Your credentials? SP asks for my credentials if then Here they are your credentials! My credentials You can access to Google Calendar

  6. SAML SSO vs SAML-based SSO for G. Apps Google (SP) Doctor (C) Hospital (IdP) …by Google

  7. An abstract attack to SAML-based SSO for G. Apps Abstract attack found via model checking: malicious medical insurance bob idp sp Ref. A. Armando, R. Carbone, L. Compagna, J. Cuellar and L. Tobarra. “Formal Analysis of SAML 2.0 Web Browser Single Sign-On: Breaking the SAML-based Single Sign-On for Google Apps”. October 27th, 2008

  8. A real attack to SAML-based SSO for G. Apps Is the abstract attack applicable on the actual implementation? Video: http://www.ai-lab.it/armando/GoogleSSOVulnerability.html

  9. Methodology applied so far • Modeling phase: • An abstract model amenable for formal analysis is specified • Model Checking • Validate the abstract model • Returns an abstract counter-example • Testing • Extraction of abstract messages from the counter-example • Concrete messages are built and sent to Google’s SP • Analysis of responses Informal Protocol Spec. Modeling Formal Specification Test Model Checking Counter-example Test Result

  10. Our approach • Modeling phase: • An abstract model amenable for formal analysis is specified • Message Mappings • Model Checking • Validate the abstract model • Returns an abstract counter-example • Test Sequence Generation • Extract abstract test cases sequence from the counter-example • Test Execution Engine • Execute test cases sequence against the SUT • Produce a verdict Informal Protocol Spec. Modeling Message Mappings Formal Specification Model Checking Test Sequence Generation Counter-example Test Sequence Test Execution Engine Test Result Control Point Observation Point SUT

  11. Automatic Test Sequence Generation • System Under Testing: Google (sp); • Abstract counter-example found through Model Checking (MC): • Abstract test cases sequence: Informal Protocol Spec. Modeling S1. c -> i : c.i.uri_i A1. i -> c : c.idp.n.i.uri_i A2. c -> idp : c.idp.n.i.uri_i S1. i(c) -> sp : c.sp.uri_sp A3. idp -> c : i.{c.idp}_inv(kidp).uri_i A1. sp -> c : c.idp.id.sp.uri_sp A4. c -> i : i.{c.idp}_inv(kidp).uri_i A4. i(c) -> sp : sp.{c.idp}_inv(kidp).uri_sp S2. sp -> c : resource.uri_sp Message Mappings Formal Specification Model Checking Test Sequence Generation Counter-example Expected outputs from the SUT Abstract message to probe the SUT Test Sequence Test Execution Engine Test Result S1. i(c) -> sp : c.sp.uri_sp A1. sp -> c : c.idp.id.sp.uri_sp A4. i(c) -> sp : sp.{c.idp}_inv(kidp).uri_sp S2. sp -> c : resource.uri_sp Control Point Observation Point SUT

  12. Automatic Test Execution Engine Informal Protocol Spec. Test Execution Engine a"m== β(cm) ? Expected output of the SUT Message checking Modeling a"m Abstract test sequence Evaluation sp -> c : c.idp.id.sp.uri c -> sp : c.sp.uri Message Mappings Formal Specification am Abstract level β(cm) Concrete level Model Checking Test Sequence Generation α(am) Message abstraction Message generation Counter-example Test Sequence GET object HTTP/1.1 Host: calendar.google.com […] Control Point Test Execution Engine Observation Point Test Result SUT HTTP/1.1 302 Moved Temporarily Location: idp.com/?SAMLRequest=[…] Control Point Observation Point cm SUT

  13. Message Mappings Table • During the modeling phase: • A concrete message… • … is abstracted: • Mapping information and fields transformation are stored in 2 tables: Informal Protocol Spec. Modeling POST SP-Endpoint HTTP/1.1 Host: SP-Domain Content-Type: application/x-www-form-urlencoded Content-Length: xyz RelayState = UrlEncode(URIResource) & SAMLResponse= AuthnResponse(IDR, IIR, S, AuthAssertion(IDAA, IdP, IIAA, NB, NA, AI, C)) Message Mappings Formal Specification Model Checking Test Sequence Generation Counter-example A4. C -> SP: SP.{C.IdP}_inv(K_IdP).URI Test Sequence Test Execution Engine Test Result Concretization Mapping Table (CMT): Abstraction Mapping Table (AMT): h1(SP-EndPoint) = SP h2(SP-Domain) = SP h3(URIResource) = URI h4(IdP) = IdP h5(C) = C f1(SP) = SP-Endpoint f2(SP) = SP-Domain f3(URI) = URIResource f4(IdP) = IdP f5(C) = C Control Point Observation Point SUT

  14. Message Format Table • For each concrete message a Message Format is created • Composed by: fixed structure, field placeholders and directives • Stored in a table Informal Protocol Spec. Modeling POST $SP-EndPoint HTTP/1.1 Host: $SP-Domain Content-Type: application/x-www-form-urlencoded Content-Length: xyz RelayState = #Encode(URL, $URIResource) & SAMLResponse= #Encode(BASE64, <samlp:Response […] ID=$ID_R IssueInstant=$II_R […]> <Signature […]> <SignatureValue>$S</SignatureValue> </Signature> <Assertion […]> <Issuer>$IdP</Issuer> <Subject><NameID […]>$C</NameID></Subject> <Conditions […]></Conditions> <AuthnStatementAuthnInstant=$AI>[…]</AuthnStatement> </Assertion> </samlp:Response> ) Message Mappings Formal Specification Model Checking Test Sequence Generation Counter-example Test Sequence Test Execution Engine Test Result Control Point Observation Point SUT

  15. Message Generation Given an abstract message: Informal Protocol Spec. A4. c -> sp: sp.{c.idp}_inv(k_idp).uri_sp Modeling 1) Look up for the message format: POST $SP-EndPoint HTTP/1.1 Host: $SP-Domain RelayState = #Encode(URL, $URIResource) & SAMLResponse= #Encode(BASE64, <samlp:Response […] ID=$ID_R IssueInstant=$II_R […]><Assertion […]> <Issuer>$IdP</Issuer><Subject><NameID […]>$C</NameID></Subject> <Conditions […]></Conditions><AuthnStatementAuthnInstant=$AI>[…] </AuthnStatement> </Assertion></samlp:Response> ) Message Mappings Formal Specification Model Checking Test Sequence Generation Counter-example Test Sequence 2) Substitution of field placeholders according to CMT: f1(sp) = endpoint/ f2(sp) = calendar.google.com Test Execution Engine POST endpoint/ HTTP/1.1 Host: calendar.google.com[…] Test Result 3) Substitution of other fields (calculated at runtime such as timestamps): Control Point Observation Point […] <AuthnStatementAuthnInstant=‘2009-05-07T13:36:35Z’>[…]</AuthnStatement>[…] SUT 4) Directives computation: […] RelayState = https%3A%2F%2Fcalendar.google.com […]

  16. Message Abstraction Given a concrete message: Informal Protocol Spec. POST endpoint/ HTTP/1.1 Host: calendar.google.com Content-Type: application/x-www-form-urlencoded Content-Length: xyz RelayState = UrlEncode(https://calendar.google.com) & SAMLResponse= AuthnResponse(…, AuthAssertion(…, idp.ai-lab.it, …, username)) Modeling Message Mappings Formal Specification 1) Look up for the message format: POST $SP-EndPoint HTTP/1.1 Host: $SP-Domain RelayState = #Encode(URL, $URIResource) & SAMLResponse= #Encode(BASE64, <samlp:Response […] ID=$ID_R IssueInstant=$II_R […]> Model Checking Test Sequence Generation Counter-example Test Sequence 2) Parsing of the incoming message: SP-EndPoint = endpoint/ SP-Domain = calendar.google.com URIResource = https://calendar.google.com IdP = idp.ai-lab.it C = username Test Execution Engine Test Result 3) Calculation of abstract value according to the AMT: Control Point Observation Point h1(“endpoint/”) = sp h2(“calendar.google.com”) = sp h3(“https://calendar.google.com”) = uri_sp h4(“idp.ai-lab.it”) = idp h5(“username”) = c SUT

  17. Assessment • Since the flawed version of SAML-based SSO for Google Apps is no longer available • Google has fixed it in Sept. 2008 • We assessed our approach by comparing the HTTP messages generated with the ones captured previously • Outgoing messages were equivalent • We concluded that our system would have been able to detect the flaw Informal Protocol Spec. Modeling Message Mappings Formal Specification Model Checking Test Sequence Generation Counter-example Test Sequence Test Execution Engine Test Result Control Point Observation Point Store

  18. Conclusions • Proposed a methodology which combines Model-checking with Security Testing • It check whether security vulnerabilities discovered at model level affect actual implementations • It relates abstract to concrete levels (and the other way around) in a systematic way • Automatically derives and executes test cases • It is protocol independent and could be applied generally to any web-based security protocol Informal Protocol Spec. Modeling Message Mappings Formal Specification Model Checking Test Sequence Generation Counter-example Test Sequence Test Execution Engine Test Result Control Point Observation Point SUT

  19. Thank you

  20. More info

  21. Case study: SAML-based SSO for G. Apps • A. Johnson, CIO of the San Francisco Bay Pediatrics said: When it comes to our email systems, our doctors don’t have the time or the budgets to deal with managing technology or defending against spam [..] With Google Apps Premier Edition we don’t have to worry about downloading the latest spam filters or navigating unwieldy servers. This is where we let Google do what it does best, so we can do what we do best – help our patients. • http://www.google.com/intl/en/press/pressrel/google_apps.html

  22. The complete story

More Related