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
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: < > & ' " 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> ©right-notice; </example>
Numeric character references are not entities.
&#<dec>; or &#x<hex>; refers to Unicode code point. © 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.
Top Related