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