Documenting threats and vulnerabilities in a web services infrastructure Lieven Desmet DistriNet Research Group, Katholieke Universiteit Leuven, Belgium

2 Overview  Context  Web applications architecture  Web services  Threat modelling for web services  Conclusion and open questions

3 Context  Threat modelling for web applications:  Coordinated by Microsoft and PWC  6 research groups:  Università Degli Studi Di Milano (SQL Server)  Technical University of Ilmenau (ASP.NET)  University of Salford (Active Directory)  COSIC, K.U.Leuven (Security Tokens)  DistriNet, K.U.Leuven (Web Services)  Sintef (Threat and Countermeasure Representation)

4 Context (2)  Identification and countering the most relevant threats  Focus on threats related to the underlying platform, technologies or programming language  Applicable by developers, particularly for Independent Software Vendors

5 Context (3)  Current results of different groups reported in the "Security in Microsoft.Net" panel on CMS2004  Panel papers are available on project's internal website:   Presentation of our approach, open for feedback

6 Web applications architecture  Web applications:  Distributed applications, using the HTTP protocol  Client-server model:  Browser or rich clients  Server-resident applications on the web and application server  Several server technologies: CGI, PHP, Java Servlets, JSP, ASP.NET, …

7 Web applications architecture (2) database server application server FW2FW company network 3 web serverclient FW1 smartcard reader mainframe, application server,... authentication & directory server client tierpresentation tierbusiness tierback-office tier

8 Web applications architecture (3) SQL server IIS ASP.NET COM+ FW2FW company network 3 IIS ASP.NET IExplorer.NET Framework FW1 smartcard reader ASP.NET Active Directory

9 Web services  Web service = XML messaging based interface to some computing resource, exchanging structured and typed information (↔ classic web application!)  Web services can be used as:  RPC implementation  Document based information flow

10 Web services (2)  Web service protocol:  Unidirectional  Asynchronous  Often combined into a bidirectional synchronous protocol  Web service protocol stack:  Transport: HTTP (or FTP,SMTP,…)  Messaging: SOAP  Service description: WSDL  Service discovery: UDDI

11 Web services (3)  Communication participants:  Originating node  Receiving node  Possibly some intermediary nodes receiving node originating node intermediate SOAP

12 Web services in web applications  Web services in web applications:  Wrapping legacy applications  Better web server – application server separation  Rich clients, interfacing to the server  Integration of building block services  Multistage processing  Virtual organisations  …

13 Threat modelling for web services  Our approach:  Defining the web service assets  Systematic STRIDE-based enumeration of threats for a generic web service  Mapping attack entry points to the architecture  Listing countermeasures  Guidelines and questions for countermeasure selection

14 Web service assets  Web service assets:  Application specific assets:  specific data, procedures, …  Web service specific technology artefacts:  WSDL files, assemblies, SOAP messages, …  Private information on the client machine  Availability originating node SOAP receiving node

15 STRIDE for web services  STRIDE:  S poofing  Both client en server can be spoofed  T ampering  SOAP messages, WSDL descriptions and client/server assemblies  R epudiation  I nformation Disclosure  SOAP messages, WSDL descriptions, client/server assemblies and application specific data  D enial of Service  E levation of privileges originating node SOAP receiving node

16 Most relevant threats  Spoofing of client requests  SOAP message replay  SOAP message tampering  WSDL file tampering  Reverse engineering of client assemblies  SOAP message disclosure  WSDL files unnecessarily disclosed  Bad error handling  Server denial of service  Exposing legacy software vulnerabilities  …

17 Mapping to the architecture back-end (mainframe, database,...) application server FW2FW company network 3 web serverclient FW1 DMZ Rich client Web server BrowserWeb server SOAP HTTP Application Server SOAP Web serverWrapped Legacy Application SOAP Application Server SOAP Application Server originating node SOAP receiving node

18 Countermeasures  Countermeasures:  Authentication  Data protection  Authorization  Input Validation  Others: non-repudiation, sandboxing, secure coding, intrusion/fraud detection, …

19 Countermeasures (2)  A lot of countermeasure technologies exist already:  Web service specific:  XML Security (XML Encryption & XML Signature)  WS-Security  SAML  Network specific countermeasures  Operating system specific countermeasures  Platform specific counter measures  …  The major challenge is choosing the right countermeasure technology and applying it correctly.

20 Countermeasure selection  Questions/issues for ‘authentication’:  authenticate a user or a machine?  entity authentication or message authentication  delegation needed?  assumptions about the authenticated party  the number of users?  application access to authenticated identities?  integrate in an existing infrastructure?  security versus ease-of-use?  Related with data protection/authorization needs

21 Conclusion and open questions  Conclusion:  Importance of threat modelling and countermeasure selection  Applicability of the STRIDE approach  Open questions:  Importance of delegation within web applications  Applicability of current countermeasure selection to developers  Better ways to represent threat modelling and countermeasure enumeration and selection (e.g. CORAS)  Web services are both too easy and too difficult ?

22 Credential delegation  No delegation:  Controlled delegation:  Impersonation:  Composite’s delegation:  Traced delegation:. ABCD A BC ABCD A A’ ABCD A AA ABCD A B,AC,B ABCD A B,AC,B,A

23 Questions & discussion ?? ? ? ? Lieven Desmet DistriNet Research Group, Katholieke Universiteit Leuven, Belgium