Upload
wyoming-gallegos
View
33
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Web Services Security – A Survey. Abu Uddin Shamual Rahaman. Web Services. Open standard (XML, SOAP, etc.) based Web applications that interact with other web applications for the purpose of exchanging data. - PowerPoint PPT Presentation
Citation preview
1
Web Services Security – A Survey
Abu Uddin
Shamual Rahaman
2
Web Services
Open standard (XML, SOAP, etc.) based Web applications that interact with other web applications for the purpose of exchanging data.
Initially used for the exchange of data on large private enterprise networks, web services are evolving to include transactions over the public Internet.
Even though it’s framework in not 100% complete, people have been widely using it.
Heterogeneous, loosely coupled architecture.
3
Hello Web Services
4
Hello Web Services
5
Hello Web Services
6
Web Services Security
Importance of security in Web Services. Security Issues in Web Services. Our Survey.
7
Selected Papers
Threats and security of Web services - a theoretical short study-Rao, Radha Krishna
Web service security - vulnerabilities and threats within the context of WS-security-Holgersson, J.; Soderstrom, E.;
Web Service Composition: A Security Perspective-Carminati, B.; Ferrari, E.; Hung, P.C.K.;
Algorithm Exchange of a Security Control System for Web Services Applications-Nasution, B.B.; Kendall, E.A.; Khan, A.I.;
8
Paper 1: Threats and security of Web services - a theoretical short study
Various threats and remedies for web services. This paper mainly focuses mainly on three different
attacks: Dictionary Attack, Replay Attack, and Buffer Overflow.
Vital points in Web services security: Authentication Authorization Confidentiality Integrity Non-repudiation
All of these can be satisfied by using encryption except Authorization, where it can use SOAP messages.
9
Dictionary Attack
Reverse Turing Test. was developed to protect system from
automated program that launches dictionary attack.
combine the traditional password authentication with a challenge that is very easy to answer for a human but not possible for an automated program.
widely used by many web sites, such as Hotmail, Yahoo.
10
Dictionary Attack
Advantages of Reverse Turing Test: does not affect the usability. offers a much better protection. no special hardware or software is needed to implement.
Disadvantages of Reverse Turing Test: requires certain capabilities on the user side. can frighten the user who are unwilling to solve the riddles . can affect the scalability of the system. not optimal for large scale system.
11
Dictionary Attacks Java Cryptography:
Dictionary attacks take twice the time to break a simple protection algorithm than doubly protected password.
now used in various critical applications. Java Cryptography Architecture(JCA)
Java Cryptography Advantages: Portability permits controlled execution of less trusted code (vs.
Activex) fine grained permission control
Java Cryptography Disadvantages: complex dependencies on other system, OS, browser,
network(DNS), PKI flexible policies accepted by user may permit hidden
breaching interactions.
12
Dictionary Attacks
Secure Socket Layer (SSL): most popular transport layer security protocol for internet.
offers the basic security services of encryption, source authentication and integrity protection for data exchanged over underlying unprotected networks.
Many product and OS has support for SSL. Also many web services permits the SSL communication.
SSL has all available security functions that’s needed to make a project secure (authentication, asymmetric/symmetric encryption, MAC and certificates).
But the problem with SSL is that programmers have to know a lot of details about the OS, and system calls.
13
Replay Attack
When an attacker simply listens and sniffs the packets and then later he resends the same packet, it’s called replay attack.
The intruder might extract information and alter or inject his own information in the message stream.
easier to detect with Web Services.
14
Buffer Overflow
Buffer Overflow is one of the major threats on data integrity.
Some of the solutions to the buffer overflow problem are: Applying patch to the affected code that will
check the length of the data before saving it to the buffer.
Apply backup code to replace the overflowed one to gain back authorities of the system.
Use programming languages that has automatic bound checking .
15
Paper 2: Web Service Security – Vulnerability And Threats within the context of WS-Security
The security issues in Web Services Threats involved Incompatibility of traditional Security techniques WS-Security Basics WS-Security vs. Web Services Threats
16
Security Issues
Security of the information must be provided while the information is in transit and while it is in storage of the server
Similar criterion as of traditional security must be satisfied
17
Security Issues
Confidentiality Integrity Non-repudiation Authentication Authorization Availability
18
The threats
Maintaining Security while Routing Unauthorized access Parameter manipulation/malicious input Eavesdropping and Message Replay Denial of Service (DoS) Bypassing of Firewalls Immaturity of the platform
19
Short comings of Traditional Security mechanism
Traditional Security techniques works on the Lower level of the OSI stack of message transfer
Doesn’t provide security against Application level communication
20
OSI Stack
21
WS-Security
Is a new security standard Published in April 2004 Still incomplete but promising
22
WS-Security Basics
Adds security to the SOAP message Passes the security information in the Header of
the SOAP Message 3 Basic Elements
Security tokens XML Encryption XML Signature
23
WS-Security, Tokens
Tokens are the security artifact included in a SOAP message
Provide authentication and authorization Can use simple user id and password based
authentication Also capable of advanced certificate based
authentication like X.509
24
XML Encryption
A specification developed by W3C Prevents unauthorized access to the XML
document Require a decryption key to read the
Document Different part of the document may require
different key to decrypt
25
XML Encryption
Therefore XML Encrypted Document can have multiple recipients
Each recipient will use their own decryption key without violating the privacy of others
26
XML Signature
Also developed by W3C Serves the same purpose that of a traditional
signature Authenticates the credentials of the token This provides message integrity Just like XML Encryption different part of the
document may have different signature associated with it
27
WS-Security VS Threats
Remember the threats….. Maintaining Security while Routing Unauthorized access Parameter manipulation/malicious input Eavesdropping and Message Replay Denial of Service (DoS) Bypassing of Firewalls Immaturity of the platform
All of them satisfied except Denial of Service Bypassing of firewalls Immaturity of the platform
28
Ws-Security: The Road Map
29
Paper 3: Web Service Composition: A security Perspective
The papers describes a security conscious Web Service composition framework that supports different security requirement criterion imposed by different WS provider and requestor
30
Web Service Composition
31
Composition With Security Restrictions Different WS may have different security
requirement e.g. some WS may require the X.509 based authentication as a security measurement for authentication and authorization
Some service requestor may want his service to be processed by a WS that use P3P based privacy policy
32
Secure WS Broker ArchitectureImage ref [3]
33
Secure WS Broker Architecture
Four main components Modeler Web Services Locator Security Match Maker WSBPEL Generator
34
SWS Broker: Modeler
Given the service request try to build a work flow
For example given a task A The modeler tries to divide the task in a sequence of tasks say {A1, A2, A3, A4} which must be carried in sequence
The A1, A2 etc are the activities
35
SWS Broker: SWs Locator
The locator is actually a simple old fashioned Web Service locator that finds the Web Services that capable of servicing the request
The locator finds all the sets of Web Services that are capable of servicing A1, A2 etc.
36
SWS Broker: Match Maker
This is the model that employs the security constrains imposed by all the involved Web Service Providers and Requestors
The algorithm is explained with an example in the next slide
37
Match Maker: Algorithm/Methodology
Lets say the service locator provides the following WSs for each of the activities in previous example
38
Match Maker: Algorithm/Methodology
We can build a following tree structure for the Wss. (Figure
ref [3])
39
SWS Broker: WSBPEL
Web Service Business Process Execution Language
Beyond the scope of this Paper
40
Defining Security Requirement
All the previously mentioned techniques sounds easy
But how to search and compare security requirement and Constraints
WSDL, SOAP none provides such mechanism
41
Modeling Security Information
Two Classes Capability Description Constraint Description
Compatibility General Final
42
Capabilities Description
Uses SAML description of following type (Figure ref [3])
43
Compatibility Constraint Description
Compatibility Constraints can be put into the WSDL using the extensibility element of WSDL
44
Other Constraint Description
The other two constraint criterion general constraint and final constraint goes into the SOAP definition
45
Future Work
The author working on implementing additional constraints like quality of service constraints
They are trying to produce a better version of the Match Maker Algorithm
46
Paper 4: Algorithm Exchange of a Security Control System for Web Services Applications
Problem with WS-Security standard. This papers takes system approach rather
than analytical approach. Two parts of the paper:
TTSN(Trusted Tansient Simple Network) Architecture.
Algorithm Exchange.
47
Trusted Transient Simple Network
3rd parties in web services. it is necessary for each party to provide itself with a sophisticated
security system which can be very independently of any other middle parties.
The most frequent strategies to solve the security problem have mainly focused on already known risks. But such strategy will fail when an unknown risk occurs.
48
TTSN
TTSN General Architecture: The traffic package leaving from A
through one path will be sent back to B through the other path.
Also, B will also append the reversed traffic package to B with the response.
In this way, A will know enough information regarding the state of the transaction and some behavior of its counterpart.
Can be activated/deactivated dynamically
49
TTSN
TTSN Security control system:
Plant of the control system. If the plant is not stable, A must maintain the process in a
continuous stable state.
50
TTSN
The reasoning mechanism. Interdependency of all
security properties: Each property will be
occupied by an intelligent agent.
51
TTSN
TTSN’s main modules:
52
TTSN
By deploying co-operative intelligent agents, loosely coupled interrelationship and strong definition of policy and rules, the aim is that TTSN will be able to solve and handle any current and potentially new vulnerability and threats.
53
Algorithm Exchange:
Since web services performs XML-based transactions and most internet transaction perform secret key exchange, it is very likely to be intercepted.
The interceptor has a chance of cracking the content of the message sooner or later.
TTSN performs algorithm exchange instead of key exchange. Both parties dynamically exchanges their algorithm throughout
the session. Since both parties used their unique algorithm, the authors
claimed that, it will be really difficult, if at all possible, for the interceptor to crack the message performing a brute force analysis to the algorithm, NOT to the key.
no known techniques available to crack algorithm.
54
Algorithm Exchange
Reflection packages and serialized class features of JAVA.
Java class file issue. this method not only guarantee confidentiality,
but also authentication and message integrity. Since the algorithm is not known, any one else
cannot impersonate the sender. The recipient must deploy the previous
algorithm to check the integrity of the data validating the signature.
55
Implementation/Testing Methodology:
The authors have successfully implemented and tested a cryptographic algorithm exchange in a web service environment using IMB WebSphere Studio Device Developer(WSDD5.6) and JDK1.4.1
56
Implementation/Testing Methodology:
57
Implementation/Testing Methodology:
58
Implementation/Testing Methodology:
59
Implementation/Testing Methodology:
60
Implementation/Testing Methodology:
61
Implementation/Testing Methodology:
After the class was loaded it has been instantiated and the method has been extracted and invoked:
62
Comparison with other/similar technology On first glance, Algorithm Exchange looks like the mechanism
of IPSec or Opportunistic Encryption. On IPSec all algorithm must comply with IETF’s standards,
which are very common (DES, TripleDES, RC4 etc). A node cannot be embbeded with user’s own generated algorithm.
In Opportunistic Encryption nodes do not exchange algorithms, but they still exchange keys.
IPSec handles network-layer security to protect transactions from hardware or OS level attackers, while most security in web services deals with threats on higher level than IP layers, most of which are software level attackers.
No programming language other than Java can dynamically load a computer program during runtime. Object serialization and class reflection made such thing possible.
63
Conclusion
Web Services is yet not matured. Web Services Security is still infant. Our 4 papers.
64