Your SlideShare is downloading. ×

13:46, 7 June 2006

240

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
240
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. Protecting Web services and Web applications against security threats Rix Groenboom Support Manager Parasoft UK Ltd [email_address]
    • 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 = S ervice O riented A rchitecture P rotocol 
    • 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=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
      • <!DOCTYPE SOAP-ENV:Envelope [
      • <!ELEMENT SOAP-ENV:Envelope ANY>
      • <!ATTLIST SOAP-ENV:Envelope entityReference CDATA #IMPLIED>
      • <!ENTITY x0 &quot;Bomb!&quot;>
      • <!ENTITY x1 &quot;&x0;&x0;&quot;>
      • <!ENTITY x2 &quot;&x1;&x1;&quot;>
      • ...
      • <!ENTITY x20 &quot;&x19;&x19;&quot;>
      • <!ENTITY x21 &quot;&x20;&x20;&quot;>
      • <!ENTITY x22 &quot;&x21;&x21;&quot;>
      • ]>
    • 8.
      • 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 ?
    • 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. 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. 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 GAP Need to be able to detect vulnerabilities as early as possible. Develop Test Monitor Architect
    • 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. 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/

    ×