Web Applications and Services
James Walden
Northern Kentucky University
Topics
1. OWASP Top 10 Security Risks
2. Web Server Security
3. Web Services Security
1.
2.
3.
4.
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
OWASP Top Ten 2013
A1: Injection
A2: Broken
Authentication
and Session
Management
A3:Cross-Site
Scripting (XSS)
A8:Cross Site
Request
Forgery (CSRF)
A7: Missing
Function Level
Access Control
A6: Sensitive
Data Exposure
A9: Using
Known
Vulnerable
Components
A10:
Unvalidated
Redirects and
Forwards
A4: Insecure
Direct Object
References
A5: Security
Misconfiguration
3


DB Table


Billing
Directories
Human Resrcs
ATTACK

Web Services
HTTP
SQL
response
query

HTTP
request
APPLICATION
Legacy Systems
Databases
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Administration
Transactions
Injection
Accounts
Finance
Application Layer
A1
"SELECT * FROM
Account Summary
Account:
accounts WHERE
SKU:
acct=‘’
OR 1=1-Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
’"
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
1. Application presents a form
to the attacker.
Custom Code
2. Attacker sends an attack in
the form data.
App Server
3. Application forwards attack
to the database in a SQL
query.
Firewall
Hardened OS
Firewall
Network Layer
Web Server
4. Database runs query
containing attack and sends
encrypted results back to
application.
5. Application decrypts data
as normal and sends results
4
to the user.
A2
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
A2
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
A3
Cross-Site Scripting (XSS)
Attacker sets the trap – update my profile
Victim views page – sees attacker profile
Administration
Transactions
2
Accounts
Finance
Attacker enters a
malicious script into a
web page that stores the
data on the server
Custom Code
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
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
1
A3
XSS Output Filtering (Escaping)
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()
HTML Element Content
#2: All non-alphanumeric < 256  &#xHH
ESAPI: encodeForHTMLAttribute()
(e.g., <div> some text to display </div> )
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> )
HTML Style Property Values
#4: All non-alphanumeric < 256  \HH
ESAPI: encodeForCSS()
(e.g., .pdiv a:hover {color: red; text-decoration:
underline} )
URI Attribute Values
#5: All non-alphanumeric < 256  %HH
ESAPI: encodeForURL()
(e.g., <a href="javascript:toggle('lesson')" )
CSC 666: Secure Software Engineering
A4
Insecure Direct Object References
https://www.onlinebank.com/user?acct=6065
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
A4
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: http://example.com/app/accountInfo?acct=N
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
A4
Securing Object References
Select an approach for protecting each user
accessible object (object number, filename, etc.):
 Replace direct with indirect object references.
http://app?file=Report123.xls
http://app?file=1
http://app?id=9182374
http://app?id=7d3J93
Access
Reference
Map
Report123.xls
Acct:9182374
 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
CSC 666: Secure Software Engineering
A5
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Administration
Transactions
Accounts
Finance
Security Misconfiguration
Database
Custom Code
App Configuration
Framework
Development
App Server
QA Servers
Web Server
Insider
Hardened OS
Test Servers
Source Control
CSC 666: Secure Software Engineering
A5
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
A6
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
A7
Missing Function Level Access
Control
Attacker notices the URL
indicates his role:
https://www.onlinebank.com/user/getAccounts
/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
A7
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
A8
Cross-Site Request Forgery
While logged into vulnerable site,
victim views attacker site
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
2
Administration
Transactions
Hidden <img> tag
contains attack against
vulnerable site
Application with CSRF
vulnerability
Accounts
Finance
1
Attacker sets the trap on some website on the internet
(or simply via an e-mail)
Custom Code
3
<img> tag loaded by
browser – sends GET
request (including
credentials) to vulnerable
site
Vulnerable site sees
legitimate request from
victim and performs the
action requested
A9
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.
Struts
 Inventory components and
check for vulnerabilities.
 OWASP Dependency Check
 SafeNuGet (for .NET libraries)
.NET Framework
CSC 666: Secure Software Engineering
Unvalidated Redirects & Forwards
Attacker sends attack to victim via email 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.
E-Commerce
Custom Code
Request sent to vulnerable
site, including attacker’s
destination site as parameter.
Redirect sends victim to
attacker site
http://www.irs.gov/taxrefund/claim.jsp?year=2006
& … &dest=www.evilsite.com
Evil Site
4
CSC 666: Secure Software Engineering
Bus. Functions
Communication
Knowledge Mgmt
Victim clicks link containing unvalidated
parameter
Transactions
Accounts
2
3
Administration
1
Finance
A10
A10
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
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 method
telnet example.com 80
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
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
WS Architecture Standards
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
title
Tuesday’s List
item
Study for midterm
CSC 666: Secure Software Engineering
item
Scripting Class
priority
10
item
Bathe Cat
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.
Attributes
number=“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.
2.
3.
4.
5.
6.
7.
8.
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
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
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=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>
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 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
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
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.
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
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 = “//users/user[@name=‘” + name +
“’ and @pass=‘” + pass + “’”;
return xp.evaluate(query, input);
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 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 = “//users/user[@name=$NAME and
@pass=$PASS”]”;
return xp.evaluate(query, input);
CSC 666: Secure Software Engineering
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.
SOAP Request
POST /order HTTP/1.1
Host: example.com
Content-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 Response
HTTP/1.1 200 OK
Content-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
A1 – Injection
A2 – Broken
Authentication and
Session
Management
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.
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.
A3 – Cross-Site
Scripting (XSS)
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.
A4 – Insecure
Direct Object
References
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.
A5 – Security
Misconfiguration
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.
CSC 666: Secure Software Engineering
OWASP Top 10 2013
A6 – Sensitive Data
Exposure
A7 – Missing
Function Level
Access Control
A8 - Cross-Site
Request Forgery
(CSRF)
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.
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.
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.
A9 - Using
Components with
Known
Vulnerabilities
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.
A10 – Unvalidated
Redirects and
Forwards
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.
CSC 666: Secure Software Engineering
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Nischal Bhalla and Sahba Kazerooni, “Web Services Vulnerabilities,” Black Hat
Briefings EU, http://www.blackhat.com/presentations/bh-europe-07/BhallaKazerooni/Whitepaper/bh-eu-07-bhalla-WP.pdf, 2007.
Brian Chess and Jacob West, Secure Programming with Static Analysis, AddisonWesley, 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,
https://www.isecpartners.com/documents/iSEC-Attacking-WebServices.OWASP.pdf, 2005.
Ramarao Kanneganti and Prasad Chodavrapu, SOA Security, Manning, 2008.
OWASP, OWASP Top 10 Project,
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project, 2013.
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, http://www.w3schools.com/soap/default.asp.