Web Services Security – A Survey

abdomendebonairSecurity

Nov 2, 2013 (3 years and 8 months ago)

79 views

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 Architecture

Image 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


3
rd

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