Protecting Web services and Web applications against security ...

Copyright © 2006 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.

The OWASP Foundation

OWASP

AppSec

Europe

May 2006 http://www.owasp.org/

Protecting Web services and Web applications against security threats

Rix GroenboomSupport ManagerParasoft UK [email protected]

2OWASP AppSec Europe 2006

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”


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: Size and Complexity

3 MLOC of SW 50 lines = 25 cm 100 = 50 cm 200 = 1 m 1,000 = 5 m 10 kloc = 50 m 100 kloc = 500 m 1 Mloc = 5 km 3 Mloc = 15 km 8 Mloc = MARATHON


Problems: Examples


Problems: Examples


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 x99 "&x98;&x98;">]>

299 = 633825300114114700748351602688


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

What is wrong with this picture ?


Software as a Service: Security Challenges

= Serious Security risks

DatabaseServer

Application Server

Legacy

Presentation Layer

Web Services

Application Logic Thin

ClientWeb Site



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…



Problems with Web services and SOACut 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 Year2000 problem revisited ! Gary McGraw (at CMU/SEI meeting)

Y2K problem: Applications never designed to work > 30,40 years Source code contains root cause of the problems One defect (bug) is enough to cause serious problems

And now with security: Applications never designed to be connected to

networks / internet Source code contains root cause of the problems One vulnerability is enough to cause serious risk And worse, people hunt for them !


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 applicationsSQL 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 servicesLarge 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/

SB113926053552466409.html


AuditsAssumptions

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!

GAPNeed to be able to detect vulnerabilities as

early as possible.

Develop Test MonitorArchitect


Why More Testing Does Not Help ?

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

An attacker passes ' or 1=1 # for usersname

SELECT user_id FROM UsersWHERE username='' or 1=1 #' AND password=‘foo’

String query = “SELECT user_id FROM Users WHERE username=‘” + username + “’ AND password=‘” + password + “’”;Statement.execute(query);


Securing Web Services

A different approach is neededA preventive, policy-based approach rather

than a reactive oneSecurity, like quality, must be built into the

application and cannot be tested inApplication are large and complex

We propose a combined approach:Outside In Inside Out


Securing Web Services: Step 1

Assessment: Impact & RiskAnalyze 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 TestingFind a few general vulnerabilitiesMany 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 exhaustiveBut, 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” & “tip of the iceberg” 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 librariesAdhere to coding and XML standards

Release IO resources in the code Turn off DTD support in XML parsers Constrain schema types

Review implementation for errorsTurn 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



Securing input to the application: Identify all input routines (like getparameter) Implement validation functions Check that all security related inputs are done from

a wrapper environment

Securing output of the application: Identify all the output routines (like DB access) Write logging routines Check that all output routines are followed by

logging routine

Make sure application does not through exceptions etc



Security Example: SQL Injection

String s = "SELECT User_id, Username FROM USERS WHERE Username = '" + sUsername + "' AND Password = '" + sPassword + "'";…Statement queryStatement =

connection.createStatement();queryStatement.executeQuery(s);

Imagine:

sUsername = ‘ or 1=1 #sPassword = (ANY)



Security Example: SQL Injection

PreparedStatement queryStatement = null;try { queryStatement = connection.prepareStatement(

"SELECT User_id FROM USERS WHERE Username = ? AND Password = ?");

queryStatement.setString (1, user); queryStatement.setString (2, password);…} catch { …


“Avoid PublicData members”

class A {

public:

int a;

};

Securing Web Services: Step 2Securing Web Services: Step 2



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 TestingSoftware development is an iterative processAn iterative development process fails without

regression testing. The same applies to securityFixing 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


General Web Services Threats Prevented

SQL InjectionsPolicy: 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 standardsTest: Simulate attacks, regression test



Improper Error HandlingPolicy: Catch/handle all exceptionsTest: Penetrate, regression test

Broken Access ControlPolicy: Baseline/extended security policiesTest: Positive & negative conditions,

regression test Large Payloads

Policy: Constrain schema typesTest: Simulate attacks, regression test



XPath InjectionsPolicy: Validate user input at the entry pointTest: Simulate attacks, regression test

External Entity AttacksPolicy: Disable DTD processing in XML

parserTest: Simulate attacks, regression test

XML BombsPolicy: Disable DTD processing in XML

parserTest: Simulate attacks, regression test


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” Security is not a bug finding exercise (one is enough)

Remember: Security is Y2K revisited


Conclusion

Thank you

Resourceshttp://www.cgisecurity.com/ws/http://www.oasis-open.org/committees/tc_cat.p

hp?cat=wshttp://www.soaleaders.org/

Commercialhttp://www.parasoft.com/

Date post:	17-May-2015
Category:	Documents
Upload:	zubin67
View:	293 times
Download:	2 times

Protecting Web services and Web applications against security ...

Documents