13:46, 7 June 2006

341 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
341
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Come up with an attention grabber SOA brings previously hidden mainframes and components that were not accessible before and make them accessible to the web - > security, unproven tech. Implied trust between partners. We need to recognize where the assets are, we are talking real business assets, financial, attackers and $$ motivated. SOAP is where you are going to put you’re your WSS
  • When is SOAP security addressed? Not at end, but from the beginning.. What activities? SOAP sec is a process, need to have sec requirements,  design specs  implement correctly, then test. How are activities organized? Still just telling people what I will talk about. Everyone has a role here.
  • There is trust in WS because you cannot see it
  • There is trust in WS because you cannot see it
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • What WS-* standards don’t address: Anything that isn’t standard Custom requirements Specific threat mediation Prescribe themselves Only provide standard mechanisms Need security analysis “ Fit like an old pair of boots” Confusing and esoteric Liquid, subject to change
  • Applying security late is costly, etc. Don’t make assumptions that nobody is gonna access it
  • 13:46, 7 June 2006

    1. 1. Protecting Web services and Web applications against security threats Rix Groenboom Support Manager Parasoft UK Ltd [email_address]
    2. 2. What We Will Explore <ul><li>What threats we see today </li></ul><ul><li>Practices for securing Web Services and SOA </li></ul><ul><li>Use of a Policy based Approach: </li></ul><ul><ul><li>“Inside Out & Outside In” </li></ul></ul>
    3. 3. First, Lets Redefine “SOAP” SOAP = S ervice O riented A rchitecture P rotocol 
    4. 4. Experience <ul><li>Who is responsible for SOA security? </li></ul><ul><li>When is SOA security addressed? </li></ul><ul><li>What activities are involved in SOA security? </li></ul>
    5. 5. Structure of this presentation <ul><li>Problems, Threats, and Solutions </li></ul><ul><li>“Testing Security Into The Application” </li></ul><ul><li>A Four-Step Approach To Securing SOAP </li></ul><ul><li>Examples of Threats Prevented </li></ul>
    6. 6. Problems: XML Bomb <ul><li>bomb.xml </li></ul>
    7. 7. Problems: XML Bomb <ul><li><?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> </li></ul><ul><li><!DOCTYPE SOAP-ENV:Envelope [ </li></ul><ul><li><!ELEMENT SOAP-ENV:Envelope ANY> </li></ul><ul><li><!ATTLIST SOAP-ENV:Envelope entityReference CDATA #IMPLIED> </li></ul><ul><li><!ENTITY x0 &quot;Bomb!&quot;> </li></ul><ul><li><!ENTITY x1 &quot;&x0;&x0;&quot;> </li></ul><ul><li><!ENTITY x2 &quot;&x1;&x1;&quot;> </li></ul><ul><li>... </li></ul><ul><li><!ENTITY x20 &quot;&x19;&x19;&quot;> </li></ul><ul><li><!ENTITY x21 &quot;&x20;&x20;&quot;> </li></ul><ul><li><!ENTITY x22 &quot;&x21;&x21;&quot;> </li></ul><ul><li>]> </li></ul>
    8. 8. <ul><li>Enterprise network protected by firewall </li></ul><ul><li>Application is the only way in </li></ul><ul><li>Must keep application open for business </li></ul><ul><li>User (potential hackers) must have access to the application </li></ul>What is wrong with this picture ?
    9. 9. Software as a Service: Security Challenges = Serious Security risks Database Server Application Server Legacy Presentation Layer Web Services Application Logic Thin Client Web Site
    10. 10. Software as a Service: Security Challenges <ul><li>Web services vulnerabilities can be present in the: </li></ul><ul><ul><li>Operating system or the applications that ship with it </li></ul></ul><ul><ul><li>Network </li></ul></ul><ul><ul><li>Database </li></ul></ul><ul><ul><li>Web server </li></ul></ul><ul><ul><li>Application server </li></ul></ul><ul><ul><li>XML parser or Web services implementation / stack </li></ul></ul><ul><ul><li>Application code </li></ul></ul><ul><ul><li>XML appliance </li></ul></ul><ul><li>And, yes, that post-it note with the password under your drawer or keyboard… </li></ul>
    11. 11. Software as a Service: Security Challenges <ul><li>Problems with Web services and SOA </li></ul><ul><ul><li>Cut through firewall </li></ul></ul><ul><ul><ul><li>SOAP messages often travel over HTTP port 80 </li></ul></ul></ul><ul><ul><li>Business processes on the web </li></ul></ul><ul><ul><ul><li>Expose internal APIs to anonymous users </li></ul></ul></ul><ul><ul><li>New technology, new mistakes </li></ul></ul><ul><ul><ul><li>Once web apps are locked tighter, guess who’s next? </li></ul></ul></ul><ul><ul><li>Implied assumptions, external dependence </li></ul></ul><ul><ul><ul><li>“ I can’t see it, neither can a hacker” </li></ul></ul></ul><ul><ul><ul><li>“ We can trust that service to work properly” </li></ul></ul></ul><ul><ul><ul><li>“ The use of the service is constrained by the client application” </li></ul></ul></ul><ul><li>The Y2K problem revisited ! </li></ul>
    12. 12. Securing Web Services – Solutions So far <ul><li>General Practices </li></ul><ul><ul><li>Define acceptable protocols </li></ul></ul><ul><ul><ul><li>Shut down other services </li></ul></ul></ul><ul><ul><ul><li>Lock down firewall (change port) </li></ul></ul></ul><ul><ul><li>Enforce security mechanisms </li></ul></ul><ul><ul><ul><li>Authentication </li></ul></ul></ul><ul><ul><ul><li>Access Control </li></ul></ul></ul><ul><ul><ul><li>Auditing </li></ul></ul></ul><ul><ul><ul><li>… to Z </li></ul></ul></ul>
    13. 13. Securing Web Services – Solutions So far <ul><li>SOA Security Mechanisms </li></ul><ul><ul><li>WS-Security </li></ul></ul><ul><ul><ul><li>XML Encryption </li></ul></ul></ul><ul><ul><ul><li>XML Signature </li></ul></ul></ul><ul><ul><ul><li>X509 </li></ul></ul></ul><ul><ul><ul><li>Username Tokens </li></ul></ul></ul><ul><ul><ul><li>SAML </li></ul></ul></ul><ul><ul><li>WS-Trust </li></ul></ul><ul><ul><li>WS-SecureConversation </li></ul></ul><ul><ul><li>WS-SecurityPolicy </li></ul></ul><ul><ul><li>WS-Federation </li></ul></ul><ul><ul><li>WS-Privacy </li></ul></ul><ul><ul><li>WS-* </li></ul></ul>
    14. 14. General Web Services Threats <ul><li>Common to all Web applications </li></ul><ul><ul><li>SQL Injections </li></ul></ul><ul><ul><ul><li>Special characters in queries </li></ul></ul></ul><ul><ul><li>Capture and Replay Attacks </li></ul></ul><ul><ul><ul><li>Man in the middle attacks </li></ul></ul></ul><ul><ul><li>DoS (resulting from a large load) </li></ul></ul><ul><ul><ul><li>Blow up application from inside </li></ul></ul></ul><ul><ul><li>Improper Error Handling </li></ul></ul><ul><ul><ul><li>Dump of stack trace etc </li></ul></ul></ul><ul><ul><li>Broken Access Control </li></ul></ul><ul><ul><ul><li>Take over earlier sessions tokens etc </li></ul></ul></ul>
    15. 15. General Web Services Threats <ul><li>Specific to XML Web services </li></ul><ul><ul><li>Large Payloads </li></ul></ul><ul><ul><ul><li>Send huge XML load, or generate huge responses </li></ul></ul></ul><ul><ul><li>XPath Injections </li></ul></ul><ul><ul><ul><li>Query XML documents for certain nodes </li></ul></ul></ul><ul><ul><li>External Entity Attacks </li></ul></ul><ul><ul><ul><li>Misuse pointed to XML data using URI </li></ul></ul></ul><ul><ul><li>XML Bombs </li></ul></ul><ul><ul><ul><li>Recursive XML entity declaration </li></ul></ul></ul>
    16. 16. General Web Services Threats <ul><li>However, threats also come from within: </li></ul><ul><ul><li>Since 1999, the percentage of companies reporting a computer-security incident from inside is almost the same as those reporting it from the outside </li></ul></ul><ul><ul><li>28.9% of of security incidents come from employees </li></ul></ul><ul><li>Source: </li></ul><ul><ul><li>The Wall Street Journal Online (Feb 13, 2006) </li></ul></ul><ul><ul><li>http://online.wsj.com/article/SB113926053552466409.html </li></ul></ul>
    17. 17. Challenge - Properly Addressing Security <ul><li>Testing security “into” the Web service application: </li></ul><ul><ul><li>Common “end-of-cycle” security testing can detect some standard application security vulnerabilities, however… </li></ul></ul><ul><ul><li>Approaching security merely as a “bug finding” exercise is inefficient and costly </li></ul></ul><ul><ul><li>It is impossible to cover all possible execution paths with testing! </li></ul></ul>Audits Assumptions GAP Need to be able to detect vulnerabilities as early as possible. Develop Test Monitor Architect
    18. 18. Why More Testing Does Not Help ? String username = request.getParameter(&quot;USER&quot;); String password = request.getParameter(&quot;PASSWORD&quot;); An attacker passes ' or 1=1 # for usersname SELECT user_id FROM Users WHERE username=' ' or 1=1 # ' AND password= ‘foo’ String query = “SELECT user_id FROM Users WHERE username=‘” + username + “’ AND password=‘” + password + “’”; Statement.execute(query);
    19. 19. Securing Web Services <ul><li>A different approach is needed </li></ul><ul><ul><li>A preventive, policy-based approach rather than a reactive one </li></ul></ul><ul><ul><li>Security, like quality, must be built into the application and cannot be tested in </li></ul></ul><ul><ul><li>Application are large and complex </li></ul></ul><ul><li>We propose a combined approach: </li></ul><ul><ul><li>Outside In </li></ul></ul><ul><ul><li>Inside Out </li></ul></ul>
    20. 20. Securing Web Services: Step 1 <ul><li>Assessment: Impact & Risk </li></ul><ul><ul><li>Analyze the business process </li></ul></ul><ul><ul><ul><li>Assets, users, entry points </li></ul></ul></ul><ul><ul><ul><li>What needs to be protected? How? </li></ul></ul></ul><ul><ul><ul><li>Outsource for expertise before implementation </li></ul></ul></ul><ul><ul><li>Define security threats </li></ul></ul><ul><ul><ul><li>CIA: Confidentiality, Availability, Integrity </li></ul></ul></ul><ul><ul><ul><li>Risk = Threat x Vulnerability x Expected Loss </li></ul></ul></ul><ul><ul><ul><ul><li>Threat = Motivated Attacker with Path to Valuable Asset </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Vulnerability = Weakness in system </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Expected Loss = Impact of threat realization </li></ul></ul></ul></ul><ul><ul><ul><li>Misusage, the general WS threats, etc. </li></ul></ul></ul>
    21. 21. Securing Web Services: Step 1 <ul><li>Assessment: Penetration Testing </li></ul><ul><ul><li>Find a few general vulnerabilities </li></ul></ul><ul><ul><li>Many penetration activities can be automated </li></ul></ul><ul><ul><ul><li>Generate injection attacks, XSS, scan for broken access control, etc. </li></ul></ul></ul><ul><ul><ul><li>Simulate large loads, generate big messages, etc. </li></ul></ul></ul><ul><ul><li>Penetration testing is not exhaustive </li></ul></ul><ul><ul><li>But, a vulnerability you find </li></ul></ul><ul><ul><ul><li>Is like a real bug: if you see one, there are 1000 you do not see ! </li></ul></ul></ul><ul><ul><ul><li>“where smoke is, is fire” </li></ul></ul></ul><ul><ul><ul><li>Helps you in Step 2 </li></ul></ul></ul>
    22. 22. Securing Web Services: Step 2 <ul><li>Develop a Security Policy: </li></ul><ul><ul><li>A security policy is a set of guidelines that are an overall strategy for application security </li></ul></ul><ul><li>Secure implementation guidelines: </li></ul><ul><ul><li>Use trusted libraries </li></ul></ul><ul><ul><li>Adhere to coding and XML standards </li></ul></ul><ul><ul><ul><li>Release IO resources in the code </li></ul></ul></ul><ul><ul><ul><li>Turn off DTD support in XML parsers </li></ul></ul></ul><ul><ul><ul><li>Constrain schema types </li></ul></ul></ul><ul><ul><li>Review implementation for errors </li></ul></ul><ul><ul><li>Turn off features by default </li></ul></ul>
    23. 23. Securing Web Services: Step 2 <ul><li>However, security policy also covers applications code </li></ul><ul><li>Key areas that need are required: </li></ul><ul><ul><li>Access control and Authentication </li></ul></ul><ul><ul><li>Denial of Service </li></ul></ul><ul><ul><li>Command Injection </li></ul></ul><ul><ul><li>Concurrency </li></ul></ul><ul><ul><li>Cryptography </li></ul></ul><ul><ul><li>Error Handling </li></ul></ul><ul><ul><li>Input Validation </li></ul></ul><ul><ul><li>Logging </li></ul></ul><ul><ul><li>Malicious Code </li></ul></ul><ul><ul><li>Memory and Session Management </li></ul></ul>
    24. 24. Securing Web Services: Step 3 <ul><li>Enforce Security Policy Throughout SDLC </li></ul><ul><ul><li>A policy without an automated enforcement mechanisms is like law without police </li></ul></ul><ul><li>Available techniques: </li></ul><ul><ul><li>Static / Dynamic Code analysis </li></ul></ul><ul><ul><ul><li>Map policies to executable rules </li></ul></ul></ul><ul><ul><ul><li>Configure the rules based on the policies and projects at hand </li></ul></ul></ul><ul><ul><li>Compliance SOA Development Governance in SDLC </li></ul></ul><ul><ul><ul><li>Like: SOAP, WSDL, Schema, XML Metadata. </li></ul></ul></ul><ul><ul><li>Runtime SOA Governance </li></ul></ul><ul><ul><ul><li>Management, Registry, Orchestration </li></ul></ul></ul>
    25. 25. Securing Web Services: Step 4 <ul><li>Regression Testing </li></ul><ul><ul><li>Software development is an iterative process </li></ul></ul><ul><ul><li>An iterative development process fails without regression testing. The same applies to security </li></ul></ul><ul><ul><li>Fixing a security vulnerability should be coupled with a policy and an enforcement mechanism to prevent it from reoccurring again </li></ul></ul><ul><ul><li>Regression testing practices results in a visible quality process that reinforces trust </li></ul></ul>
    26. 26. General Web Services Threats Prevented <ul><li>SQL Injections </li></ul><ul><ul><li>Policy: Validate user input; strip potentially malicious characters like ‘ and “ as soon as you get them </li></ul></ul><ul><ul><li>Test: Penetrate, regression test </li></ul></ul><ul><li>Capture and Replay Attacks </li></ul><ul><ul><li>Policy: Use signed random nonce values and Timestamps </li></ul></ul><ul><ul><li>Test: Penetrate, regression test </li></ul></ul><ul><li>DoS (resulting from a large load) </li></ul><ul><ul><li>Policy: Secure coding standards </li></ul></ul><ul><ul><li>Test: Simulate attacks, regression test </li></ul></ul>
    27. 27. General Web Services Threats Prevented <ul><li>Improper Error Handling </li></ul><ul><ul><li>Policy: Catch/handle all exceptions </li></ul></ul><ul><ul><li>Test: Penetrate, regression test </li></ul></ul><ul><li>Broken Access Control </li></ul><ul><ul><li>Policy: Baseline/extended security policies </li></ul></ul><ul><ul><li>Test: Positive & negative conditions, regression test </li></ul></ul><ul><li>Large Payloads </li></ul><ul><ul><li>Policy: Constrain schema types </li></ul></ul><ul><ul><li>Test: Simulate attacks, regression test </li></ul></ul>
    28. 28. General Web Services Threats Prevented <ul><li>XPath Injections </li></ul><ul><ul><li>Policy: Validate user input at the entry point </li></ul></ul><ul><ul><li>Test: Simulate attacks, regression test </li></ul></ul><ul><li>External Entity Attacks </li></ul><ul><ul><li>Policy: Disable DTD processing in XML parser </li></ul></ul><ul><ul><li>Test: Simulate attacks, regression test </li></ul></ul><ul><li>XML Bombs </li></ul><ul><ul><li>Policy: Disable DTD processing in XML parser </li></ul></ul><ul><ul><li>Test: Simulate attacks, regression test </li></ul></ul>
    29. 29. Securing Web Services <ul><li>Old tricks for new dogs… </li></ul><ul><ul><li>Start from the beginning </li></ul></ul><ul><ul><li>Assume the worst </li></ul></ul><ul><ul><li>Use standards rather than “build your own” </li></ul></ul><ul><ul><li>Be proactively consistent </li></ul></ul><ul><ul><li>Consider external and internal threats </li></ul></ul><ul><ul><li>Develop and enforce a security policy </li></ul></ul><ul><li>Compliance Vs. Audit </li></ul><ul><ul><li>“Build it in”, not “test it in” </li></ul></ul>
    30. 30. Conclusion <ul><li>Thank you </li></ul><ul><li>Resources </li></ul><ul><ul><li>http://www.cgisecurity.com/ws/ </li></ul></ul><ul><ul><li>http://www.oasis-open.org/committees/tc_cat.php?cat=ws </li></ul></ul><ul><ul><li>http:// www.soaleaders.org / </li></ul></ul><ul><li>Commercial </li></ul><ul><ul><li>http://www.parasoft.com/ </li></ul></ul>

    ×