Advanced Web Services Security & Hacking
Download
Report
Transcript Advanced Web Services Security & Hacking
Advanced Web Services
Security & Hacking
OWASP
AppSec
Seattle
Oct 2006
Justin Derry,
OWASP Brisbane Chapter Leader
Practice Leader, b-sec Consulting
[email protected]
+61 411 411 881
Copyright © 2006 - The OWASP Foundation
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 http://creativecommons.org/licenses/by-sa/2.5/
The OWASP Foundation
http://www.owasp.org/
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.”
www.w3.org/TR/ws-gloss
OWASP AppSec Seattle 2006
3
XML Web Service Communication
Typical Web Service Communication Packet
OWASP AppSec Seattle 2006
4
Common Application Uses
Public Web Applications
AJAX (maps.google.com, mp3act.net)
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 with third parties (trusted or untrusted)
OWASP AppSec Seattle 2006
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 (vb.net 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 (Base64/MD5/SHA)
Support for SSL to be available shortly (Oct/Nov)
Support for HTTP/S Injection and Proxy tool as well
(Oct/Nov)
OWASP AppSec Seattle 2006
11
Web Interceptor – Demo & Download
Demo initial features available in Release 1.0 of
Interceptor Toolkit (XML Interception & Replay)
Download available at
www.intratools.net/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 Framework without
Remote Web User
WS-* or additional controls)
(Normal Client Access)
Web Server
L)
(HTM
raffic
T
b
e
/S W
HTTP
Firewall
XML
SOAP
Mess
a
Serv ges via W
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
raffic
eb T
/S W
HTTP
L)
(HTM
Web Server
XML Gateway
Appliance
Firewall
Remote Web User
XML
(WS-Security)
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 inspect and verify
messages received prior to receiving them on
the Web Service Endpoint
OWASP AppSec Seattle 2006
20
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
(Under consideration)
Core Web Services Framework
(Widely adopted in Industry)
Extended Standards
(Currently being adopted)
WS-POLICY
XML Messaging Stack
(Widely deployed in Industry)
WS-SECURE
CONVERSTATION
WS-RELIABLE
MESSAGING
WS-TRUST
WS-SECURITY
WS-ADDRESSING
WS-ROUTING
WSDL 1.1
SOAP 1.1 HTTP (SSL) XML MESSAGE
DESCRIPTION
DELIVERY
Description Services
Security & Enforcement
Delivery Services – Standards for XML
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 Top Ten)
OWASP AppSec Seattle 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 unless necessary)
OWASP AppSec Seattle 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: [email protected]
OWASP AppSec Seattle 2006
26