EISA Considerations for Web Application Security


Published on

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
  • \n
  • We are using the term “enterprise” here loosely, the same principles apply to small and medium sized businesses or organizations.\n
  • \n
  • My paper gave a general overview of the various attack vectors to show how prevalent web application security vulnerabilities are.\n
  • If security is integrated into each phase of the development process, then threat modeling is introduced in the requirements phase of the development cycle. This is logical since the results will influence coding and testing of the web application.\n
  • \n
  • Perhaps a figure that can be provided to management.\n
  • Some advocate having the manual code review performed by pairs of programmers/web developers \n
  • The test code remaining in production source is one that when I first read it, I thought, oh I’d never be that careless. But since then I’ve worked on a large, complex administrative back end for a site, and on final review before posting changes, I sometimes find test code that needs to be commented out or removed.\n
  • I’m not really going to go into any detail about any commercial solutions except to say that they are out there and may be an alternative tool for security analysis.\n
  • \n
  • EISA Considerations for Web Application Security

    1. 1. Information Security for aWeb-based Business Process A proposal for the appropriate tools for detection andprevention of security vulnerabilities within an enterprise information systems architecture for a given business process.
    2. 2. Profiling • Web Platform – the web server the application runs on and/or the language the application was written in • Web Authentication – password, multifactor (reCAPTCHA), online authentication (e.g. WIndows Live ID) • Web Authorization – attacking the web application’s access controls through advanced session analysis, hijacking, and fixation techniques • Input Injection Attacks – XSS, SQL injection, buffer overflows • XML Web Services – WSDL disclosure, input injection, external entity injection, and XPath injection • Web Application Management – “attacks against remote server management, web content management/authoring, admin misconfigurations, and developer-driven mistakes.” • Web Client – exploits in the web browser itself.
    3. 3. Specific Attacks OWASP Top Ten for 2010 1. Injection 2. Cross-Site Scripting (XSS) 3. Broken Authentication and Session Management 4. Insecure Direct Object References 5. Cross-Site Request Forgery (CSRF) 6. Security Misconfiguration 7. Insecure Cryptographic Storgage 8. Failure to Restrict URL Access 9. Insufficient Transport Layer Protection 10. Unvalidated Redirects and Forwards Being aware of the common exploits (even older ones), as well as securing the operating system and web server is essential.
    4. 4. Threat Modeling Threat modeling is one of the most critical steps you can take to improve the security of your web applications (Scambray, 2010). Threat modeling should be used during the development and requirements phase of design – the results will affect coding and testing of the application. “Threat modeling is the process of systematically deriving the key threats relevant to an application in order to efficiently identify and mitigate potential security weaknesses before releasing it” (Scambray, Liu & Sima, 2011).
    5. 5. Threat Modeling Asset identification (e.g., business logic, customer information, financial information) that is encompassed by the application, along with a data flow diagram to establish the flow of sensitive information through the application and associated systems aids in threat modeling. A major part of threat modeling is deconstructing the application in terms of security regions – authentication/authorization, logging, interface, privileges, etc. • Confidentiality, integrity, availability, and audit logging (CIAA) should be considered for each asset documented. • Microsoft’s STRIDE model – spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privileges is another helpful tool to think creatively regarding potential threats
    6. 6. Threat Modeling Threats are then documented and ranked based on the seriousness of the threat. Mitigations of threats would be implemented in the development process. Risk = Impact x Probability Where impact is expressed in financial terms – gives a hard estimate in dollars.
    7. 7. Code Review Mitigation of threats in the development phase • code review of components • implementation of countermeasures Manual code review is the best, but the costliest in terms of time. Critical components that qualify for a manual code review include: • Modules that perform data sanitization and interact with databases • Authentication components • Authorization and session management • Administration and user management • Error and exception handling • Cryptographic modules • Code running with excessive privileges • Code running that crosses multiple security contexts • Client-side code that could be subject to debugging
    8. 8. Code Review Common security issues • Input handling • SQL statement formation • Storing secrets in code • Authorization/Session management • Test code remaining in production code release
    9. 9. Security Assessment Tools Sprajax is an FLOSS black box security scanner used to assess the security of AJAX-enabled applications – an OWASP Project MetaSploit – Simplifies network discovery and vulnerability verification, increasing the effectiveness of vulnerability scanners such as Nexpose. Nessus 5 – the most widely-deployed vulnerability and configuration assessment product worldwide There are also many commercial web application security scanning programs available, such as HP WebInspect, IBM AppScan, Cenzic Hailstorm, and NTObjectives NTOSpider. Some organizations such as WhiteHat Security and HP SaaS Application Security Center will scan your application and report the results to you as well.
    10. 10. References MetaSploit. (2012). MetaSploit penetration testing software. Retrieved February 15, 2012 from http://www.metasploit.com/ Nessus. (2012). Nessus 5.0 is here. Retrieved February 15, 2012 from http://www.nessus.org/products/nessus Open Web Application Security Project. (2011). Main Page - OWASP. Retrieved November 30, 2011 from https://www.owasp.org/ index.php/Main_Page Scambray, J., Liu, V., & Sima, C. (2011). Hacking exposed web applications: web application security secrets and solutions. [Kindle Edition Version]. Chicago: McGraw Hill. xkcd. (2011). Exploits of a mom. Retrieved February 15, 2012 from http://xkcd.com/327/