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@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 <?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;"> ]>

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. Application Logic Legacy Thin Client Web Site Application Server Presentation Layer Database Server Web Services 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 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 !

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. GAP Develop Architect Test Monitor Need to be able to detect vulnerabilities as early as possible. 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! Assumptions Audits

18. 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’

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. Conclusion • Thank you • Resources • http://www.cgisecurity.com/ws/ • http://www.oasis-open.org/committees/tc_cat.php?cat=ws • http://www.soaleaders.org/ • Commercial • http://www.parasoft.com/