1. Web Applications and Services
James Walden
Northern Kentucky University

2. CSC 666: Secure Software Engineering
Topics
OWASP Top 10 Security Risks
Web Server Security
Web Services Security
XML
Xpath
WSDL
SOAP
Animations and diagrams from the OWASP Top 10 Project are licensed with a Creative Commons CC BY-SA 3.0 license.
CSC 666: Secure Software Engineering

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
A9 are new and highlighted in red.
A6 through to A7 should have also been highlighted in light blue since there are merged and/or split from 2010

4. "SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’"
Injection
Account:
SKU:
Account:
SKU:
"SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’"
Account Summary
Acct:
Acct:
Acct:
Acct:
HTTP response  
DB Table  
HTTP request
SQL query
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Application Layer
Databases
Legacy Systems
Web Services
Directories
Human Resrcs
Billing
APPLICATION ATTACK
Custom Code
1. Application presents a form to the attacker.
2. Attacker sends an attack in the form data.
App Server
3. Application forwards attack to the database in a SQL query.
Web Server
Hardened OS
4. Database runs query containing attack and sends encrypted results back to application.
Network Layer
Firewall
Firewall
5. Application decrypts data as normal and sends results to the user.

5. Broken Authentication and Session Management
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.
CSC 666: Secure Software Engineering

6. Authentication/Session Protection
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.
CSC 666: Secure Software Engineering

7. Cross-Site Scripting (XSS)A3
Cross-Site Scripting (XSS) 1
Attacker sets the trap – update my profile
Attacker enters a malicious script into a web page that stores the data on the server
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions 2
Victim views page – sees attacker profile
Script runs inside victim’s browser with full access to the DOM and cookies 3
Script silently sends attacker Victim’s session cookie
CSC 666: Secure Software Engineering

8. XSS Output Filtering (Escaping)
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()
HTML Element Content
(e.g., <div> some text to display </div> )
#2: All non-alphanumeric < 256  &#xHH
ESAPI: encodeForHTMLAttribute()
HTML Attribute Values
(e.g., <input name='person' type='TEXT' value='defaultValue'> )
#3: All non-alphanumeric < 256  \xHH
ESAPI: encodeForJavaScript()
JavaScript Data
(e.g., <script> some javascript </script> )
#4: All non-alphanumeric < 256  \HH
ESAPI: encodeForCSS()
HTML Style Property Values
(e.g., .pdiv a:hover {color: red; text-decoration: underline} )
#5: All non-alphanumeric < 256  %HH
ESAPI: encodeForURL()
URI Attribute Values
(e.g., <a href="javascript:toggle('lesson')" )
CSC 666: Secure Software Engineering

9. Insecure Direct Object ReferencesA4
Insecure Direct Object References
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.
CSC 666: Secure Software Engineering

10. Insecure Direct Object ReferencesA4
Insecure Direct Object References
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:
String query="SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query , … );
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
CSC 666: Secure Software Engineering

11. Securing Object ReferencesA4
Securing Object References
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
Access
Reference
Map
Report123.xls
Acct:
CSC 666: Secure Software Engineering

12. Security Misconfiguration
Database
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Custom Code
App Configuration
Development
Framework
App Server
QA Servers
Web Server
Hardened OS
Insider
Test Servers
Source Control
CSC 666: Secure Software Engineering

13. Avoiding Security Misconfiguration
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

14. Sensitive Data Exposure
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?
CSC 666: Secure Software Engineering

15. Missing Function Level Access Control
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.
CSC 666: Secure Software Engineering

16. Missing Function Level Access Control
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.
CSC 666: Secure Software Engineering

17. Cross-Site Request ForgeryA8
Cross-Site Request Forgery
Attacker sets the trap on some website on the internet (or simply via an ) 1
Application with CSRF vulnerability
Hidden <img> tag contains attack against vulnerable site
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
While logged into vulnerable site, victim views attacker site 2 3
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

18. Using Components with Known Vulnerabilities
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)
Struts
.NET Framework
CSC 666: Secure Software Engineering

19. Unvalidated Redirects & Forwards1
Attacker sends attack to victim via or webpage
From: Internal Revenue Service Subject: Your Unclaimed Tax Refund Our records show you have an unclaimed federal tax refund. Please click here to initiate your claim. 3
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions 2
Victim clicks link containing unvalidated parameter
Request sent to vulnerable site, including attacker’s destination site as parameter. Redirect sends victim to attacker site
Evil Site 4
… &dest=
CSC 666: Secure Software Engineering

20. Protecting Redirects & Forwards
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.
CSC 666: Secure Software Engineering

21. CSC 666: Secure Software Engineering
Web Server Issues
Admin interfaces
Default content
Directory listings
Proxy capabilities
CSC 666: Secure Software Engineering

22. 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

23. 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

24. 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

25. 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

26. CSC 666: Secure Software Engineering
Testing for Proxies
Modify URL to access other hosts:
telnet example.com 80
GET HTTP/1.0
Use the CONNECT method
CONNECT other.example.com:80 HTTP/1.0
Can use to port scan
Try combinations of IP address + port.
If receive banner, then port is open on IP.
CSC 666: Secure Software Engineering

27. 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
CSC 666: Secure Software Engineering

28. WS Architecture Standards

29. 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=“ ”>
<author>Chris Pine</author>
<title>Learn to Program</title>
</book>
</inventory>
CSC 666: Secure Software Engineering

30. CSC 666: Secure Software Engineering
XML Tree Structure
<todo>
<title>
Monday’s List
</title>
<item>
Study for midterm
</item>
<priority=10/>
SSE Class
Bathe cat
</html>
todo
Tuesday’s List
title
Study for midterm
item
Scripting Class
priority 10
Bathe Cat
CSC 666: Secure Software Engineering

31. Elements and Attributes
An element consists of tags and contents
<title>Learn to Program</title>
Begin and end tags are mandatory.
<isbn number=“ ” />
Tags must be consistently nested.
Attributes
number=“ ”
Elements may have zero or more attributes.
Attribute values must always be quoted.
CSC 666: Secure Software Engineering

32. CSC 666: Secure Software Engineering
XML Entities
Entities are named data.
Default: < > & &apos; "
New entities can be defined in DTD.
Entities definitions can be recursive.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE example [
<!ENTITY copy "©">
<!ENTITY copyright-notice "Copyright © 2009, XYZ Enterprises">
]>
<example> &copyright-notice; </example>
Example from
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

33. CSC 666: Secure Software Engineering
XML Syntax Rules
There is one and only one root tag.
Begin tags must be matched by end tags.
XML tags must be properly nested.
XML tags are case sensitive.
All attribute values must be quoted.
Whitespace within tags is part of text.
Newlines are always stored as LF.
HTML-style comments: <!-- comment -->
CSC 666: Secure Software Engineering

34. 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

35. 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

36. CSC 666: Secure Software Engineering
Validation
Ensure that elements are present and are leaf nodes.
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= >
<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>
CSC 666: Secure Software Engineering

37. CSC 666: Secure Software Engineering
Strict Validation
Schemas can also validate data using regexps.
<?xml version=“1.0”?>
<xs:schema xmlns:xs= >
<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:pattern value=“[A-Za-z0-9 ,#\-\.\t\n]*” />
</xs:schema>
CSC 666: Secure Software Engineering

38. CSC 666: Secure Software Engineering
Bypassing Validation
Include 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

39. External Entity References
Use 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

40. 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

41. 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.
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.
<bo>
<title>XML Security</title>
<price>59.99</price>
<shippingAddress>
<street>Nunn Drive</street>
<city>Highland Heights</city>
<state>KY</state>
</shippingAddress>
</bo>
CSC 666: Secure Software Engineering

42. CSC 666: Secure Software Engineering
XPath Searching
<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>
XPathFactory xfac = XPathFactory.newInstance();
XPath xp = xfac.newXPath();
InputSource input = new InputSource(xmlFile);
String query = + name +
“’ + pass + “’”;
return xp.evaluate(query, input);
Example from Secure Programming with Static Analysis
CSC 666: Secure Software Engineering

43. 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

44. Mitigating XPath Injection
Use 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 =
return xp.evaluate(query, input);
Example from Secure Programming with Static Analysis
CSC 666: Secure Software Engineering

45. 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.

46. CSC 666: Secure Software Engineering
SOAP Request
POST /order HTTP/1.1
Host: example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<soap:Envelope xmlns:soap ="
soap:encodingStyle=" encoding/">
<soap:Body xmlns:m=“
<m:OrderBook>
<m:isbn> </m:isbn>
<m:quantity>1</m:quantity>
</m:OrderBook>
</soap:Body>
</soap:Envelope>
CSC 666: Secure Software Engineering

47. CSC 666: Secure Software Engineering
SOAP Response
HTTP/ OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<soap:Envelope xmlns:soap ="
soap:encodingStyle=" encoding/">
<soap:Body xmlns:m=“
<m:OrderBookResponse>
<m:isbn> </m:isbn>
<m:price>49.99</m:price>
<m:quantity>1</m:quantity>
</m:OrderBookResponse>
</soap:Body>
</soap:Envelope>
CSC 666: Secure Software Engineering

48. 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.
Image from
CSC 666: Secure Software Engineering

49. 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

50. 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

51. OWASP Top 10 2013 CSC 666: Secure Software Engineering A1 – Injection
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

52. OWASP Top 10 2013 CSC 666: Secure Software Engineering
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
OWASP Top
CSC 666: Secure Software Engineering

53. References
Nischal Bhalla and Sahba Kazerooni, “Web Services Vulnerabilities,” Black Hat Briefings EU, Kazerooni/Whitepaper/bh-eu-07-bhalla-WP.pdf, 2007.
Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison- Wesley, 2007.
Mario Heiderich et. Al., Web Application Obfuscation, Syngress, 2010.
Billy Hoffman and Bryan Sullivan, AJAX Security, Addison-Wesley, 2008.
Paco Hope and Ben Walther, Web Security Testing Cookbook, O’Reilly, 2009.
iSEC Partners, Attacking Web Services, OWASP AppSec DC, Services.OWASP.pdf, 2005.
Ramarao Kanneganti and Prasad Chodavrapu, SOA Security, Manning, 2008.
OWASP, OWASP Top 10 Project,
Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s Handbook, 2nd Edition, Wiley, 2011.
Asoke Talukder and Manish Cahitanya, Architecting Secure Software Systems, CRC Press, 2009.
w3schools, SOAP Tutorial,