Protecting Web services and Web applications against security threats

1
Protecting Web services and Web applications
against security threats

• Rix Groenboom
• Support Manager, Parasoft UK Ltd
• rix.groenboom_at_parasoft.com

2
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

3
First, Lets Redefine SOAP
SOAP Service Oriented Architecture Protocol ?
4
Experience

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

5
Structure of this presentation

• Problems, Threats, and Solutions
• Testing Security Into The Application
• A Four-Step Approach To Securing SOAP
• Examples of Threats Prevented

6
Problems XML Bomb

• bomb.xml

7
Problems XML Bomb

• lt?xml version"1.0" encoding"UTF-8"?gt
• lt!DOCTYPE SOAP-ENVEnvelope
• lt!ELEMENT SOAP-ENVEnvelope ANYgt
• lt!ATTLIST SOAP-ENVEnvelope entityReference
  CDATA IMPLIEDgt
• lt!ENTITY x0 "Bomb!"gt
• lt!ENTITY x1 "x0x0"gt
• lt!ENTITY x2 "x1x1"gt
• ...
• lt!ENTITY x20 "x19x19"gt
• lt!ENTITY x21 "x20x20"gt
• lt!ENTITY x22 "x21x21"gt
• gt

8
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

9
Software as a Service Security Challenges
Serious Security risks
10
Software as a Service Security 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

11
Software as a Service Security 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 whos
  next?
• Implied assumptions, external dependence
• I cant 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 !

12
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

13
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-

14
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

15
General Web Services Threats

• 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

16
General Web Services Threats

• 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/SB113926053552466409
  .html

17
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!

Audits
Assumptions
18
Why More Testing Does Not Help ?
String username request.getParameter("USER") St
ring password request.getParameter("PASSWORD")
String query SELECT user_id FROM Users WHERE
username username AND
password password Statement.execute(qu
ery)
An attacker passes ' or 11 for usersname
SELECT user_id FROM Users WHERE username'' or
11 ' AND passwordfoo
19
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

20
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.

21
Securing Web Services Step 1

• 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

22
Securing Web Services 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

23
Securing Web Services Step 2

• 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

24
Securing Web Services Step 3

• 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

25
Securing Web Services Step 4

• 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

26
General Web Services Threats 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
• Test Penetrate, regression test
• DoS (resulting from a large load)
• Policy Secure coding standards
• Test Simulate attacks, regression test

27
General Web Services Threats Prevented

• Improper Error Handling
• Policy Catch/handle all exceptions
• Test Penetrate, regression test
• Broken Access Control
• Policy Baseline/extended security policies
• Test Positive negative conditions, regression
  test
• Large Payloads
• Policy Constrain schema types
• Test Simulate attacks, regression test

28
General Web Services Threats Prevented

• XPath Injections
• Policy Validate user input at the entry point
• Test Simulate attacks, regression test
• External Entity Attacks
• Policy Disable DTD processing in XML parser
• Test Simulate attacks, regression test
• XML Bombs
• Policy Disable DTD processing in XML parser
• Test Simulate attacks, regression test

29
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

30
Company Corporate Background

• Founded in 1987, privately held
• 300 employees worldwide
• Headquarters in Monrovia, CA
• 10,000 customers worldwide
• ABN AMRO, AXA, Bank of America, Bloomberg,
  Boeing, Cisco, DCA, Disney, HP, IBM, Lehman
  Brothers, Lockheed, Northrop, Panasonic UK,
  Philips, PO Ferries, Royal Bank of Scotland
• Technical innovator
• Fifteen US patents for software technology

31
(No Transcript)
32
Conclusion

• Thank you
• Resources
• http//www.cgisecurity.com/ws/
• http//www.oasis-open.org/committees/tc_cat.php?ca
  tws
• http//www.soaleaders.org/
• Commercial
• http//www.parasoft.com/

33
Questions?