53
Web Applications and Services James Walden Northern Kentucky University

Web Applications and Services James Walden Northern Kentucky University

Embed Size (px)

Citation preview

Web Applications and Services

James Walden

Northern Kentucky University

CSC 666: Secure Software Engineering

Topics

1. OWASP Top 10 Security Risks

2. Web Server Security

3. Web Services Security1. XML

2. Xpath

3. WSDL

4. SOAP

Animations and diagrams from the OWASP Top 10 Project are licensed with a Creative Commons CC BY-SA 3.0 license.

3

OWASP Top Ten 2013

A1: Injection

A2: Broken Authentication

and Session Management

A3:Cross-Site Scripting (XSS)

A4: Insecure Direct Object References

A5: Security Misconfiguration

A6: Sensitive Data Exposure

A7: Missing Function Level Access Control

A8:Cross Site Request

Forgery (CSRF)

A9: Using Known

Vulnerable Components

A10: Unvalidated

Redirects and Forwards

InjectionA1

Fire

wal

l

Hardened OS

Web Server

App Server

Fire

wal

l

Dat

abas

es

Lega

cy S

yste

ms

Web

Ser

vice

s

Dire

ctor

ies

Hum

an R

esrc

s

Bill

ing

Custom Code

APPLICATIONATTACK

Net

wor

k La

yer

App

licat

ion

Laye

r

Acc

ount

s

Fin

ance

Adm

inis

trat

ion

Tra

nsac

tions

Com

mun

icat

ion

Kno

wle

dge

Mgm

t

E-C

omm

erce

Bus

. Fun

ctio

ns

HTTP request

SQL

query

DB Table

HTTP response

"SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’"

1. Application presents a form to the attacker.

2. Attacker sends an attack in the form data.

3. Application forwards attack to the database in a SQL query.

Account Summary

Acct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-0293

4. Database runs query containing attack and sends encrypted results back to application.

5. Application decrypts data as normal and sends results to the user.

Account:

SKU:

Account:

SKU:

4

CSC 666: Secure Software Engineering

You may be vulnerable if: User authentication credentials aren’t protected when stored

using hashing or encryption. See A6. Credentials can be guessed or overwritten through weak

account management functions (e.g., account creation, change password, recover password, weak session IDs).

Session IDs are exposed in the URL (e.g., URL rewriting). Session IDs are vulnerable to session fixation attacks. Session IDs don’t timeout, or user sessions or authentication

tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.

Session IDs aren’t rotated after successful login. Passwords, session IDs, and other credentials are sent over

unencrypted connections. See A6.

Broken Authentication and Session ManagementA2

CSC 666: Secure Software Engineering

An application should have a single set of strong authentication and session management controls. Such controls should strive to:

meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).

have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.

Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs. See A3.

Authentication/Session ProtectionA2

CSC 666: Secure Software Engineering

Cross-Site Scripting (XSS)A3

3

2

Attacker sets the trap – update my profile

Attacker enters a malicious script into a web page that stores the data on the server

1

Victim views page – sees attacker profile

Script silently sends attacker Victim’s session cookie

Script runs inside victim’s browser with full access to the DOM and cookies

Custom Code

Acc

ount

s

Fina

nce

Adm

inis

trat

ion

Tra

nsac

tions

Com

mun

icat

ion

Kno

wle

dge

Mgm

t

E-C

omm

erce

Bus

. Fun

ctio

ns

CSC 666: Secure Software Engineering

XSS Output Filtering (Escaping)A3

HTML Style Property Values

(e.g., .pdiv a:hover {color: red; text-decoration: underline} )

JavaScript Data(e.g., <script> some javascript </script> )

HTML Attribute Values(e.g., <input name='person' type='TEXT'

value='defaultValue'> )

HTML Element Content(e.g., <div> some text to display </div> )

URI Attribute Values(e.g., <a href="javascript:toggle('lesson')" )

#4: All non-alphanumeric < 256 \HH

ESAPI: encodeForCSS()

#3: All non-alphanumeric < 256 \xHH

ESAPI: encodeForJavaScript()

#1: ( &, <, >, " ) &entity; ( ', / ) &#xHH;

ESAPI: encodeForHTML()

#2: All non-alphanumeric < 256 &#xHH

ESAPI: encodeForHTMLAttribute()

#5: All non-alphanumeric < 256 %HH

ESAPI: encodeForURL()

CSC 666: Secure Software Engineering

Attacker notices his acct parameter is 6065:

?acct=6065

He modifies it to a nearby number:

?acct=6066

Attacker views the victim’s account information.

Insecure Direct Object ReferencesA4

https://www.onlinebank.com/user?acct=6065

CSC 666: Secure Software Engineering

Verify all object references are protected: For direct references to restricted resources, does

the application fail to verify the user is authorized to access the exact resource they have requested?

If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?

Ex: http://example.com/app/accountInfo?acct=NString query="SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt = connection.prepareStatement(query , … );

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

Insecure Direct Object ReferencesA4

CSC 666: Secure Software Engineering

Select an approach for protecting each user accessible object (object number, filename, etc.):

Replace direct with indirect object references.

Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object

Securing Object ReferencesA4

http://app?file=1Report123.xls

http://app?id=7d3J93Acct:9182374http://app?id=9182374

http://app?file=Report123.xlsAccess

ReferenceMap

CSC 666: Secure Software Engineering

Security MisconfigurationA5

Hardened OS

Web Server

App Server

Framework

App Configuration

Custom Code

Acc

ount

s

Fina

nce

Adm

inis

trat

ion

Tra

nsac

tions

Com

mun

icat

ion

Kno

wle

dge

Mgm

t

E-C

omm

erce

Bus

. Fun

ctio

ns

Test Servers

QA Servers

Source Control

Development

Database

Insider

Avoiding Security MisconfigurationA5 Verify your system’s configuration management

Development/testing to production mode changes.- Use production credentials instead of dev/test.

- Disable debugging and test features.

Secure configuration “hardening” guideline.- Automation is REALLY USEFUL here.

Keep up with patches for ALL components.- OS, server, libraries.

Can you “dump” the application configuration If you can’t verify it, it isn’t secure.

Verify the implementation

CSC 666: Secure Software Engineering

For all sensitive (PII, asswords, etc.) data: Is any of this data stored in clear text long term,

including backups of this data? Is any of this data transmitted in clear text, internally

or externally? Internet traffic is especially dangerous. Are any old / weak cryptographic algorithms used? Are weak crypto keys generated, or is proper key

management or rotation missing? Are any browser security directives or headers

missing when sensitive data is provided by / sent to the browser?

Sensitive Data ExposureA6

CSC 666: Secure Software Engineering

Attacker notices the URL indicates his role:

/user/getAccounts

He modifies it to another directory (role):

/admin/getAccounts, or

/manager/getAccounts

Attacker views more accounts than just their own.

Missing Function Level Access ControlA7

https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts

CSC 666: Secure Software Engineering

Verify every application function: Does the UI show navigation to unauthorized

functions? Are server side authentication or authorization

checks missing? Are server side checks done that solely rely on

information provided by the attacker?

Testing process Using a proxy, browse application with privileged role. Revisit restricted pages using a less privileged role. If server responses are alike, you're vulnerable.

Missing Function Level Access ControlA7

Cross-Site Request ForgeryA8

3

2

Attacker sets the trap on some website on the internet(or simply via an e-mail)1

While logged into vulnerable site,victim views attacker site

Vulnerable site sees legitimate request from victim and performs the action requested

<img> tag loaded by browser – sends GET request (including credentials) to vulnerable site

Custom Code

Acc

ount

s

Fin

ance

Adm

inis

trat

ion

Tra

nsac

tion

s

Com

mun

icat

ion

Kno

wle

dge

Mgm

t

E-C

omm

erce

Bus

. Fun

ctio

ns

Hidden <img> tag contains attack against vulnerable site

Application with CSRF vulnerability

CSC 666: Secure Software Engineering

Web applications use many third party components, which often have vulnerabilities. 26% of library downloads

contained vulnerabilities according to a 2010 Aspect Security study.

Inventory components and check for vulnerabilities. OWASP Dependency Check SafeNuGet (for .NET libraries)

Using Components with Known VulnerabilitiesA9

Struts

.NET Framework

CSC 666: Secure Software Engineering

Unvalidated Redirects & ForwardsA10

3

2

Attacker sends attack to victim via email or webpage

From: Internal Revenue ServiceSubject: Your Unclaimed Tax RefundOur records show you have an unclaimed federal tax refund. Please click here to initiate your claim.

1

Request sent to vulnerable site, including attacker’s destination site as parameter. Redirect sends victim to attacker site

Custom Code

Acc

ount

s

Fin

ance

Ad

min

istr

atio

n

Tra

nsa

ctio

ns

Com

mu

nic

atio

n

Kn

owle

dge

Mgm

t

E-C

omm

erce

Bus

. Fun

ctio

ns

4

Victim clicks link containing unvalidated parameter

Evil Site

http://www.irs.gov/taxrefund/claim.jsp?year=2006&

… &dest=www.evilsite.com

CSC 666: Secure Software Engineering

Danger of redirects Sending user to another site for phishing or infection. As a cross-site attack vector.

Danger of forwards (transfers in .NET) Bypassing authentication and access control.

Protecting redirects and forwards Avoid using redirects and forwards. Use redirects and forwards without user input. Validate URLs

- Indirect selection: page selects from safe list of specified URLs.

- Examine computed URL to verify it matches safe whitelist.

Protecting Redirects & ForwardsA10

CSC 666: Secure Software Engineering

Web Server Issues

Admin interfaces Default content Directory listings Proxy capabilities

CSC 666: Secure Software Engineering

Admin Interfaces

Admin services often run on different port.8008: IBM WebSphere

8080: Apache Tomcat

May be accessible via Host header.Host: example.com:8080

Even if firewall blocks that port.

May have default credentials.Tomcat: <tomcat,tomcat>, <admin,’’>

Sun JavaServer: <admin,admin>

CSC 666: Secure Software Engineering

Default Content

Default content includes Debug + test functions. Sample scripts. Manuals + images.

Example: phpinfo.php

CSC 666: Secure Software Engineering

Directory Listings

Web server may respond to dir request by Returning default resource in directory, such

as index.html. Returning an error, such as 403 Forbidden. Returning a listing of the directory.

Directory listings may lead to problems: Leftover files, such as backups, logs, etc. Attacker can identify resources that may not

be properly protected by access control.

CSC 666: Secure Software Engineering

Web Server as Proxy

Web servers sometimes configured as proxies to send requests to other servers.

If may be possible to use a server proxy to Attack third-party systems on the Internet. Access internal systems that are protected by

the firewall from direct external access. Access other services on internal host that

are protected by the firewall.

CSC 666: Secure Software Engineering

Testing for Proxies

Modify URL to access other hosts:telnet example.com 80

GET http://other.example.com:80/ HTTP/1.0

Use the CONNECT methodtelnet example.com 80

CONNECT other.example.com:80 HTTP/1.0

Can use to port scanTry combinations of IP address + port.

If receive banner, then port is open on IP.

CSC 666: Secure Software Engineering

Web Services

Web services are designed to provide: Interoperability: services can be built on any

framework in any language. Reuse: code can be re-used among different

applications.

Services should be Self-describing Discoverable Content-independent Stateless

WS Architecture Standards

CSC 666: Secure Software Engineering

eXtensible Markup Language

Extensible descriptive markup language framework Primarily used for data communication and storage. Tree-based document structure using <> tags. Began as simplified subset of SGML.

<?xml version="1.0" encoding="UTF-8"?><inventory>

<book isbn=“0976694042”><author>Chris

Pine</author><title>Learn to

Program</title></book>

</inventory>

CSC 666: Secure Software Engineering

XML Tree Structure<todo>

<title> Monday’s List</title><item> Study for midterm</item><item> <priority=10/> SSE Class</item><item> Bathe cat</item>

</html>

todo

titleTuesday’s List

itemStudy for midterm

itemScripting Class

priority10

itemBathe Cat

CSC 666: Secure Software Engineering

Elements and Attributes

An element consists of tags and contents<title>Learn to Program</title>

Begin and end tags are mandatory.

<isbn number=“0976694042” />

Tags must be consistently nested.

Attributesnumber=“0976694042”

Elements may have zero or more attributes.

Attribute values must always be quoted.

CSC 666: Secure Software Engineering

XML Entities

Entities are named data. Default: &lt; &gt; &amp; &apos; &quot; New entities can be defined in DTD. Entities definitions can be recursive.

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE example [

<!ENTITY copy "&#xA9;"> <!ENTITY copyright-notice "Copyright &copy; 2009, XYZ Enterprises">

]> <example> &copyright-notice; </example>

Numeric character references are not entities.

&#<dec>; or &#x<hex>; refers to Unicode code point. &#xA9 above is used to refer to the copyright symbol.

CSC 666: Secure Software Engineering

XML Syntax Rules

1. There is one and only one root tag.

2. Begin tags must be matched by end tags.

3. XML tags must be properly nested.

4. XML tags are case sensitive.

5. All attribute values must be quoted.

6. Whitespace within tags is part of text.

7. Newlines are always stored as LF.

8. HTML-style comments: <!-- comment -->

CSC 666: Secure Software Engineering

Correctness

Well-formed Conforms to XML syntax rules. A conforming parser will not parse

documents that are not well-formed.

Valid Conforms to XML semantics rules given in

- Document Type Definition (DTD)- XML Schema

A validating parser will not parse invalid documents.

CSC 666: Secure Software Engineering

Malicious XML

Insert additional <price> element. XML is well formed. Validity depends on DTD. Application will accept if it doesn’t validate.

<bookOrder> <title>XML Security</title> <price>59.99</price> <shippingAddress> <price>0.01</price> <street>Nunn Drive</street> <city>Highland Heights</city> <state>KY</state> </shippingAddress></bookOrder>

CSC 666: Secure Software Engineering

Validation

DTD<?xml version=“1.0” encoding=“UTF-8”?><!ELEMENT bookOrder (title, price, shippingAddress) ><!ELEMENT title (#PCDATA) ><!ELEMENT price (#PCDATA) ><!ELEMENT shippingAddress (#PCDATA) >

Schema<?xml version=“1.0”?><xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema ><xs:element name=“bookOrder”>

<xs:element name=“title” type=“xs:string” /><xs:element name=“price” type=“xs:string” /><xs:element name=“shippingAddress” type=“xs:string” />

</xs:element></xs:schema>

Ensure that elements are present and are leaf nodes.

CSC 666: Secure Software Engineering

Strict Validation

Schemas can also validate data using regexps.

<?xml version=“1.0”?>

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema >

<xs:element name=“bookOrder”>

<xs:element name=“title”>

<xs:restriction base=“xs:string”>

<xs:pattern value=“[A-Za-z0-9 ‘\-]*” />

</xs:restriction>

</xs:element>

<xs:element name=“price” type=“xs:decimal” />

<xs:element name=“shippingAddress”>

<xs:restriction base=“xs:string”>

<xs:pattern value=“[A-Za-z0-9 ,#\-\.\t\n]*” />

</xs:restriction>

</xs:element>

</xs:element>

</xs:schema>

CSC 666: Secure Software Engineering

Bypassing ValidationInclude DTD in malicious XML file.

<?xml version=“1.0” encoding=“UTF-8”?><!DOCTYPE bookOrder [<!ELEMENT bookOrder (title, price, shippingAddress) ><!ELEMENT title (#PCDATA) ><!ELEMENT price (#PCDATA) ><!ELEMENT shippingAddress ANY >]><bookOrder> <title>XML Security</title> <price>59.99</price> <shippingAddress> <price>0.01</price> <street>Nunn Drive</street> <city>Highland Heights</city> <state>KY</state> </shippingAddress></bookOrder>

Alternately: <!DOCTYPE bookOrder SYSTEM “DTD_URL">

CSC 666: Secure Software Engineering

External Entity ReferencesUse entity references to read files on server filesystem.

<?xml version=“1.0” encoding=“UTF-8”?> <!DOCTYPE bookOrder [ <!ELEMENT bookOrder ANY > <!ELEMENT title ANY > <!ENTITY eer SYSTEM “c:\boot.ini”>]><bookOrder> <title>&eer;</title></bookOrder>

CSC 666: Secure Software Engineering

XML Injection

Include <price> element in shipping address. User input for street is “Nunn

Drive</street><price>0.01</price> <street>Nunn Drive”

<bookOrder> <title>XML Security</title> <price>59.99</price> <shippingAddress> <street>Nunn Drive</street><price>0.01</price><street>Nunn Drive</street> <city>Highland Heights</city> <state>KY</state> </shippingAddress></bookOrder>

CSC 666: Secure Software Engineering

XPath

Language for selecting nodes from XML. Combines directory-type paths + regexps. XPath 2.0 basis for XQuery SQL-like language.

<bo> <title>XML Security</title> <price>59.99</price> <shippingAddress> <street>Nunn Drive</street> <city>Highland Heights</city> <state>KY</state> </shippingAddress></bo>

Examples

bo: children of bo node /bo: root bo element //bo: all bo elements bo//title: all titles //bo/[price=’39’]: all bo

nodes with a price of 39.

CSC 666: Secure Software Engineering

XPath Searching

XPathFactory xfac = XPathFactory.newInstance();XPath xp = xfac.newXPath();InputSource input = new InputSource(xmlFile);String query = “//users/user[@name=‘” + name + “’ and @pass=‘” + pass + “’”;return xp.evaluate(query, input);

<users><user id=“1234” name=“John” pass=“letmein”><user id=“2456” name=“Archi” pass=“password1”><user id=“3322” name=“Eddie” pass=“Eddie”><user id=“4321” name=“Lori” pass=“drowssap”></users>

CSC 666: Secure Software Engineering

XPath Injection

Set pass to ‘ or ‘a’ = ‘a //users/user[name=‘John’ and pass=‘’ or ‘a’ = ‘a’] Returns all users.

Set name to ‘ or id=1 or ‘’=‘ //users/user[name=‘John’ or id=1 or ‘’=‘’ and

pass=‘letmein’] Returns all users with id=1

XQuery Injection in the future Supports conditionals + loops. User-defined functions.

CSC 666: Secure Software Engineering

Mitigating XPath InjectionUse XPath bind variables

Similar to SQL prepared statement variables.

XPathFactory xfac = XPathFactory.newInstance();XPath xp = xfac.newXPath();InputSource input = new InputSource(xmlFile);XPathBindVariables bv = new XPathBindVariables();xp.setXPathVariableResolver(bv);bv.bindVar(“ID”, id);bv.bindVar(“NAME”, name);String query = “//users/user[@name=$NAME and

@pass=$PASS”]”;return xp.evaluate(query, input);

SOAP: Simple Object Access Protocol

Always uses POST requests. Ignores meaning of HTTP requests. Request meaning is stored in request body. Could be used over non-HTTP protocols.

Remote Procedure Call (RPC) protocol Similar to earlier binary RPC like CORBA or

ICE XML format: human readable but 2-4X larger Successor to XML-RPC.

CSC 666: Secure Software Engineering

SOAP RequestPOST /order HTTP/1.1 Host: example.comContent-Type: text/xml; charset="utf-8" Content-Length: nnnn

<soap:Envelope xmlns:soap ="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Body xmlns:m=“http://example.com/order"> <m:OrderBook> <m:isbn>978-0321424778</m:isbn>

<m:quantity>1</m:quantity> </m:OrderBook>

</soap:Body> </soap:Envelope>

CSC 666: Secure Software Engineering

SOAP ResponseHTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8" Content-Length: nnnn

<soap:Envelope xmlns:soap ="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Body xmlns:m=“http://example.com/order"> <m:OrderBookResponse> <m:isbn>978-0321424778</m:isbn>

<m:price>49.99</m:price> <m:quantity>1</m:quantity>

</m:OrderBookResponse> </soap:Body>

</soap:Envelope>

CSC 666: Secure Software Engineering

WSDL

Web Services Description Language

Service: contains set of messages.

Message: an individual operation.

Port: address (URL) of service.

Binding: port type, such as SOAP and SOAP binding type.

CSC 666: Secure Software Engineering

WSDL Enumeration

Obtain list of services and messages. WSDL file typically published by default.

Finding WSDL files Append ?WSDL or .WSDL to service URL. Lookup WSDL files on UDDI servers. Google hacking, filetype:wsdl inurl:wsdl

Mitigation Avoid publishing WSDL file. J2EE: remove wsdl.location from properties.

CSC 666: Secure Software Engineering

Key Points

Top 10 Web Security Risks XML parsing

Valid and well-formed Specifications: schema, DTD

XPath language for searching XML XPath Injection

SOAP and WSDL

CSC 666: Secure Software Engineering

OWASP Top 10 2013

Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

A1 – Injection

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

A2 – Broken Authentication and

Session Management

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A3 – Cross-Site Scripting (XSS)

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

A4 – Insecure Direct Object References

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

A5 – Security Misconfiguration

CSC 666: Secure Software Engineering

OWASP Top 10 2013

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

A6 – Sensitive Data Exposure

Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

A7 – Missing Function Level

Access Control

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

A8 - Cross-Site Request Forgery

(CSRF)

Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

A9 - Using Components with

Known Vulnerabilities

Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

A10 – Unvalidated Redirects and

Forwards

References1. Nischal Bhalla and Sahba Kazerooni, “Web Services Vulnerabilities,” Black Hat

Briefings EU, http://www.blackhat.com/presentations/bh-europe-07/Bhalla-Kazerooni/Whitepaper/bh-eu-07-bhalla-WP.pdf, 2007.

2. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.

3. Mario Heiderich et. Al., Web Application Obfuscation, Syngress, 2010.4. Billy Hoffman and Bryan Sullivan, AJAX Security, Addison-Wesley, 2008.

5. Paco Hope and Ben Walther, Web Security Testing Cookbook, O’Reilly, 2009.

6. iSEC Partners, Attacking Web Services, OWASP AppSec DC, https://www.isecpartners.com/documents/iSEC-Attacking-Web-Services.OWASP.pdf, 2005.

7. Ramarao Kanneganti and Prasad Chodavrapu, SOA Security, Manning, 2008.

8. OWASP, OWASP Top 10 Project, https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project, 2013.

9. Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s Handbook, 2nd Edition, Wiley, 2011.

10. Asoke Talukder and Manish Cahitanya, Architecting Secure Software Systems, CRC Press, 2009.

11. w3schools, SOAP Tutorial, http://www.w3schools.com/soap/default.asp.