Advanced Web Services

Security & Hacking

Justin Derry,
OWASP Brisbane Chapter Leader
Practice Leader, b-sec Consulting
jderry@[Link]
OWAS +61 411 411 881
P
AppSe Copyright © 2006 - The OWASP Foundation

c
Permission is granted to copy, distribute and/or modify this document
under the terms of the Creative Commons Attribution-ShareAlike 2.5
License. To view this license, visit
Seattl [Link]

e The OWASP
Oct 2006 [Link]
Foundation
Presentation Agenda
 Web Services & Technology
 What is a Web Service
 Where are they commonly used & why
 Are you Exposing yourself (Willingly/Unwillingly?)
 What’s happening right now.

 An Attackers Toolkit
 Known common attacks against XML
 XML Interceptor Toolkit
 Case Studies (XML Web Service & WS-Security Web
Service)

 Web Services Security

 WS-Security
 Web Services Appliances (What they can/can’t do)
 Common Mistakes and pitfalls OWASP AppSec Seattle 2006 2
What is a Web Service?

Many things could be called a Web

Service.
For this presentation we are talking
about…

“A Web Service is a system designed to

support interoperable communication from
machine to machine over a network. It
includes an interface described in a
machine-processable format (WSDL), and
is typically conveyed using HTTP with XML
serialization.” OWASP AppSec Seattle 2006 3
[Link]/TR/ws-gloss
XML Web Service Communication

Typical Web Service Communication

Packet

OWASP AppSec Seattle 2006 4

Common Application Uses

Public Web Applications

AJAX ([Link], [Link])
Application API’s
Google, Yahoo, Ebay, Flickr, Amazon, IMDB,
etc.
Internet Payment Hubs
(Most major banks use XML Web Services for
Credit Card Processing, or similar XML
Technology)
Business B2B Communication Gateways
Extends the business outside their internal
network
Communicate easily withOWASP
thirdAppSec Seattle 2006
parties (trusted 5
Are you exposing yourself?

Vendor Applications
In-house applications that share
data with partners
Developers writing a tool to solve a
problem without business awareness
New Technologies (AJAX, Web 2.0, Google)
Maybe not called a Web Service but has
similar characteristics to an XML Web
Service

OWASP AppSec Seattle 2006 6

Known Common Web Service Attacks

 Parsing Exploits
 SAX/DOM Known Common Exploits on Vendor
Frameworks
 Custom parsers that are poorly written
 XML Injection (Passed into XML Stream)
 XPath Injection Attacks
 XML Manipulation (i.e. CDATA Manipulation etc.)
 WSDL Discovery and Manipulation with schemas
 DoS attacks against Web Services
 Typical HTTP/S Style Header Injection attacks
 Common Application Attacks (SQL Injection etc.)

OWASP AppSec Seattle 2006 7

Vulnerability Breakdown (Real-world)

source: b-sec Application Reviews 2005-2006

OWASP AppSec Seattle 2006 8

Increasing Attacks & Web Services

Increasing use of Web Service technology

Vendors are using to rapidly deploy
applications and services
Research into exploits is increasing
It’s a “Cool & New” technology we should
use it
“Today over 70% of attacks against a
company's
Web site or Web application come at the
'Application Layer' not the Network or
System layer”
(Gartner Group)
OWASP AppSec Seattle 2006 9
XML Interceptor Toolkit (1.0)

 Windows Forms .NET

Toolkit ([Link] 2.0)
 Developed in Australia
 Currently in initial
release for OWASP
Seattle 06
 Work in Progress – Do
you want to get
involved?

OWASP AppSec Seattle 2006 10

Web Interceptor Features

Currently in initial release for OWASP

Seattle 06
Supports XML TCP Capture as Proxy (initial)
Allows replay/manipulation of XML POST
requests
Easy interface to inject and force header
changes
Support for some automated attacks
Saving and recording of attack history
Perform most XML related attacks through the
tool
Includes basic security functions
OWASP AppSec Seattle 2006 11
(Base64/MD5/SHA)
Web Interceptor – Demo & Download

Demo initial features available in Release

1.0 of Interceptor Toolkit (XML Interception
& Replay)

Download available at
[Link]/owasp

OWASP AppSec Seattle 2006 12

Case Study (XML Web Service)

 Windows Forms .NET Client (Demo shows

interface)
 Remotely deployed to Call Center/Support
 Connected over Public Internet to Application
 Basic XML Web Services used (.NET Remote Framework
Web User
(Normal Client Access)
without WS-*
Web Server
or additional controls)

TML)
Traffic (H
eb
/S W
HTTP

XML
SOAP
Mess
a
Serv ges via W
Firewall ices eb

Corporate
Firewall
Support/Admin User
(Windows Forms Interface)
Database Server
OWASP AppSec Seattle 2006 13
Exploiting a Web Service through XML

Performing SQL Injection attacks using an

XML message and the Interceptor Toolkit.
How to use CDATA in XML Fields to pass
Cross Site Scripting..

How we did it (Web Interceptor Example)

OWASP AppSec Seattle 2006 14

Case Study Risks Identified

Assumed No Interface – No Attacks

No Data Validation (most OWASP Top Ten
Missing)
Serious SQL Injection & XSS Flaws
Passed through XML to Web Interface
XML Not encrypted (Replay/Data
Interception)
Returned Error Messages in XML

OWASP AppSec Seattle 2006 15

Case Study (WS-Security Enabled
Service)
 Financial Institution (i.e. Bank)
 Transactional Gateway Solution for their clients
 Credit Card Processing/Account Processing
 Significant risks with exposing transactional data
 Implemented a WS-Security Gateway Client Administrative
Access (Web SSL)

Web Server

TML)
ic (H
eb Traff
/S W
HTTP
Remote Web User
Web Server

XML
(WS-Security)
Firewall
XML Gateway
Appliance
Remote Application
(Transactional Requests)
Database Server
OWASP AppSec Seattle 2006 16
Case Study 2 (Where did it all go
wrong!)
Assumed WS-Security Protects 100%
Messages not sent over SSL
(Sniffing/Replay)
XML Gateway Appliance misconfigured
Sensitive data was passed in clear text
API Toolkit was basic and had no security
Assumed XML Gateway was doing it’s job
Assumed end user’s knew what they were
doing

OWASP AppSec Seattle 2006 17

What is WS-Security?

 Provides a core standard framework and schema

for XML messaging security
 Implements the following capabilities for XML
 Authentication
 Confidentiality
 Integrity

OWASP AppSec Seattle 2006 18

WS-Security Messages
Soap Envelope
Contains the schema
details and
instructions for the
message

WS-Security Details
Contains any WSSE Tokens,
Digital Signatures etc. Also
includes the WSU Created
Token (Timestamps)

Soap Body (The contents of

the XML Message)

OWASP AppSec Seattle 2006 19

Implementing WS-Security Securely

Ensure you are using Standard 1.1 (latest)

Implement an Authentication Token (either
UsernameToken, BinaryToken, etc.)
Provide a Digital Hash of the Message
(integrity)
Use Message encryption if passing
sensitive data
Implement SSL technology to ensure
messages cannot be captured and
replayed
Use a WS-* Gateway to OWASP
inspect and
AppSec verify
Seattle 2006 20

messages received prior to receiving them

Web Service Appliance/Gateways

 Market Space is Growing in size (Rapidly)

 Vendor solutions provides assistance to the
problem and are not a complete solution
 Use all the features not just the simple things
 WS-Security Authentication Validation
 Schema Validation
 Search for known common exploits in strings (i.e. SQL
Injection, XSS Attacks, etc.)
 Specify trusted hosts (IP Addresses or Agent Types) &
Restrict

OWASP AppSec Seattle 2006 21

Other Standards XML (WS-*)

 Oasis-Open Working groups releasing other

standards for XML Web Services
Future Standards Core Web Services Framework
(Under consideration ) (Widely adopted in Industry )

Extended Standards XML Messaging Stack

(Currently being adopted ) (Widely deployed in Industry )

WS-SECURE WS-RELIABLE
CONVERSTATION MESSAGING
WS-TRUST

WS-POLICY WS-SECURITY WS-ADDRESSING WS-ROUTING

WSDL 1.1 SOAP 1.1 HTTP (SSL) XML MESSAGE

DESCRIPTION DELIVERY

Description Services Delivery Services – Standards for XML

Security & Enforcement Message Communication

OWASP AppSec Seattle 2006 22

Common Mistakes

Assumption that WS-Security solves

everything
Assumption (No Interface means no
attacks – service is hidden)
Belief in vendors without performing
testing
Supply insecure API to remote users
Forget to disable WSDL publishing of
service
Web Service has minimal or no application
security controls (i.e. OWASP TopSeattle
OWASP AppSec Ten) 2006 23
OWASP Top Ten & Web Services

 (1) Data Validation = Validate Everything

 (2) Access Control = Implement Authentication (WS-
Security)
 (3) Authentication/Session Management = Replay attacks in
XML
 (4) Cross Site Scripting = (See – 1, Integration with
applications)
 (5) Buffer Overflow = Watch for this, validate and address
in code
 (6) Injection Flaws = Watch for this, validate and address in
code
 (7) Error Handling = Don’t return detailed error messages
 (8) Insecure Storage = Watch for this, store appropriately
 (9) Denial of Service = Detect & Alert, similar to web
application
 (10) Insecure Configuration Management = Similar to web
application (Avoid WSDL Publishing etc AppSec
OWASP unlessSeattle
necessary)
2006 24
Summary
 Implement WS-Security (C,I,A)
 Implement OWASP Guidelines for Applications
 Identify & Test Vendor Applications
 Don’t rely 100% on XML security gateways to
provide all the security
 Disable WSDL Publishing if you don’t need it

OWASP AppSec Seattle 2006 25

Questions?

Justin Derry
Application Security Practice Leader
B-sec Consulting Pty Ltd (Australia)
+61 411 411 881
Email: jderry@[Link]

OWASP AppSec Seattle 2006 26