OWASP. Application Security Awareness OWASP. The OWASP Foundation

OWASP Application Security Awareness OWASP September 16th 2010 Martin Knobloch OWASP Netherland Chapter Leader OWASP Global Education Committee OWA...
0 downloads 2 Views 4MB Size
OWASP Application Security Awareness

OWASP

September 16th 2010

Martin Knobloch OWASP Netherland Chapter Leader OWASP Global Education Committee OWASP Global Connection Committee Sogeti Netherlands B.V. [email protected] +31-6 52 32 76 79 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation http://www.owasp.org

Agenda What is OWASP? Secure Application

 OWASP Top Ten OWASP near you

OWASP

OWASP Mission

to make application security "visible," so that people and organizations can make informed decisions about application security risks

OWASP

3

OWASP World

OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security visible so that people and organizations can make informed decisions about application security risks.

Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the ongoing availability and support for our work.

OWASP

www.owasp.org

OWASP

5

5

OWASP Resources and Community Documentation (Wiki and Books) • Code Review, Testing, Building, Legal, more …

Code Projects • Defensive, Offensive (Test tools), Education, Process, more …

Chapters • Over 100 and growing

Conferences • Major and minor events all around the world OWASP

2009 OWASP Supporters

OWASP

The Wisdom of Crowds Diversity of opinion Decentralization Aggregation Independence

OWASP

8

OWASP Worldwide Community Participants 25000 20000 15000 10000 5000 0

Chapters 160 140 120 100 80 60 40 20 0

OWASP

9

OWASP Dashboard Worldwide Users

Most New Visitors

250

22,782,709 page views

200 150 100 50

0 1-10-2002

1-10-2003

1-10-2004

1-10-2005

1-10-2006

1-10-2007

OWASP

10

OWASP Conferences (2008-2009)

Minnesota Oct 2008 Denver Spring 2009

NYC Sep 2008 DC Sep 2009

Brussels May 2008

Germany Nov 2008 Poland May 2009

Ireland 2009 Portugal Summit Nov 2008

Israel Sep 2008

India Aug 2008

Taiwan Oct 2008

Gold Coast Feb 2008 +2009

OWASP

11

OWASP Projects Are Alive!

2009



2007

2005 2003 2001

OWASP

12

Web Server Hardened OS Firewall

Firewall

Network Layer

App Server

You can’t use network layer protection (firewall, SSL, IDS, hardening) to stop or detect application layer attacks OWASP

Billing

Human Resrcs

Directories

APPLICATION ATTACK

Web Services

Custom Developed Application Code

Legacy Systems

Your security “perimeter” has huge holes at the application layer Databases

Application Layer

Security Perimeter

What is Web Application Security? Not Network Security Securing the “custom code” that drives a web application Securing libraries Securing backend systems Securing web and application servers

Network Security Mostly Ignores the Contents of HTTP Traffic Firewalls, SSL, Intrusion Detection Systems, Operating System Hardening, Database Hardening OWASP

Tools – At Best 45%  MITRE found that all application security tool vendors‟ claims put together cover only 45% of the known vulnerability types (695)  They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true)

OWASP

OWASP Top Ten Critical Vulnerabilities

OWASP

16

OWASP Projects Lifecycle  Define Criteria for Quality Levels  Alpha, Beta, Release

 Encourage Increased Quality  Through Season of Code Funding and Support  Produce Professional OWASP books

 Provide Support  Full time executive director (Kate Hartmann)  Full time project manager (Paulo Coimbra)  Half time technical editor (Kirsten Sitnick)  Half time financial support (Alison Shrader)  Looking to add programmers (Interns and professionals) OWASP

OWASP Live CD

OWASP

18

Want More OWASP?                         

OWASP .NET Project OWASP ASDR Project OWASP AntiSamy Project OWASP AppSec FAQ Project OWASP Application Security Assessment Standards Project OWASP Application Security Metrics Project OWASP Application Security Requirements Project OWASP CAL9000 Project OWASP CLASP Project OWASP CSRFGuard Project OWASP CSRFTester Project OWASP Career Development Project OWASP Certification Criteria Project OWASP Certification Project OWASP Code Review Project OWASP Communications Project OWASP DirBuster Project OWASP Education Project OWASP Encoding Project OWASP Enterprise Security API OWASP Flash Security Project OWASP Guide Project OWASP Honeycomb Project OWASP Insecure Web App Project OWASP Interceptor Project

                       

OWASP JBroFuzz OWASP Java Project OWASP LAPSE Project OWASP Legal Project OWASP Live CD Project OWASP Logging Project OWASP Orizon Project OWASP PHP Project OWASP Pantera Web Assessment Studio Project OWASP SASAP Project OWASP SQLiX Project OWASP SWAAT Project OWASP Sprajax Project OWASP Testing Project OWASP Tools Project OWASP Top Ten Project OWASP Validation Project OWASP WASS Project OWASP WSFuzzer Project OWASP Web Services Security Project OWASP WebGoat Project OWASP WebScarab Project OWASP XML Security Gateway Evaluation Criteria Project OWASP on the Move Project

OWASP

19

Part of the ‘Big 4’

Building Guide

Code Review Guide

Testing Guide

Application Security Desk Reference (ASDR)

OWASP

The Building Guide Free and open source Gnu Free Doc License

Most platforms Examples are J2EE, ASP.NET, and PHP

Comprehensive Thread Modeling Advise & Best Practices Web Services Key AppSec Area‟s:  Authorization/Authentication  Session Management  Data Validation

OWASP

21

Secure Code Review Guide  What it is :

 What it isn't:

 Examination of developed source code for quality.

 Silver Bullet

 Security = Quality  Robust & Stable code

 Replacement for poor application development

 More Expensive

 Easy

 Can be more Accurate

 Cheap (Not Manual anyways)

 Requires unique skill set to do properly

 Replacement for other security controls

OWASP

OWASP

OWASP Code review tools Code Crawler: Alessio Marziali

Paulo Prego Orizon Framework

OWASP

Testing Guide v3: Index 1. Frontispiece

2. Introduction 3. The OWASP Testing Framework 4. Web Application Penetration Testing

5. Writing Reports: value the real risk Appendix A: Testing Tools Appendix B: Suggested Reading Appendix C: Fuzz Vectors Appendix D: Encoded Injection OWASP

What’s new?  V2 8 sub-categories (for a total amount of 48 controls)  V3 10 sub-categories (for a total amount of 66 controls)  36 new articles!

Information Gathering Business Logic Testing Authentication Testing Session Management Testing Data Validation Testing Denial of Service Testing Web Services Testing Ajax Testing

Information Gathering Config. Management Testing Business Logic Testing Authentication Testing Authorization Testing Session Management Testing Data Validation Testing Denial of Service Testing Web Services Testing Ajax Testing Encoded Appendix

OWASP

SDLC & OWASP Guidelines

OWASP Framework

OWASP

27

CLASP  Comprehensive, Lightweight Application Security Process Centered around 7 AppSec Best Practices Cover the entire software lifecycle (not just development)  Adaptable to any development process

Defines roles across the SDLC 24 role-based process components Start small and dial-in to your needs

OWASP

OWASP Tools and Technology

OWASP

29

Part of the ‘Big 4 +1’ ASVS

Building Guide

Code Review Guide

Testing Guide

Application Security Desk Reference (ASDR) OWASP

OWASP Application Security Verification Std Standard for verifying the security of web applications

Four levels Automated Manual Architecture Internal

OWASP

31

Coverage Depth – Level of Rigor

No malicious developers



The design has to be right The controls have to be right

 

Scan

 Breadth – Number of Requirements

OWASP

What does the ASVS look like?  “Verification Levels” section  “Detailed Verification Requirements” section  “Verification Reporting Requirements” section

OWASP

What are ASVS verification levels?

OWASP

Levels in more detail Level 1 – Automated Verification – Level 1A – Dynamic Scans (Partial Automated Verification) – Level 1B – Source Code Scans (Partial Automated Verification)

Level 2 – Manual Verification – Level 2A – Manual Pentesting (Partial Manual Verification) – Level 2B – Manual Source Code Review (Partial Manual Verification)

Level 3 – Design Verification Level 4 – Internal Verification

OWASP

Earning a level… Security control behavior

Security control use

• Is the control designed right? • Is the control used right?

Security control implementation

• Is the control implemented right?

Security control verification

• What do you have to do to verify the control?

Documentation

• How do you have to write it up?

OWASP

Level 1 in more detail Automated verification of a web application or web service treated as groups of components within single monolithic entity.

OWASP

Application Security Verification Techniques Find Vulnerabilities Using the Running Application

Find Vulnerabilities Using the Source Code

Manual Application Penetration Testing

Manual Security Code Review

Automated Application Vulnerability Scanning

Automated Static Code Analysis

OWASP

Appliaction Security Verification Standaard 5

Manual Security Code Review (Specialist)

4 3

Auto Source Code Review (Tool)

1

2

External App Scan (Tool)

Threat Analysis & Architecture Review (Analyst)

0

(Defined by Business)

Business Criticality (Impact of Loss)

Manual Penetration Testing (Specialist)

0

1

2

3

4

5

Expected Security Assurance (Assessment Depth – Expected Level of Security) (Defined by Corporate Security)

OWASP

39

3

AL6 AL5

2

AL4 AL2

1

(Defined by Business)

Business Criticality

4

5

Appliaction Security Verification Standaard

AL3

0

AL1 0

1

2

3

Expected Security Assurance

4

5

(Defined by Corporate Security)

 AL1: Architecture Review/Threat Analysis - Design level review to identify critical assets, sensitive data stores and business critical interconnections. In addition to architecture reviews is threat analysis to determine potential attack vectors, which could be used in testing.  AL2: Quick Hit Application Security Check - Automated scans (either external vulnerability scan or code scan or both) with minimal interpretation and verification.  AL3: Basic Application Security Check – AL2 + verification and validation of scan results. Security areas not scanned (encryption, access control, etc.) must be lightly tested or code reviewed. OWASP

40

3

AL6 AL5

2

AL4 AL2

1

(Defined by Business)

Business Criticality

4

5

Appliaction Security Verification Standaard

AL3

0

AL1 0

1

2

3

Expected Security Assurance

4

5

(Defined by Corporate Security)

 AL4: Standard Application Security Verification – AL3 + verification of common security mechanisms and common vulnerabilities using either manual penetration testing or code review or both. Not all instances of problems found - Sampling allowed.  AL5: Enhanced Application Security Verification – AL1 + AL3 + verification of all security mechanisms and vulnerabilities based on threat analysis model using either manual penetration testing or code review or both.  AL6: Comprehensive Application Security Verification – AL1 + AL4 + search for malicious code. All code must be manually reviewed against a standard and all security mechanisms tested. OWASP

41

SAMM Business Functions Start with the core activities tied to any organization performing software development Named generically, but should resonate with any developer or manager

OWASP

SAMM Security Practices From each of the Business Functions, 3 Security Practices are defined The Security Practices cover all areas relevant to software security assurance Each one is a „silo‟ for improvement

OWASP

Under each Security Practice Three successive Objectives under each Practice define how it can be improved over time This establishes a notion of a Level at which an organization fulfills a given Practice

The three Levels for a Practice generally correspond to: (0: Implicit starting point with the Practice unfulfilled) 1: Initial understanding and ad hoc provision of the Practice 2: Increase efficiency and/or effectiveness of the Practice 3: Comprehensive mastery of the Practice at OWASP scale

Check out this one...

OWASP

Per Level, SAMM defines... Objective Activities Results Success Metrics Costs Personnel Related Levels

OWASP

Approach to iterative improvement Since the twelve Practices are each a maturity area, the successive Objectives represent the “building blocks” for any assurance program

Simply put, improve an assurance program in phases by: Select security Practices to improve in next phase of assurance program Achieve the next Objective in each Practice by performing the corresponding Activities at the specified Success Metrics OWASP

Applying the model

OWASP

Conducting assessments SAMM includes assessment worksheets for each Security Practice

OWASP

Assessment process Supports both lightweight and detailed assessments Organizations may fall in between levels (+)

OWASP

Creating Scorecards Gap analysis Capturing scores from detailed assessments versus expected performance levels

Demonstrating improvement Capturing scores from before and after an iteration of assurance program build-out

Ongoing measurement Capturing scores over consistent time frames for an assurance program that is already in place OWASP

Roadmap templates  To make the “building blocks” usable, SAMM defines Roadmaps templates for typical kinds of organizations  Independent Software Vendors  Online Service Providers  Financial Services Organizations  Government Organizations

 Organization types chosen because  They represent common use-cases  Each organization has variations in typical software-induced risk  Optimal creation of an assurance program is different for each OWASP

Building Assurance Programs

OWASP

Case Studies A full walkthrough with prose explanations of decision-making as an organization improves Each Phase described in detail Organizational constraints Build/buy choices

One case study exists today, several more in progress using industry partners

OWASP

SAMM Business Functions Start with the core activities tied to any organization performing software development Named generically, but should resonate with any developer or manager OWASP

SAMM Security Practices  From each of the Business Functions, 3 Security Practices are defined

 The Security Practices cover all areas relevant to software security assurance  Each one is a „silo‟ for improvement

OWASP

OWASP Software Assurance Maturity Model

OWASP

57

Agenda What is OWASP? Secure Application

 OWASP Top Ten OWASP near you

OWASP

Ultimate Security?!?

OWASP

What is secure Software? An application is secure if it acts and reacts, as it expected, at any time! Functional

Technical

Specification

Implementation

Secure Insecure?

Insecure? OWASP

Applications over time The environments in where the software applications run where closed. • By this, the applications could be developed ‘open’.

OWASP

Applications over time The environments in where the software applications run where closed. • By this, the applications could be developed ‘open’. The environments became more open over time.

OWASP

Applications over time The environments in where the software applications run where closed. • By this, the applications could be developed ‘open’. The environments became more open over time.  What means, the applications have to become more closed.

OWASP

Security Design & Architectuur

OWASP

Ultimate Security?!?

OWASP

The problem: Cookies, HTTP authentication, SLL.. Low learning curve Easy to attack (web) applications

OWASP

OWASP Top 10 2007  A1 - Cross Site Scripting (XSS)

        

A2 - Injection Flaws A3 - Malicious File Execution A4 - Insecure Direct Object Reference A5 - Cross Site Request Forgery (CSRF) A6 - Information Leakage & Improper Error Handling A7 - Broken Authentication & Session Management A8 - Insecure Cryptographic Storage A9 - Insecure Communications A10 - Failure to Restrict URL Access

OWASP

Where do attacks come from? Conscious!

Unconscious!

Cracker Hacker Scriptkiddie

• System • Environment • User

Risk=(

Threat * Vulnerability Countermeasures

)*Value OWASP

What is Software Security about? Applications are about information! 3 pillars of Information Security: Confidentiality Integrity

Availability

OWASP

Security Requirements? ‘Why’

N o n

F

Business requirements

u

n c

‘What’

f u n

t User requirements

i o

n a l

‘How’

c

Business rules

t i o

Constraints

n

a

System requirementsExternal

l

interfaces

OWASP

What is Software Security about? Who..

(the user) in what role?

Where..

thus, with what rights?

..in which process..

..may do..

..on what data? OWASP

Where ‘is’ Software Security?

OWASP

Software Architectuur?

OWASP

Security Development Lifecycles Microsoft SDL

Touchpoints

CLASP OWASP

Summary > Applications are about information > Confidentiality, Integrity & Availability > Explicit security requirements > Make security verifiable! > Security in depth > Security considered through the whole application > Propagation of credentials > Security by default > Who may do what?

More code = more bugs! OWASP

Any questions so far?

OWASP

Agenda What is OWASP Secure Application

 OWASP Top Ten OWASP near you

OWASP

OWASP Top Ten Critical Vulnerabilities

OWASP

78

A1 Cross-Site Scripting (XSS)

OWASP

A1 Cross-Site Scripting (XSS)

Unsafe content is stored in the dynamic part of the web content? 1. Unsafe content is retrieved from the database 2. That unsafe content becomes part of the site 3. The servers sends the response to the client 4. The client receives and interprets the received content. 5. The unsafe content (e.g. a script) causes the browser to send an request to another, unsafe, site! OWASP

A2 Injection Flaws

OWASP

A2 Injection Flaws – SQL injection Screen: USERNAME:[Admin] PASSWORD:[Secret01]

Server: Access if: the username is „Admin‟ & and the password is „Secret01'; OWASP

A2 Injection Flaws – SQL injection Screen: USERNAME:[Admin] PASSWORD:[Secret01 OR 1 = 1]

Server: Access if: the username is „Admin‟ & and the password is „Secret01‟ OR 1 = 1; OWASP

A2 Injection Flaws – SQL injection Screen: USERNAME:[Admin] PASSWORD:[Secret01 OR 1 = 1]

Server: Access if: the username is „Admin‟ & and the password is „whatever‟ OR 1 = 1; OWASP

A3 Malicious File Execution

OWASP

A4 Insecure Direct Object Reference

OWASP

A5 Cross-site Request Forgery (XSRF)

OWASP

A6 Information Leakage / Improper Error Handling

OWASP

A8 Insecure Cryptographic Storage

OWASP

A9 Insecure Communication

OWASP

A10 Failure to Restrict URL Access

OWASP

Agenda What is OWASP? Secure Application

 OWASP Top Ten OWASP near you

OWASP

Subscribe to Chapter mailing list Post your (Web)AppSec questions Keep up to date! Get monthly news letters Contribute to discussions!

OWASP

93

That’s it… http://www.owasp.org http://www.owasp.org/index.php/London

http://www.owasp.org/index.php/Leeds_UK

[email protected] Thank you! OWASP

94

Suggest Documents