You are on page 1of 33

Testing & Code Review

Guides & Labrat (OWASP


Live CD)

Eoin Keary CISSP


OWASP Testing and Code Review Guides
Lead
OWASP Live CD Coordinator
OWASP Ireland Chapter Lead & Founder
OWAS
Rits Information Security (Ireland)
P Eoin.Keary@owasp.org
AppSe Copyright © 2006 - The OWASP Foundation

c
Permission is granted to copy, distribute and/or modify this document
under the terms of the Creative Commons Attribution-ShareAlike 2.5
License. To view this license, visit
Seattl http://creativecommons.org/licenses/by-sa/2.5/

e The OWASP
Oct 2006 http://www.owasp.org/
Foundation
Agenda
The OWASP Testing Guide

The OWASP Code review Guide

Labrat: OWASP Live! (Live CD)

OWASP AppSec Seattle 2006 2


About me…

Senior Security Consultant in Rits (Ireland).


www.ritsgroup.com

Testing Guide project Lead.

Code review Guide Project Lead.

OWASP Live CD Coordinator.

OWASP Ireland founder and Lead.

OWASP AppSec Seattle 2006 3


Introduction: Pen & Patch is
unavoidable.
The penetrate and patch approach (although unavoidable)
Is like Plastic surgery:

Happens after the fact.

Its expensive

It may not stand the test of


time.

OWASP AppSec Seattle 2006 4


Pen & Patch: Sustainable?
Applications are getting more complex as time goes on.

But so are attacks.

Q: Given such complexity of systems, can we continue to obtain @100% coverage?


– (In functional testing the consensus is no.)

A: Probably not; end-to-end security assessments are getting larger and larger.
– Time is a finite resource, in the business world. We can’t spend a week on,
say “session mgt”`.

How to solve this losing battle?

The applications need to be developed in a secure manner.

- Secure Design reviews


- Secure Code review – Manual & Automated.
- Unit/System/Integration testing to include security test cases

OWASP AppSec Seattle 2006 5


What is the Problem?
We have known these metrics for years….

IBM Labs: It’s 100 times more expensive to fix security vulnerabilities after
an application/system is deployed into production.

Integrated at the design phase, security is more effective and the total cost
of ownership (TCO) is less but it may take a little longer to develop (10%-
15%).

But the reality is…

60%, 70%, 80% of web applications contain security vulnerabilities.

Business drives technology and the pressure to produce product takes


precedence over security & quality.

Consumers are not aware of the issues or have no choice but to purchase.

There is no “NCAP” (New Car Assessment Programme) for software and


no real standards which to test by. OWASP AppSec Seattle 2006 6
What is the Problem…?

Is it technology, is this inherently insecure?

Is it we have based today’s technology on older technology which is not secure?


(HTTP is pretty old..)

Is it business forces pushing for the next big thing?

Or it could be

A Cultural issue……(methinks yes)

If you think technology can solve your security


problems, then you don't understand the problems
and you don't understand the technology.
-Bruce Schneier
OWASP AppSec Seattle 2006 7
Application Security Testing, What &
Why?
Given that….

•Interesting Statistics – Employing code review


– IBM Reduces 82% of Defects Before Testing Starts

– HP Found 80% of Defects Found Were Not Likely To Be Caught in


Testing

– 100 Times More Expensive to Fix Security Bug at Production Than


Design”
– IBM Systems Sciences Institute

– Improvement Earlier in SDLC makes sense.


– Fix at Right Place; the Source (logical thing to do)
– Takes 15 - 20% extra time – payoff is order of magnitude more.

… why are we so busy performing testing?


We shouldn’t be finding such “low hanging fruit”???

OWASP AppSec Seattle 2006 8


OWASP Testing Guide….Why?
The standard of information on application testing is very varied.
Google, blogs, security websites, hax0r sites.

The variance in different application architectures makes our job


Interesting.
- Rarely the same application architecture twice.
- Like being a mechanic but every car is different.

Technology moves so fast sometimes there is little information

Books go out of date, not just technology changes, but standards change!

The Industry embraces technology prior to defacto standards being defined and
agreed upon.

- How about a book written by everybody?


- Lets pool knowledge - The OWASP Guides…….

OWASP AppSec Seattle 2006 9


OWASP Testing Guide History
Started in 2002 by Mark Curphy. Taken over in 2003 by Daniel
Cuthbert (OWASP London). Taken over by me in 2005.
Currently undergoing a face-lift via the OWASP Autumn of Code.
(Tech Lead: Matteo Meucci )
It was:
Word document/pdf, downloadable.
Pretty popular, Very Good, Extensive
But….
Its now a little Old
Needs updating AJAX, JSF, XML/WS, WEB2.0…..
Needs to be More accessible
Better contribution model is required to keep it up to date.

OWASP AppSec Seattle 2006 10


OWASP Testing Guide
Being a consultant one can not choose what type of application one is faced
with when asked to perform an application assessment.
It may be a framework/language such as struts, .NET, or JSF, PHP….
Example:
AJAX or Web Services are now the "New" thing (using the same old stuff) but
how do we know what to look for when testing it?

Guide aims to be a global reference on Application security assessment.


It aims to be organic (Keep up-to-date)
Very accessible (WIKI)
Non-biased and free!

OWASP AppSec Seattle 2006 11


OWASP Testing Guide
The WIKI approach complements the Open approach (ala OWASP) wherein
anyone can contribute.

No one person can have all the answers and hence the app sec community can
team together and build a comprehensive guide to application penetration testing.

As technology evolves so will the guide, another reason for using a WIKI

Based on the learn by example approach.

Categorised by vulnerability

OWASP AppSec Seattle 2006 12


OWASP Testing Guide Contains
The Testing Guide Contains Information on the following:

The OWASP Testing Framework


- A typical testing framework that can be used within an
organisation to improve secure development.

Web Application Penetration Testing


- A large database of vulnerabilities to test for
and how to test them.

Report Writing:
- Covers how to tackle documenting issues discovered.

Also Covered:
Automated Testing & tools, references to other matieral

OWASP AppSec Seattle 2006 13


Testing Guide currently…
XSS:
incubated attacks.
Covers many aspects of application testing Phishing (using java script?)
But HTTP Methods
Much more to do…..
AJAX:
Information gathering: Vulnerabilities
Error codes: SQL, IIS/.NET Stack Trace (Java) How to test/what to look for.
Source code disclosure, SOAP faults
Automated testing.
Brute Force: Tools, how to's, references, tutorials.
Login forms. Fuzzing with webscarab
Basic Auth dialogues
WebServices: SQL Injection: Oracle, mySQL, SQL
Structural Attacks HTTP exploits
Server, TeraData
Content level attacks Extended stored procedures.
DTD based attacks Stored procedure injection
HTTP/REST attacks Oracle +SQLServer ports and
SOAP attachment attacks attacks. Listener attacks etc. 1521
Brute force 1433 1526
OWASP AppSec Seattle 2006 14
OWASP Testing Guide V2

The Guide is undergoing a facelift as part of the Autumn


of Code.

Due to be “completed” end of December.

Large team of motivated contributors.

Going well, so far…..

OWASP AppSec Seattle 2006 15


Structure .. going forward
We are aiming that the guide is focused on testing howto’s and less theory.
The OWASP site contains plenty of theory.

Envisioned as a reference NOT as a AppSec 101 training manual.

Structure of each section:

• Short Description of the Issue


• How to Test
• Black Box testing and example
• White Box testing and example
• References
• Whitepapers
• Tools

OWASP AppSec Seattle 2006 16


OWASP Testing Guide V2 Goals
The goals of the Autumn of Code for the testing guide:
Consolidate
More content to be added
Better quality control

Restructure
Less theory about testing but…
More examples
More pragmatic
More practical
More of a “guide”

OWASP AppSec Seattle 2006 17


When shall it be done?

Autumn of Code end date 31 Dec 2006

Stable release

Never really finished.

OWASP AppSec Seattle 2006 18


OWASP Code Review Guide
Code review Guide: “Security at Source”

Became a “splinter” guide to the Testing guide in 2005

It grew too big to be a chapter in the Testing guide.

Code Review and Testing are two distinct processes.

May/Should become more important in the future.

Secure Application Development (SAD) is (in my opinion) the most important


area of application security.

(Google Code Search may have great effect on


secure coding in the open source arena)
Try:
http://www.google.com/codesearch?q=package%3A%22login%22+%22String+password%22&btnG=Search+Code

OWASP AppSec Seattle 2006 19


Culture is the Issue, Not Technology
Buy a car: Safety + Security is a “Buying Factor”

Buy a door lock: Security is a factor

Buy software: Security, What?


“Of course we are secure”, “you need a UserId + Password”,
“We use encryption”
“We use SSL”

Why don’t dev orgs consider security as important as functionality?:


- Clients don’t demand it.
- No standard to which to compare
- The business:
“Security, we can’t see it”. “It does not generate revenue.”

-Why?

OWASP AppSec Seattle 2006 20


OWASP Code Review Guide

Guide tries to be a reference on “Where to start”

Guide assists in how to define a (SCR) Secure Code Review process.


Based on experience in industry.

Based on best practice secure application development.

OWASP AppSec Seattle 2006 21


OWASP Code Review Guide
The most effective application security is built as part of the application design.

All code has potential security vulnerabilities.

Code review guide is to assist code reviewers in the basics of reviewing:

Uses the “Learn by example” model

Process (People)-
Involve developers
Business buy-in – Paramount importance.
Culture of secure development (Very important)
Information gathering – We need context.

Pitfalls (People) –
Information and context issues
“Half-baked” code – Context of code?
Baselined code
Not auditors, but a helpful resource. – “help me help you”
OWASP AppSec Seattle 2006 22
OWASP Code Review Guide
Learn by example: Code + Framework examples:
How to locate vulnerable code:
(Anti)Patterns to look out for.
- API’s relating to common security issues.
Java HTTPRequest, Java.net.* etc…..
Transation analysis
- Data flow analysis (From event to result)
- Follow the data

Secure code environment:


Configuration files for frameworks and deployment packages
Development languages + frameworks:
Java/J2EE,.NET, C/C++, PHP, Struts OWASP AppSec Seattle 2006 23
Code Review Guide Structure:

Example:

Error, Exception handling & Logging:

Introduction
How to locate the potentially vulnerable code (Anti Pattern)
o JAVA
o .NET
Vulnerable Patterns for Error Handling
Page_Error
Global.asax
Web.config
Try & Catch (Java/ .NET)
Releasing resources and good housekeeping
Potential solutions:
Centralised exception handling (Struts Example)
Logging

OWASP AppSec Seattle 2006 24


OWASP Code Review Guide
Tools:
Open source and commercial
Integrating tools into the development lifecycle
Tool deployment model
Empowering developers
Scalability

OWASP AppSec Seattle 2006 25


OWASP Code Review Guide
Challenges:

We require to keep it up to date:

Technology changes, Standards change, frameworks change.


New Technologies, New frameworks, Finalised standards.

WIKI (Half the battle) but…Contributors (always looking for more).

Cut’N’Paste from other sources….This has occurred.


We don’t want copyright theft or plagiarism

Original work only, this takes time, effort and knowledge.

OWASP AppSec Seattle 2006 26


OWASP Live
CD (Labrat)

OWASP AppSec Seattle 2006 27


OWASP Live CD

Similar to Whoppix/Auditor CD but focus on Application Security

We call it LabRat

Team:

Josh Perrymon CE|H, OPST – OSSTMM, OPST/OPSA Trainer


Based in Australia. Specializes in RFID security.
Josh is also writing the RFID chapter for "Hacking Exposed-Linux Edition"
also owns PacketFocus, ( www.packetfocus.com ) an independent security
research company.

And…..

Me.

OWASP AppSec Seattle 2006 28


OWASP Live CD
Aim:

Produce a stand-alone OS for Application Security testing on a single DVD

A container for the OWASP deliverables: Tools, Guides, etc….

Based on Morphix/KDE

Contains OWASP tools and open source security tools

Contains the OWASP Guides in off-line WIKI format

Currently in Alpha (Lots more to do)

Release 1.0 Due out at end of first phase of “Autumn of code”

OWASP AppSec Seattle 2006 29


Quick Demo…..

OWASP AppSec Seattle 2006 30


Tools
Application: Misc:
•WebGoat •RFID Hacking Tools
•WebScarab •VOIP Hacking Tools
•Cal9000 •OWASP Testing Guide
•Wikto/Nikto •OWASP Code Review Guide
•Fuzz Vectors •Foot printing and Information Gathering Tools

Infrastructure:
•Nmap
•Hping2
•TCPDump
•Yersinia
•MetaSploit Framework
•Nessus

And others….. Suggestions appreciated.

OWASP AppSec Seattle 2006 31


To Conclude….

OWASP Live CD V1.0 release date: End 2006

AoC (Autumn of Code): Testing Guide & Live CD included in prospectus.

Currently they (OWASP Guides) are some of the most frequented AppSec guides
on the net.

But…….

Want/Need to grow and adapt over time

Need contributors for all OWASP projects.

OWASP AppSec Seattle 2006 32


Go Raibh Maith agat

(Thanks)

OWASP AppSec Seattle 2006 33

You might also like