testing & code review guides & labrat

8/14/2019 Testing & Code Review Guides & Labrat

1/33

Copyright 2006 - The OWASP FoundationPermission is granted to copy, distribute and/or modify this documentunder the terms of the Creative Commons Attribution-ShareAlike 2.5License. To view this license, visithttp://creativecommons.org/licenses/by-sa/2.5/

The OWASPFoundation

OWAS

PAppSec

Seattle

Oct 2006 http://www.owasp.org/

Testing & Code Review

Guides & Labrat (OWASPLive CD)

Eoin Keary CISSPOWASP Testing and Code Review GuidesLeadOWASP Live CD CoordinatorOWASP Ireland Chapter Lead & Founder

Rits Information Security (Ireland)

[email protected]


2/33

2OWASP AppSec Seattle 2006

Agenda

The OWASP Testing Guide

The OWASP Code review Guide

Labrat: OWASP Live! (Live CD)


3/33


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.

About me
http://www.ritsgroup.com/http://www.ritsgroup.com/


4/33


Introduction: Pen & Patch isunavoidable.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.


5/33


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 cant 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

Pen & Patch: Sustainable?


6/33


We have known these metrics for years.

IBM Labs: Its 100 times more expensive to fix security vulnerabilities afteran 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.

What is the Problem?


7/33


What is the Problem?

Is it technology, is this inherently insecure?

Is it we have based todays 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


8/33


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 ThanDesign

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.

Application Security Testing, What &Why?

Given that.

why are we so busy performing testing?

We shouldnt be finding such low hanging fruit???


9/33


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 jobInteresting.

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


10/33


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 Testing Guide History


11/33


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 Testing Guide


12/33


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 Testing Guide


13/33


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 Testing Guide Contains


14/33


Testing Guide currently

Covers many aspects of application testing

ButMuch more to do..

XSS:

incubated attacks.

Phishing (using java script?)

HTTP Methods

AJAX:

Vulnerabilities

How to test/what to look for.

HTTP exploitsSQL Injection: Oracle, mySQL, SQL

Server, TeraData

Extended stored procedures.

Stored procedure injection

Oracle +SQLServer ports and

attacks. Listener attacks etc. 1521

1433 1526

Automated testing.Tools, how to's, references, tutorials.

Fuzzing with webscarab

Brute Force:

Login forms.

Basic Auth dialoguesWebServices:

Structural Attacks

Content level attacksDTD based attacks

HTTP/REST attacks

SOAP attachment attacks

Brute force

Information gathering:

Error codes: SQL, IIS/.NET Stack Trace (Java)

Source code disclosure, SOAP faults


15/33


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


16/33


Structure .. going forward

We are aiming that the guide is focused on testing howtos 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


17/33


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 Testing Guide V2 Goals


18/33


19/33


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 onsecure coding in the open source arena)

Try:http://www.google.com/codesearch?q=package%3A%22login%22+%22String+password%22&btnG=Search+Code


20/33


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 dont dev orgs consider security as important as functionality?:

- Clients dont demand it.

- No standard to which to compare

- The business:

Security, we cant see it. It does not generate revenue.

-Why?

Culture is the Issue, Not Technology


21/33



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.


22/33



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


23/33


Learn by example: Code + Framework examples:

How to locate vulnerable code:

(Anti)Patterns to look out for.

- APIs 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



24/33


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


25/33


Tools:

Open source and commercial

Integrating tools into the development lifecycle

Tool deployment model

Empowering developers

Scalability



26/33


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) butContributors (always looking for more).

CutNPaste from other sources.This has occurred.

We dont want copyright theft or plagiarism

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



27/33


OWASP LiveCD (Labrat)


28/33


OWASP Live CD

Similar to Whoppix/Auditor CD but focus on Application Security

We call it LabRat

Team:

Josh PerrymonCE|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.
http://www.packetfocus.com/http://www.packetfocus.com/


29/33


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


30/33


Quick Demo..


31/33


Application:

WebGoatWebScarabCal9000Wikto/NiktoFuzz Vectors

Tools

Misc:

RFID Hacking ToolsVOIP Hacking ToolsOWASP Testing GuideOWASP Code Review GuideFoot printing and Information Gathering Tools

Infrastructure:NmapHping2TCPDumpYersiniaMetaSploit Framework

Nessus

And others.. Suggestions appreciated.


32/33


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 guideson the net.

But.

Want/Need to grow and adapt over time

Need contributors for all OWASP projects.


33/33


Go Raibh Maith agat

(Thanks)

testing & code review guides & labrat

Documents