1 / 33

A Framework for Automated Web Application Security Evaluation

By: Razieh Rezaei Saleh. A Framework for Automated Web Application Security Evaluation. Security Evaluation. Security Evaluation The examination of a system to determine its degree of compliance with a stated security model, security standard, or specification.

val
Download Presentation

A Framework for Automated Web Application Security Evaluation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. By: Razieh Rezaei Saleh A Framework for Automated Web Application Security Evaluation

  2. Security Evaluation • Security Evaluation The examination of a system to determine its degree of compliance with a stated security model, security standard, or specification. • The evaluation may be conducted • (a) by analyzing the detailed design, especially of the software, often using verification and validation, • (b) by observing the functional behavior of the system, or • (c) by attempting to penetrate the system using techniques available to an “attacker”.

  3. Security Testing • The Process to determine that an IS (Information System) protects data and maintains functionality as intended. • The six basic security concepts that need to be covered by security testing are: • Confidentiality • Integrity • Authentication • Authorization • Availability • non-repudiation

  4. Vulnerability • the word vulnerability refers to a weakness in a system allowing an attacker to violate the security of the system or the data and applications it hosts. • Vulnerabilities may result from bugs or design flaws in the system. • A vulnerability can exist either only in theory, or could have a known exploit.

  5. Release Cycle Security Tollgates in Software Development Life Cycle (SDLC) Product Requirements Functional Design Technical Design Implementation Testing Beta Security Tollgates Architectural Risk Analysis Security Requirements Document Secure Coding Security Testing

  6. Security testing tools • There is eight security tool categories: • source code analyzers, • web application (black-box) scanners, • database scanners, • binary analysis tools, • runtime analysis tools, • configuration management tools, • HTTP proxies, • miscellaneous tools.

  7. Types of Web Application Security Test • There are two approaches for security test: • Manual approach • Penetration test • Code review • Automated approach • Vulnerability scanners • Static analyzers

  8. A Framework for Automated Web Application Security Evaluation

  9. Why Web Application? • Because of globalization of web and being of internet as the major tool for international information exchange, security of web application is becoming more and more important. • Web applications are very much vulnerable to DOS attacks or security and access compromise.

  10. Why Web Application? "70% of today's successful hacks involve Web Application attacks " SPI Dynamics

  11. Why Automated? • Automated testing tools are vital because of growth in web application’s extension and complication. • Manual penetration testing and automated scanning are used to find security vulnerabilities in Web applications. • Each has inherent strengths and weaknesses.

  12. Why Automated? • Web application vulnerabilities’ categories: • Technical vulnerabilities • cross-site scripting (XSS), injection faws and buffer overflows. • Logical vulnerabilities • Logical vulnerabilities are security weaknesses that can be exploited by circumventing the typical flow of an application.

  13. Technical vs. Logical Vulnerabilities • Logical Flaws • Security vulnerabilities that arise with somecontextual logic in application. • Example: • Multi step procedure that can be bypassed with direct invocation Technical vs. Logical Vulnerabilities at WhiteHat

  14. Automated Tools • Strength: saving time and money • Weakness: false positive and false negative • As automated Web application security testing tools have matured, enterprises have experienced fewer incidents of false positives and false negatives.

  15. Why Black box? • Efficient when used on Larger systems • The environment the program is running is also tested. • The invested effort can be used multiple times. (regression testing) • Tests will be done from a hacker's point of view. • There is no need of having detailed functional knowledge of system to the tester. • As the tester and developer are independent of each other, test is balanced and unprejudiced • Tester can be non-technical.

  16. Why Leveling? • Each application may need different level of security. • Leveling helps better comparison of system.

  17. Scanning web application • Two categories of automated security tool: • Static: • Analyzes the source code for security defects • Known as white box security test • Needs source code • Dynamic: • Elicits vulnerabilities by sending malicious requests, and investigating replies • When source code is not available • Tester looks at the application from the attacker’s perspective • Analyzes only applications deployed in test or production environments

  18. Scanning web application • Uses vulnerability scanners to find security vulnerabilities. • In an automated security test, there are three fundamental steps: • Discovering new URLs and forms by crawling • Creating test script with crafted data • Sending malicious request to the web application • Analyzing response to detecting vulnerabilities

  19. Most Powerful Scanners • Acunetix • Nmap • Nikto • Burp Suit • W3AF • Web Scarab • Web Inspect • Wikto • …..

  20. Categorizing Found Vulnerabilities OWASP top ten vulnerabilities: • Cross Site Scripting (XSS) • Injection Flaws • Malicious File Execution • Insecure Direct Object Reference • Cross Site Request Forgery (CSRF) • Information Leakage and Improper Error Handling • Broken Authentication and Session Management • Insecure Cryptographic Storage • Insecure Communications • Failure to Restrict URL Access Open Web Application Security Project (OWASP)- The ten most critical web application security vulnerabilities,2007

  21. Measuring Metrics Selected web application vulnerabilities from OWASP top ten for evaluation: • Cross Site Scripting (XSS) • Injection Flaws • Malicious File Execution • Insecure Direct Object Reference • Cross Site Request Forgery (CSRF) • Information Leakage and Improper Error Handling • Insecure Communications • Failure to Restrict URL Access

  22. Application Security Verification Standard • The ASVS defines four level of verification that increase in both breadth and depth. • The breadth is defined in each level by set of security requirements that must be addressed. • The depth of verification is defined by the approach and level of rigor required in verifying each security requirement. • Has a close resemblance to ISO-IEC 18045, but customized for web application. OWASP- Application Security Verification Standard (ASVS),2009

  23. ASVS levels • ASVS’ four level of verification: • Level 1: Automated Verification • 1A: Dynamic Scan • 1B: Source Code Scan • Level 2: Manual Verification • Level 3: Design Verification • Level 4:Internal Verification

  24. Some requirement of level 1A • Verify that all pages and resources require authentication except those specifically intended to be public. • Verify that all password fields do not echo the user’s password when it is entered, and that password fields (or the forms that contain them) have autocomplete disabled. • Verify that if a maximum number of authentication attempts is exceeded, the account is locked for a period of time long enough to deter brute force attacks. • Verify that sessions are invalidated when the user logs out. • Verify that sessions timeout after a specified period of inactivity. • ….

  25. Weighting Metrics • Not all metrics have the same importance to the security of application. • Using CVSS score for weighting. • Using OWASP risk assessment approach.

  26. Common Vulnerability Scoring System (CVSS) • CVSS is composed of three metric groups: Represents the characteristics of a vulnerability that change over time but not among user environments. Represents the characteristics of a vulnerability that are relevant and unique to a particular user’s environment. Represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments.

  27. Common Vulnerability Scoring System (CVSS) • When the base metrics are assigned values, the base equation calculates a score ranging from 0 to 10

  28. Calculated weights The result of calculating weight for each selected vulnerability is as below: • Cross Site Scripting (XSS): 4.3 • Injection Flaws: 7.1 • Malicious File Execution: 7.1 • Insecure Direct Object Reference: 6.8 • Cross Site Request Forgery (CSRF): 6.8 • Information Leakage and Improper Error Handling: 4.1 • Insecure Communications: 6.9 • Failure to Restrict URL Access: not assigned yet.

  29. Using ASVS

  30. Using ASVS

  31. Using ASVS

  32. Identifying Application’s Security Level • The security level of application can be specified according to the results of calculated metrics. • This level of security is with assurance of level 1A in ASVS.

  33. Thanks for your attention.

More Related