Your SlideShare is downloading. ×
Web application security (eng)
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Web application security (eng)


Published on

● Why this is important? What to do? …

● 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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Web Application Security21/03/2012
  • 2. Softjourn Inc.Web Application Security Anatoliy Okhotnikov Softjourn Inc.
  • 3. Web Application Security
  • 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. 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. 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. 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. Why this is important?
  • 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. 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. 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. Mitigations
  • 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. 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. Designing Secure Web Applications
  • 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. Designing: input validation strategies
  • 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. Designing: authentication
  • 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. Designing: authorization Use multiple gatekeepers Restrict user access to system level resources Consider authorization granularity
  • 22. Designing: configuration management  Secure your administration interfaces  Secure your configuration stores  Separate administration privileges  Use least privileged process and service accounts
  • 23. Designing: sensitive data Secrets Sensitive per user data
  • 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. 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. 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. Designing: exception management  Do not leak information to the client  Log detailed error messages  Catch exceptions
  • 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. Building Secure Web Applications
  • 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. 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. 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. 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. Secure Web App: serialization  Do Not Serialize Sensitive Data  Validate Serialized Data Streams  Partial Trust Considerations
  • 35. Secure Web App: threading Do Not Cache the Results of Security Checks Consider Impersonation Tokens Synchronize Static Class Constructors Synchronize Dispose Methods
  • 36. Secure Web App: cryptography  Use Platform-provided Cryptographic Services  Key Generation  Key Storage  Key Exchange  Key Maintenance
  • 37. Secure Web App: architecture & design  Input validation  Authentication  Authorization  Configuration Management  Sensitive Data  Session Management  Cryptography  Parameter Manipulation  Exception Management  Auditing & Logging
  • 38. Securing Your Network, Web Server and Database Securing your network Securing your web server Securing your database
  • 39. Securing Your Network
  • 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. Securing Your Network: firewalls  Patch & Update  Filters  Packet filters  Circuit-level filters  Application filters  Stateful inspection  Custom application filters  Logging & Auditing  Perimeter Networks
  • 42. Securing Your Network: switches  Patches & Updates  Virtual Local Area Networks (VLANs)  Insecure Defaults  Services  Encryption
  • 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. 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. 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. Assessment: Injection
  • 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. Assessment: Cross-Site Scripting (XSS)
  • 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. Assessment: Broken Authentication and Session Management
  • 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. Assessment: Insecure Direct Object References
  • 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. Assessment: Cross-Site Request Forgery (CSRF)
  • 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. Assessment: Security Misconfiguration
  • 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. Assessment: Insecure Cryptographic Storage
  • 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. Assessment: Failure to Restrict URL Access
  • 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. Assessment: Insufficient Transport Layer Protection
  • 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. Assessment: Unvalidated Redirects and Forwards
  • 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. Assessment: Additional Risks to Consider
  • 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. Links• ecurity•• us/library/ff649874.aspx• application-security• s/pdf/CLUSIF-2010-Web-application- security.pdf•• Copyright © 2000-2011 Softjourn, Inc. All rights reserved
  • 69. Questions & discussion“Anatoliy Okhotnikov”<> Copyright © 2000-2011 Softjourn, Inc. All rights reserved