documenting threats and vulnerabilities in a web services infrastructure lieven desmet distrinet...
TRANSCRIPT
Documenting threats and vulnerabilities in a web services infrastructure
Lieven Desmet DistriNet Research Group, Katholieke Universiteit Leuven, Belgium
2
Overview
ContextWeb applications architectureWeb servicesThreat modelling for web servicesConclusion and open questions
3
Context
Threat modelling for web applications:Coordinated by Microsoft and PWC6 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:
http://sobenet.cs.kuleuven.ac.be/usergroup/working/
Presentation of our approach, open for feedback
6
Web applications architecture
Web applications:Distributed applications, using the HTTP protocolClient-server model:
Browser or rich clients Server-resident applications on the web and application
serverSeveral server technologies: CGI, PHP, Java
Servlets, JSP, ASP.NET, …
7
Web applications architecture (2)
databaseserver
applicationserver
FW2 FW
company network
3
web serverclient
FW1
smartcardreader
mainframe,application server, ...
authentication& directory
server
client tier presentation tier business tier back-office tier
8
Web applications architecture (3)
SQLserver
IISASP.NET
COM+
FW2 FW
company network
3IIS
ASP.NETIExplorer
.NET Framework
FW1
smartcardreader
ASP.NET
ActiveDirectory
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 implementationDocument based information flow
10
Web services (2)
Web service protocol:UnidirectionalAsynchronousOften combined into a bidirectional synchronous protocol
Web service protocol stack:Transport: HTTP (or FTP,SMTP,…)Messaging: SOAPService description: WSDLService discovery: UDDI
11
Web services (3)
Communication participants:Originating nodeReceiving nodePossibly some intermediary nodes
receivingnode
originatingnode intermediate intermediate
SOAP SOAP SOAP
12
Web services in web applications
Web services in web applications:Wrapping legacy applicationsBetter web server – application server separationRich clients, interfacing to the serverIntegration of building block servicesMultistage processingVirtual organisations…
13
Threat modelling for web services
Our approach:Defining the web service assetsSystematic STRIDE-based enumeration of threats
for a generic web serviceMapping attack entry points to the architectureListing countermeasuresGuidelines 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 machineAvailability
originatingnode
SOAP receivingnode
15
STRIDE for web services
STRIDE:Spoofing
Both client en server can be spoofedTampering
SOAP messages, WSDL descriptions and client/server assembliesRepudiation Information Disclosure
SOAP messages, WSDL descriptions, client/server assemblies and application specific data
Denial of ServiceElevation of privileges
originatingnode
SOAP receivingnode
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, ...)
applicationserver
FW2 FW
company network
3
web serverclient
FW1
DMZ
Rich client
Web server
Browser Web server
SOAP
HTTP
Application ServerSOAP
Web server Wrapped Legacy ApplicationSOAPApplication Server
Application ServerSOAPApplication Server
originatingnode
SOAP receivingnode
18
Countermeasures
Countermeasures:AuthenticationData protectionAuthorizationInput ValidationOthers: 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:
.
A B C DA B C
A B C DA A’ A’
A B C DA A A
A B C DA B,A C,B
A B C DA B,A C,B,A
23
Questions & discussion
? ??
??
Lieven DesmetDistriNet Research Group, Katholieke Universiteit Leuven, Belgium