1. By: Razieh Rezaei Saleh

2.  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.  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.  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. 5 Product Requirem ents Functio nal Design Techni cal Design Implementati on Testi ng Beta Release Cycle Security Requiremen ts Document Architectu ral Risk Analysis Security Tollgates Securi ty Testin g Secure Coding

6.  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.  There are two approaches for security test: ▪ Manual approach ▪ Penetration test ▪ Code review ▪ Automated approach ▪ Vulnerability scanners ▪ Static analyzers

8. Scanning Web Application Categorizing Found Vulnerabilities Measuring Metrics Weighting Metrics Evaluating Security of Application Identifying Application’s Security Level

9.  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. 10

11.  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.  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. 13 Logical Flaws Security vulnerabilities that arise with some contextual logic in application. Example: Multi step procedure that can be bypassed with direct invocation Technical vs. Logical Vulnerabilities at WhiteHat

14.  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.  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.  Each application may need different level of security.  Leveling helps better comparison of system.

17.  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.  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.  Acunetix  Nmap  Nikto  Burp Suit  W3AF  Web Scarab  Web Inspect  Wikto  …..

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

21. Selected web application vulnerabilities from OWASP top ten for evaluation: 1. Cross Site Scripting (XSS) 2. Injection Flaws 3. Malicious File Execution 4. Insecure Direct Object Reference 5. Cross Site Request Forgery (CSRF) 6. Information Leakage and Improper Error Handling 7. Insecure Communications 8. Failure to Restrict URL Access

22.  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’ 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.  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.  Not all metrics have the same importance to the security of application.  Using CVSS score for weighting.  Using OWASP risk assessment approach.

26.  CVSS is composed of three metric groups: Represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments. 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.

27.  When the base metrics are assigned values, the base equation calculates a score ranging from 0 to 10

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

29. V 4.4. Verify that direct object references are protected, such that only authorized objects are accessible to each user. Insecure Direct Object Reference

30. V 8.1. Verify that that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id and personal information. Information Leakage and Improper Error Handling

31. V 5.2. Verify that a positive validation pattern is defined and applied to all input. V 5.3. Verify that all input validation failures result in input rejection or input sanitization. Injection Flows

32.  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.