Download Chapter 10

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Semantic Web wikipedia , lookup

Cross-site scripting wikipedia , lookup

Transcript
Chapter 10
XML and Web Services
Topics

Why a standards-compliant XML parser

Why a standard (off the shelf) XML parser

Validation.

External references

Document queries

Input validation for Web services

WSDL potential problems/a bad example with blacklisting

New opportunities for old errors

JavaScript hijacking..
Introduction

XML

web services

Service oriented architecture
The promise:

Software reuse

Less software security headaches
Why a standards-compliant XML parser


XML is very hard to parse

Recursive

XML entities (&xxxx;)
Better to use a standard, off the shelf XML
parser; there are many...
Validation



Validating XML documents can be done against
an XML schema or Document Type Definition
(DTD)
Slight preference for XML Schema because
“Simple Object Access Protocol” (Soap) uses
XML schema and SOAP used for man Web
Services standards.
Can be tricked, so be careful (page 354 has a
good example of “XML injection”)
External References

Document queries may be malicious, so be careful
about following them!
Example Document Type Declaration:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/strict.dtd”>

One example redefined the XML parser (ref. P 359)

Another example exported the boot sector.
Recommendation: use XML Schema (easier, more
powerful)
Document Queries
Looking around in XML documents is difficult.
Solution: XPATH
Problem: XPATH queries can be subject to XPATH
injection if not validated correctly.
(See example and cure on pp 363-365
Web Services
●
●
●
Web services are the main reason firewalls are
not too useful
Proponents often equate security features with
secure features.
Many chances for problems.
Input validation for Web Services
WS frameworks make it easy to “push a button”
and get a web service.
Case in point: Class xxx.java is copied into
webapp directory as
<webapp>/axis/xxx.jws
Now xxx is available via SOAP, with all its
vulnerabilities!!!
WSDL potential problems/a bad
example with blacklisting
●
●
●
WSDL stands for Web Services Description
Language: does for Web Services what HTML does for
web pages: makes them “discoverable.
Example: Direct Web Remoting (DWR) (see
http://directwebremoting.org/dwr/index.html) has a
facility that allows listing “excluded” methods:
●
<exclude ...>
●
<include ...>
DWR is another easy way to include java code in a
web services page.
New opportunities for old errors
●
Automatic Stack traces ???
●
Session management traps
●
Ambiguous security requirements:
●
Versatility vs security (XSS for example)
JavaScript Hijacking
●
●
AJAX is a well used platform for developing
Web applications; it is very easy to use.
Biggest problem is that browser requests are
for small datapieces, leaving the door open for
attackers to steal data (technology exists to mix
data sources, similar to mash-ups). Confidential
data can be retrieved by a malicious website.
Very possible with XSS. Advice:
●
●
Decline malicious requests
Prevent direct execution of JavaScript
responses.
Declining Malicious Requests
A Javascript hijacking attempt looks like an XSS.
Suggest:
Include a random cookie (can be a session or a dialog
cookie)
Check the HTTP referer header.
Do not respond to GET requests. (Always used by
<script> tag) (efficiency hit)
Preventing direct response
execution
Program in such a way that responses include code that
has to be removed in order to make it executable: for
example, prefix it with:
While(1);
or convert the code into comments (enclose in /* */)