Protecting Web Services and Web Applications Against Security Threats

Protecting Web services and Web
applications against security threats
Rix Groenboom
Support Manager
Parasoft UK Ltd
OWAS rix.groenboom@parasoft.com
P
AppSe
c
Copyright © 2006 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation
Europ License.
e The OWASP
May 2006 http://www.owasp.org/
Foundation
What We Will Explore
 What threats we see today

 Practices for securing Web Services and
SOA
 Use of a Policy based Approach:
 “Inside Out & Outside In”
OWASP AppSec Europe 2006 2

First, Lets Redefine “SOAP”
SOAP = Service Oriented Architecture Protocol

Experience
Who is responsible for SOA security?
When is SOA security addressed?
What activities are involved in SOA

security?

Structure of this presentation
Problems, Threats, and Solutions
“Testing Security Into The Application”
A Four-Step Approach To Securing SOAP
Examples of Threats Prevented

Problems: XML Bomb
bomb.xml

Problems: XML Bomb
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE SOAP-ENV:Envelope [
<!ELEMENT SOAP-ENV:Envelope ANY>
<!ATTLIST SOAP-ENV:Envelope entityReference CDATA #IMPLIED>
<!ENTITY x0 "Bomb!">
<!ENTITY x1 "&x0;&x0;">
<!ENTITY x2 "&x1;&x1;">
...
<!ENTITY x20 "&x19;&x19;">
<!ENTITY x21 "&x20;&x20;">
<!ENTITY x22 "&x21;&x21;">
]>

What is wrong with this picture ?
 Enterprise
network
protected by
firewall
 Application is the
only way in
 Must keep
application open
for business
 User (potential
hackers) must
have access to
the application
Software as a Service: Security
Challenges
Application
Legacy Thin Web
Logic
Client Site
Database Application Presentation

Server Server Layer
Web
Services
= Serious Security risks

Challenges
 Web services vulnerabilities can be present in
the:
 Operating system or the applications that ship with it
 Network
 Database
 Web server
 Application server
 XML parser or Web services implementation / stack
 Application code
 XML appliance
 And, yes, that post-it note with the password

under your drawer or keyboard…
Challenges
 Problems with Web services and SOA
 Cut through firewall
 SOAP messages often travel over HTTP port 80
 Business processes on the web
 Expose internal APIs to anonymous users
 New technology, new mistakes
 Once web apps are locked tighter, guess who’s next?
 Implied assumptions, external dependence
 “I can’t see it, neither can a hacker”
 “We can trust that service to work properly”
 “The use of the service is constrained by the client
application”
 The Y2K problem revisited !

Securing Web Services – Solutions So
far
 General Practices
 Define acceptable protocols
 Shut down other services
 Lock down firewall (change port)
 Enforce security mechanisms
 Authentication
 Access Control
 Auditing
 … to Z

Securing Web Services – Solutions So
far
 SOA Security Mechanisms
 WS-Security
 XML Encryption
 XML Signature
 X509
 Username Tokens
 SAML
 WS-Trust
 WS-SecureConversation
 WS-SecurityPolicy
 WS-Federation
 WS-Privacy
 WS-*

General Web Services Threats
Common to all Web applications

SQL Injections
 Special characters in queries
Capture and Replay Attacks
 Man in the middle attacks
DoS (resulting from a large load)
 Blow up application from inside
Improper Error Handling
 Dump of stack trace etc
Broken Access Control
 Take over earlier sessions tokens etc

Specific to XML Web services

Large Payloads
 Send huge XML load, or generate huge responses
XPath Injections
 Query XML documents for certain nodes
External Entity Attacks
 Misuse pointed to XML data using URI
XML Bombs
 Recursive XML entity declaration

However, threats also come from within:

Since 1999, the percentage of companies
reporting a computer-security incident from
inside is almost the same as those reporting it
from the outside
28.9% of of security incidents come from
employees
Source:
The Wall Street Journal Online (Feb 13, 2006)
http://online.wsj.com/article/SB1139260535524
66409.html
Challenge - Properly Addressing
Security
Testing security “into” the Web service
application:
 Common “end-of-cycle” security testing can detect some
standard application security vulnerabilities, however…
 Approaching security merely as a “bug finding” exercise is
inefficient and costly
 It is impossible to cover all possible execution paths with testing!
Architect Develop Test Monitor
Assumptions Need to be able to

GAP Audits
detect vulnerabilities as
early as possible.

Why More Testing Does Not Help ?
String username = request.getParameter("USER");

String password = request.getParameter("PASSWORD");
String query = “SELECT user_id FROM Users WHERE username=‘” +

username + “’ AND password=‘” + password + “’”;
Statement.execute(query);
An attacker passes ' or 1=1 # for usersname
SELECT user_id FROM Users

WHERE username='' or 1=1 #' AND password=‘foo’
Securing Web Services
A different approach is needed

A preventive, policy-based approach rather
than a reactive one
Security, like quality, must be built into the
application and cannot be tested in
Application are large and complex
We propose a combined approach:
Outside In
Inside Out

Securing Web Services: Step 1
Assessment: Impact & Risk

Analyze the business process
 Assets, users, entry points
 What needs to be protected? How?
 Outsource for expertise before implementation
Define security threats
 CIA: Confidentiality, Availability, Integrity
 Risk = Threat x Vulnerability x Expected Loss
– Threat = Motivated Attacker with Path to Valuable
Asset
– Vulnerability = Weakness in system
– Expected Loss = Impact of threat realization
 Misusage, the general WS threats, etc.
Assessment: Penetration Testing

Find a few general vulnerabilities
Many penetration activities can be automated
 Generate injection attacks, XSS, scan for broken
access control, etc.
 Simulate large loads, generate big messages, etc.
Penetration testing is not exhaustive
But, a vulnerability you find
 Is like a real bug: if you see one, there are 1000 you
do not see !
 “where smoke is, is fire”
 Helps you in Step 2

Develop a Security Policy:

A security policy is a set of guidelines that are
an overall strategy for application security
Secure implementation guidelines:

Use trusted libraries
Adhere to coding and XML standards
 Release IO resources in the code
 Turn off DTD support in XML parsers
 Constrain schema types
Review implementation for errors
Turn off features by default

 However, security policy also covers applications

code
 Key areas that need are required:
 Access control and Authentication
 Denial of Service
 Command Injection
 Concurrency
 Cryptography
 Error Handling
 Input Validation
 Logging
 Malicious Code
 Memory and Session Management
 Enforce Security Policy Throughout SDLC

 A policy without an automated enforcement
mechanisms is like law without police
 Available techniques:
 Static / Dynamic Code analysis
 Map policies to executable rules
 Configure the rules based on the policies and projects
at hand
 Compliance SOA Development Governance in SDLC
 Like: SOAP, WSDL, Schema, XML Metadata.
 Runtime SOA Governance
 Management, Registry, Orchestration
Regression Testing
Software development is an iterative process
An iterative development process fails without
regression testing. The same applies to security
Fixing a security vulnerability should be coupled
with a policy and an enforcement mechanism to
prevent it from reoccurring again
Regression testing practices results in a visible
quality process that reinforces trust

Prevented
SQL Injections
Policy: Validate user input; strip potentially
malicious characters like ‘ and “ as soon as you
get them
Test: Penetrate, regression test
Capture and Replay Attacks
Policy: Use signed random nonce values
and Timestamps
DoS (resulting from a large load)
Policy: Secure coding standards
Test: Simulate attacks, regression test
Prevented
Improper Error Handling
Policy: Catch/handle all exceptions
 Broken Access Control
Policy: Baseline/extended security
policies
Test: Positive & negative conditions,
regression test
 Large Payloads
Policy: Constrain schema types
Prevented
 XPath Injections
Policy: Validate user input at the entry point
 External Entity Attacks
Policy: Disable DTD processing in XML
parser
 XML Bombs
Policy: Disable DTD processing in XML parser

Securing Web Services
Old tricks for new dogs…

Start from the beginning
Assume the worst
Use standards rather than “build your own”
Be proactively consistent
Consider external and internal threats
Develop and enforce a security policy
Compliance Vs. Audit

“Build it in”, not “test it in”

Conclusion
Thank you
Resources
http://www.cgisecurity.com/ws/
http://www.oasis-open.org/committees/tc_cat.php?c
http://www.soaleaders.org/
Commercial
http://www.parasoft.com/

Protecting Web Services and Web Applications Against Security Threats

Uploaded by

Copyright:

Available Formats

Protecting Web Services and Web Applications Against Security Threats

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protecting Web Services and Web Applications Against Security Threats

Uploaded by

Copyright:

Available Formats

Protecting Web services and Web

applications against security threats

 What threats we see today

OWASP AppSec Europe 2006 2

SOAP = Service Oriented Architecture Protocol

OWASP AppSec Europe 2006 3

Who is responsible for SOA security?

When is SOA security addressed?

What activities are involved in SOA

OWASP AppSec Europe 2006 4

Problems, Threats, and Solutions

“Testing Security Into The Application”

A Four-Step Approach To Securing SOAP

Examples of Threats Prevented

OWASP AppSec Europe 2006 5

OWASP AppSec Europe 2006 6

<?xml version="1.0" encoding="UTF-8"?>

OWASP AppSec Europe 2006 7

Database Application Presentation

= Serious Security risks

OWASP AppSec Europe 2006 9

 And, yes, that post-it note with the password

 The Y2K problem revisited !

OWASP AppSec Europe 2006 12

OWASP AppSec Europe 2006 13

Common to all Web applications

OWASP AppSec Europe 2006 14

Specific to XML Web services

OWASP AppSec Europe 2006 15

However, threats also come from within:

Architect Develop Test Monitor

Assumptions Need to be able to

OWASP AppSec Europe 2006 17

String username = request.getParameter("USER");

String query = “SELECT user_id FROM Users WHERE username=‘” +

An attacker passes ' or 1=1 # for usersname

SELECT user_id FROM Users

A different approach is needed

OWASP AppSec Europe 2006 19

Assessment: Impact & Risk

Assessment: Penetration Testing

OWASP AppSec Europe 2006 21

Develop a Security Policy:

Secure implementation guidelines:

OWASP AppSec Europe 2006 22

 However, security policy also covers applications

 Enforce Security Policy Throughout SDLC

OWASP AppSec Europe 2006 25

OWASP AppSec Europe 2006 28

Old tricks for new dogs…

Compliance Vs. Audit

OWASP AppSec Europe 2006 29

OWASP AppSec Europe 2006 30

You might also like