Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

OWASP Plan - Strawman.ppt

VIEWS: 12 PAGES: 21

									                      Detecting Web Application
                      Vulnerabilities Using Open
                      Source Means

                                  Konstantinos Papapanagiotou
                                  Committee Member
                                  OWASP Greek Chapter
                                  conpap@owasp.gr
OWASP
3rd Free / Libre / Open Source
Software (FLOSS) Conference
27/5/2008                  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
What is OWASP?

The Open Web Application Security Project
Worldwide, free and open community
Mission: improve application software security
  Information and awareness
      Documentation
      Guidelines
      Forums, mailing lists, conferences, local chapters
  Practical aspects
      Open Source Tools
Non-profit, charitable organization
  Members: VISA, Deloitte, Unisys, Foundstone, …
                                                            OWASP   2
The Greek Chapter

Created in 2005 but active since early 2007
Mission: raise security awareness in Greece
Activities:
  Translation of OWASP documentation
  Mailing list
  Monthly newsletter
  Participation in working groups and conferences
  Software tools: Web Vulnerability Scanner
~60 members
http://www.owasp.gr
Soon: http://blog.owasp.gr                   OWASP   3
Outline

Motivation: The need for web security
  Terminology
OWASP Top10: 10 most important vulnerabilities
Detection Tools
  OWASP Web Scarab
  WVS (Web Vulnerability Scanner)
Conclusions




                                         OWASP    4
Web Security

Rapid growth of the Internet in the last 2-3
 years
  Increase of population and bandwidth
  Dynamic web sites
Hacker trends have changed
  Used to be: viruses, worms, defacements
  Now: phishing, zombie networks, web application
   security
Weakest links
  End-users
  Developers
                                             OWASP   5
Web Application Vulnerabilities

Some vocabulary
  Threats
  Vulnerabilities
  Exploits
  Attacks
  Patching…
Web Applications: new category of applications
  Widely available
  Can access local resources
New code – old code
                                        OWASP     6
Tackling the problem

Security is not a one-off project
Secure Development Lifecycle:
  1.   Getting informed, raise awareness
  2.   Secure design and implementation
  3.   Product Launch
  4.   Vulnerability detection
  5.   Patching
  6.   Monitoring
  7.   Keep the track
Not a end-user or developer only matter
                                           OWASP   7
Step 1: Awareness - The OWASP Top 10

Document that lists the 10 most important web
 vulnerabilities
Aim: educate developers, designers, architects
 and organizations about the consequences of
 the most common web application security
 vulnerabilities.
Provides:
  Brief description
  basic methods for protection
2007: second version
                                        OWASP     8
The Vulnerabilities

A1 - Cross Site Scripting (XSS)
  User supplied data are sent to web browser without
   validating or encoding that content.
  Result: can allow script execution that can lead to
   user sessions hijacking, web site defacement, etc.
A2 - Injection Flaws (e.g. SQL injection)
  User supplied data are sent to an interpreter as part
   of a command or query.
  Result: the interpreter is tricked into executing
   unintended commands or changing data.


                                                OWASP      9
The Vulnerabilities (2)

A3 - Malicious File Execution (e.g. remote file
 inclusion (RFI)
  Can allow attackers to include hostile code and data
  Result: up to total server compromise.
  Target: PHP, XML and any framework which accepts
   filenames or files from users.
A4 - Insecure Direct Object Reference
  Reference to an internal implementation object (file,
   directory, database record, key, etc) as a URL or form
   parameter is accidentally exposed by the developer.
  Result: Attackers can manipulate those references to
   access other objects without authorization.
                                               OWASP        10
The Vulnerabilities (3)

A5 - Cross Site Request Forgery (CSRF)
  Forces a logged-on victim's browser to send a pre-
   authenticated request to a vulnerable web
   application, which then forces the victim's browser to
   perform a hostile action to the benefit of the attacker.
A6 - Information Leakage and Improper Error
 Handling
  Unintentional leak of information regarding
   configuration, internal workings, or privacy violation
  Result: Attackers use this weakness to steal sensitive
   data, or conduct more serious attacks.

                                                 OWASP        11
The Vulnerabilities (4)

A7 - Broken Authentication and Session
 Management
  Account credentials and session tokens are often not
   properly protected.
  Result: Attackers compromise passwords, keys, or
   authentication tokens to assume other users'
   identities.
A8 - Insecure Cryptographic Storage
  Web applications rarely use cryptographic functions
   properly to protect data and credentials.
  Result: can lead to identity theft, credit card fraud,
   etc.
                                                 OWASP      12
The Vulnerabilities (5)

A9 - Insecure Communications
  Applications frequently fail to encrypt network traffic
   when it is necessary to protect sensitive
   communications.
A10 - Failure to Restrict URL Access
  Frequently, an application only protects sensitive
   functionality by preventing the display of links or
   URLs to unauthorized users.
  Result: Attackers can use this weakness to access
   and perform unauthorized operations by accessing
   those URLs directly.

                                                 OWASP       13
Step 2: Detection – OWASP WebScarab

Framework for analysing applications that
 communicate using HTTP and HTTPS.
Written in Java for portability
Operates as an intercepting proxy
  The operator can review and modify requests created
   by the browser before they are sent to the server
  He can also review and modify responses returned
   from the server before they are received by the
   browser.
Several modes of operation and plugins

                                             OWASP       14
Step 2: Detection – OWASP WebScarab (2)

Target Groups:
  Developers can debug otherwise difficult problems
  Security specialists can identify vulnerabilities in the
   way that the application has been designed or
   implemented.
http://www.owasp.org/index.php/Category:OWA
 SP_WebScarab_Project
Under Development: OWASP Web Scarab Next
 Generation
  Complete rewrite
  New user interface
                                                   OWASP      15
Step 2: Detection – WVS

Web Vulnerability Scanner
Started off as a university student project
Goal: test a web site or application (not the
 server in the back end)
Target group: security specialists, penetration
 testers, developers
Functional but still under development
Beta version at: http://www.owasp.gr
(http://www.owasp.org/images/6/65/WVS_beta-0.2.1.zip)


                                             OWASP      16
WVS – Design and Implementation

Three tier architecture:
  Vulnerability database
      SQLite
      Data retrieval API
      Update API
  Communication API
      Communication with server (GET, POST, etc)
  Presentation Level
      Plaintext output, graphical interface, html, etc
Multi-threaded
  User-specified

                                                          OWASP   17
WVS – Advantages

Less false negatives
  “Paranoid scanning”
      User-enabled
      Retrieves the site’s structure
      Makes all possible checks in the entire site
Less false positives
  Static sites: MD5 hash checking
  Future work: dynamic sites
Portability
  Use of open and portable technologies (SQLite,
   libcurl, etc)
  Future work: POSIX threads                 OWASP   18
WVS – Future Work

Eliminate false positives in dynamic sites
Enhance Portability
  POSIX threads
  Java implementation (?)
Sophisticated checks for XSS and SQL injection
Fuzzing algorithms
Other suggestions…




                                              OWASP   19
Conclusions

Web Application Security is a continuous process
Developers
  have the skills
  Are not always well informed
Organizations
  Follow deadlines
  Worry about security after release
End users
  Low awareness
OWASP
  Continuous effort to raise awareness   OWASP     20
      Q&A




http://www.owasp.gr
http://www.owasp.org
                       OWASP   21

								
To top