Your SlideShare is downloading. ×
  • Like
Protecting Web services and Web applications against security ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Protecting Web services and Web applications against security ...

  • 273 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
273
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
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
  • There is trust in WS because you cannot see it
  • 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
  • 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. Structure of this presentation
    • Problems, Threats, and Solutions
    • “Testing Security Into The Application”
    • A Four-Step Approach To Securing SOAP
    • Examples of Threats Prevented
  • 4. 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
  • 5. Problems: Examples
  • 6. Problems: Examples
  • 7. Problems: XML Bomb
    • bomb.xml
  • 8. 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 x99 &quot;&x98;&x98;&quot;>
    • ]>
    • 2 99 = 633825300114114700748351602688
  • 9.
    • 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 ?
  • 10. Software as a Service: Security Challenges = Serious Security risks Database Server Application Server Legacy Presentation Layer Web Services Application Logic Thin Client Web Site
  • 11. 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…
  • 12. 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”
  • 13. Software as a Service: Security Challenges
    • 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 !
  • 14. 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
  • 15. 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-*
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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);
  • 21. 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
  • 22. 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.
  • 23. 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” & “tip of the iceberg”
        • Helps you in Step 2
  • 24. 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
  • 25. 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
  • 26. Securing Web Services: Step 2
    • 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
  • 27. Securing Web Services: Step 2
    • Security Example: SQL Injection
    • String s = &quot;SELECT User_id, Username FROM USERS
    • WHERE Username = '&quot; + sUsername + &quot;' AND
    • Password = '&quot; + sPassword + &quot;'&quot;;
    • Statement queryStatement = connection.createStatement();
    • queryStatement.executeQuery(s);
    • Imagine:
        • sUsername = ‘ or 1=1 #
        • sPassword = (ANY)
  • 28. Securing Web Services: Step 2
    • Security Example: SQL Injection
    • PreparedStatement queryStatement = null;
    • try {
    • queryStatement = connection.prepareStatement(
    • &quot;SELECT User_id FROM USERS WHERE
    • Username = ? AND Password = ?&quot;);
    • queryStatement.setString (1, user);
    • queryStatement.setString (2, password);
    • } catch { …
  • 29.
    • “ Avoid Public
    • Data members”
    • class A {
    • public:
    • int a;
    • };
    Securing Web Services: Step 2 Securing Web Services: Step 2
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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 /