Web application security (eng)


Published on

● Why this is important? What to do?
● Security threats & Mitigations
● Designing Secure Web Applications
● Building Secure Web Applications
● Securing Your Network, Web Server and
● Assessing Your Security

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Web application security (eng)

  1. 1. Web Application Security21/03/2012
  2. 2. Softjourn Inc.Web Application Security Anatoliy Okhotnikov Softjourn Inc.
  3. 3. Web Application Security
  4. 4. 3/21/12 Agenda ● Why this is important? What to do? ● Security threats & Mitigations ● Designing Secure Web Applications ● Building Secure Web Applications ● Securing Your Network, Web Server and Database ● Assessing Your Security
  5. 5. Why this is important? Web applications allow visitors access to the most critical resources of a web site, the web server and the database server Deface a web site Loss of trust with customers and/or visitors Damaged brand reputation Lost sales revenue Your site labeled as a malicious Loss of search engine rankings
  6. 6. Why this is important? (more) Insert spam links directing visitors to another site Insert malicious code that installs itself onto a visitor’s computer Insert malicious code that steals session IDs (cookies) Steal visitor information and browsing habits Steal account information Steal information stored in the database Access restricted content And much more...
  7. 7. What to do? Build a hack-resilient application reduces the likelihood of a successful attack and mitigates the extent of damage if an attack occurs. It resides on a secure host(server) in a secure network and is developed using secure design and development guidelines.
  8. 8. Why this is important?
  9. 9. Security threats SQL injection OS Command injection Classic buffer overflow Cross-site scripting (XSS) Missing authentication and/or authorization Direct site attacks more...
  10. 10. Security threats (more) Use of Hard-coded Credentials Missing Encryption of Sensitive Data Unrestricted Upload of File with Dangerous Type Reliance on Untrusted Inputs in a Security Decision Execution with Unnecessary Privileges Cross-Site Request Forgery (CSRF) Improper Limitation of a Pathname to a Restricted Directory (Path Traversal) Download of Code Without Integrity Check even more...
  11. 11. Security threats (even more) Incorrect Authorization Inclusion of Functionality from Untrusted Control Sphere Incorrect Permission Assignment for Critical Resource Use of Potentially Dangerous Function Use of a Broken or Risky Cryptographic Algorithm Incorrect Calculation of Buffer Size Improper Restriction of Excessive Authentication Attempts URL Redirection to Untrusted Site (Open Redirect) Uncontrolled Format String Integer Overflow or Wraparound Use of a One-Way Hash without a Salt
  12. 12. Mitigations
  13. 13. Mitigations Establish and maintain control over all of your inputs and outputs Lock down your environment Assume that external components can be subverted, and your code can be read by anyone Use industry-accepted security features instead of inventing your own more...
  14. 14. Mitigations (more) Use libraries and frameworks that make it easier to avoid introducing weaknesses Integrate security into the entire software development lifecycle Use a broad mix of methods to comprehensively find and prevent weaknesses Allow locked-down clients to interact with your software
  15. 15. Designing Secure Web Applications
  16. 16. Designing Secure Web Applications  Design input validation strategies  Partition Web sites into open and restricted areas  Implement effective account management practices  Develop effective authentication and authorization strategies  Protect sensitive data  Protect user sessions  Prevent parameter manipulation  Handle exceptions securely  Secure an application’s configuration management features  List audit and logging considerations
  17. 17. Designing: input validation strategies
  18. 18. Designing: input validation strategies  Assume ALL input is malicious  Centralize your approach  Do not rely on client-side validation  Be careful with canonicalization issues  Constrain, reject and sanitize your input  Use common input handling practices
  19. 19. Designing: authentication
  20. 20. Designing: authentication Separate public and restricted areas Use account lockout policies for end-user accounts Support password expiration periods Be able to disable accounts Do not store passwords in user stores Require strong password Do not send password over the wire in plaintext Protect authentication cookies
  21. 21. Designing: authorization Use multiple gatekeepers Restrict user access to system level resources Consider authorization granularity
  22. 22. Designing: configuration management  Secure your administration interfaces  Secure your configuration stores  Separate administration privileges  Use least privileged process and service accounts
  23. 23. Designing: sensitive data Secrets Sensitive per user data
  24. 24. Designing: session management  Use SSL to protect session authentication cookies  Encrypt the contents of the authentication cookies  Limit session lifetime  Protect session state from unauthorized access
  25. 25. Designing: cryptography Do not develop your own cryptography Keep unencrypted data close to the algorithm Use the correct algorithm and correct key size Secure your encryption keys
  26. 26. Designing: parameter manipulation  Encrypt sensitive cookie state  Make sure that users do not bypass your checks  Validate all values sent from the client  Do not trust HTTP header information
  27. 27. Designing: exception management  Do not leak information to the client  Log detailed error messages  Catch exceptions
  28. 28. Designing: auditing and logging  Audit and log access across application tiers  Consider identity flow  Log key events  Secure log files  Back up and analyze log files regularly
  29. 29. Building Secure Web Applications
  30. 30. Building Secure Web Applications  Role-based Security, URL authorization  Code Access Security  Be aware of unauthorized access, privilege elevation, code injection, information disclosure, tampering  Log events  Data Access  Obfuscation
  31. 31. Secure Web App: class design  Restrict Class & Member Visibility  Seal Non-Base Classes  Restrict Which Users Can Call Your Code  Expose Fields Using Properties
  32. 32. Secure Web App: exceptions Use Structured Exception Handling Do Not Log Sensitive Data Do Not Reveal Sensitive System or Application Information Consider Exception Filter Issues Consider an Exception Management Framework
  33. 33. Secure Web App: file I/O Avoid Untrusted Input for File Names Do Not Trust Environment Variables Validate Input File Names Constrain File I/O Within Your Applications Context
  34. 34. Secure Web App: serialization  Do Not Serialize Sensitive Data  Validate Serialized Data Streams  Partial Trust Considerations
  35. 35. Secure Web App: threading Do Not Cache the Results of Security Checks Consider Impersonation Tokens Synchronize Static Class Constructors Synchronize Dispose Methods
  36. 36. Secure Web App: cryptography  Use Platform-provided Cryptographic Services  Key Generation  Key Storage  Key Exchange  Key Maintenance
  37. 37. Secure Web App: architecture & design  Input validation  Authentication  Authorization  Configuration Management  Sensitive Data  Session Management  Cryptography  Parameter Manipulation  Exception Management  Auditing & Logging
  38. 38. Securing Your Network, Web Server and Database Securing your network Securing your web server Securing your database
  39. 39. Securing Your Network
  40. 40. Securing Your Network: routers  Patch & Update  Ingress & Egress Filtering / Screen Traffic  Prevent TTL Expired Messages with Values of 1 or 0  Do Not Receive or Forward Directed Broadcast Traffic  Disable Unused Interfaces  Apply Strong Password Policies  Use Static Routing  Audit Web Facing Administration Interfaces  Auditing and Logging / Intrusion Detection
  41. 41. Securing Your Network: firewalls  Patch & Update  Filters  Packet filters  Circuit-level filters  Application filters  Stateful inspection  Custom application filters  Logging & Auditing  Perimeter Networks
  42. 42. Securing Your Network: switches  Patches & Updates  Virtual Local Area Networks (VLANs)  Insecure Defaults  Services  Encryption
  43. 43. Securing Your Web Server Be aware of profiling, denial of service, unauthorized access, arbitrary code execution, elevation of privileges, viruses, worms and trojan horses Patches & Updates. Services. Protocols. Accounts. Files & Directories. Shares. Ports. Auditing & Logging. Sites & Virtual Directories. Script Mappings. API Filters. Server Certificates. Permissions. Error Messages. Sample & test files.
  44. 44. Securing Your Database Be aware of SQL injection, network eavesdropping, unauthorized server access, password cracking Patches & Upgrades. Disable unused server services Restrict server to TCP/IP, harden TCP/IP stack Secure DB accounts, delete or disable unused accounts, enforce strong password policy, restrict remote logons, disable anonymous Verify permissions on files & directories, secure or remove tools, utilities and SDKs Restrict access to DB port Log all failed logon attempts, actions, enable SQL logging Run server using a least privileged account Do not grant permission to the public role Remove sample DBs, secure stored procedures
  45. 45. Assessing Your Security Get organized. Establish the process Standardize how you verify web application security (ASVS) Assemble tools suite (OWASP Live CD Project) Code review. CodeCrawler, Orizon, O2 Testing/Penetration. WebScarab
  46. 46. Assessment: Injection
  47. 47. Assessment: Injection Verify that all use of interpreters clearly separates untrusted data from the command query. Check the code. Code analysis tools can help. Penetration testing with exploits. Automated dynamic scanning which exercises the application.
  48. 48. Assessment: Cross-Site Scripting (XSS)
  49. 49. Assessment: Cross-Site Scripting (XSS)  Ensure that all user supplied input sent back to the browser is verified to be safe and properly escaped before it is included in the output page.  Both static and dynamic tools can find some XSS problems automatically, but complete coverage requires a combination of manual code review and manual penetration testing.  Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
  50. 50. Assessment: Broken Authentication and Session Management
  51. 51. Assessment: Broken Authentication and Session Management  Are credentials always protected when stored using hashing or encryption?  Can credentials be guessed or overwritten through weak account management functions?  Are session IDs exposed in the URL?  Are session IDs vulnerable to session fixation attacks?  Do sessions IDs timeout and can users log out?  Are session IDs rotated after successful login?  Are passwords, session IDs, and other credentials sent over TLS connections?
  52. 52. Assessment: Insecure Direct Object References
  53. 53. Assessment: Insecure Direct Object References Verify that all object references have appropriate defenses. Code review/testing. For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested. If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.
  54. 54. Assessment: Cross-Site Request Forgery (CSRF)
  55. 55. Assessment: Cross-Site Request Forgery (CSRF)  Verify if each link and form contains an unpredictable token for each user.  Check multistep transactions, as they are not inherently immune.  Note that session cookies, source IP addresses, and other information that is automatically sent by the browser doesnt count since this information is also included in forged requests.  OWASPs CSRF Tester tool can help generate test cases to demonstrate the dangers of CSRF flaws.
  56. 56. Assessment: Security Misconfiguration
  57. 57. Assessment: Security Misconfiguration  Do you have a process for keeping all your software up to date? This includes the OS, Web/App Server, DBMS, applications and all code libraries.  Is everything unnecessary disabled, removed or not installed (eg ports, services, pages, accounts, privileges)?  Are default account passwords changed or disabled?  Is your error handling set up to prevent stack traces and other overly informative error messages from leaking?  Are the security settings in your development frameworks and libraries understood and configured properly?
  58. 58. Assessment: Insecure Cryptographic Storage
  59. 59. Assessment: Insecure Cryptographic Storage Which data is sensitive enough to require encryption? Is it encrypted everywhere it is stored long term, particularly in backups of this data? Can the authorized users only access decrypted copies of the data? Is a strong standard encryption algorithm used? Is a strong key generated, protected from unauthorized access and key change is planned for?
  60. 60. Assessment: Failure to Restrict URL Access
  61. 61. Assessment: Failure to Restrict URL Access Verify every page. Consider is the page supposed to be public or private. Is authentication required to access a private page? Is a private page supposed to be accessible to ANY authenticated user? If not, is an authorization check made to ensure the user has permission to access that page? Verify external security mechanisms are properly configured for every page? If code level protection is used, verify that it is in place for every required page. Penetration testing can also verify whether proper protection is in place.
  62. 62. Assessment: Insufficient Transport Layer Protection
  63. 63. Assessment: Insufficient Transport Layer Protection  Is SSL used to protect all authentication related traffic?  Is SSL used for all resources on all private pages and services?  Are strong algorithms only supported?  Have all session cookies their secure flag set?  Is the server certificate legitimate and properly configured for that server?
  64. 64. Assessment: Unvalidated Redirects and Forwards
  65. 65. Assessment: Unvalidated Redirects and Forwards  Review the code for all uses of redirect or forward. For each use, identify if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.  Spider the site to see if it generates any redirects (300- 307). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such URL. If so, change the URL target and observe whether the site redirects to the new target.  If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and those that do.
  66. 66. Assessment: Additional Risks to Consider
  67. 67. Assessment: Additional Risks to Consider  Clickjacking (UI redress attack)  Concurrency flaws  Denial of service  Header injection  Information leakage and Improper error handling  Insufficient anti-automation  Insufficient logging and accountability  Lack of intrusion detection and response  Malicious file execution
  68. 68. Links• http://en.wikipedia.org/wiki/Web_application_s ecurity• http://cwe.mitre.org/top25/• http://msdn.microsoft.com/en- us/library/ff649874.aspx• http://www.applicure.com/solutions/web- application-security• http://www.clusif.asso.fr/fr/production/ouvrage s/pdf/CLUSIF-2010-Web-application- security.pdf• http://www.webappsec.org/• http://code.google.com/p/owasptop10/ Copyright © 2000-2011 Softjourn, Inc. All rights reserved
  69. 69. Questions & discussion“Anatoliy Okhotnikov”<aokhotnikov@softjourn.com> Copyright © 2000-2011 Softjourn, Inc. All rights reserved