by Semi Yulianto

MCT, CEH, ECSA, CHFI, ECSP, SSCP, CISSP, CASP, CISA

Part I
Secure Programming
Securing Engineering
Web Application Attacks
Web App Security Statistics
OWASP Top 10
Security Development Lifecycle
SDL Optimization Model
SDL Security Activities
SDL Process Illustration

Part II
Security Concern in Development
Tools Used by Organization in SDL
Activities Uses in SDL
Security Training for Developers
Results of Implementing SDL
Dos and Donts
Best Practices


Web Application Attacks
Practical OWASP Top 10
Application Vulnerability Assessment
Web Application Pen-Testing
Using SDL Tools
Threat Modeling
Code Review
Challenge Exercises



PART I
Secure Programming is the practice of developing
software where attention and planning is given to
producing robust and reliable applications that operate
securely.

Secure Programming presents practical programming
techniques for developing and enhancing the security of
applications.

Primary methods of attacks and perpetrators are
surveyed and concrete recommendations are given to
prevent each type of attack.

Primary methods of attacks and perpetrators are
surveyed and concrete recommendations are given to
prevent each type of attack.

Secure development concepts, techniques and goals are
identified.

A list of secure programming dos and donts included.

Guideline for both testing software and code reviews are
presented.

Common Questions Asks
How can an organization build secure programming
into application development process?
Failure to define clear and detailed security
requirements is one of the most common issues in
the security assurance process.
Common Questions Asks
How can automated code analysis tools aid in
setting secure programming standards?
Default secure programming standards can be
adopted as a by-product of implementing an
automated code analysis tool.
Common Questions Asks
Are development teams ultimately responsible for
insecure software?
The default responsibility for preventing security
vulnerabilities in source code often falls to the
development organization.

Securing Engineering presents an overview of key
security engineering activities that should be an
integral part of your application development
lifecycle.

Key Objective is to include specific security-related
activities in your current software engineering
processes.

Securing Engineering activities includes:
Identifying security objectives.
Applying secure design guidelines, patterns and principles.
Creating threat models.
Conducting architecture and design reviews for security.
Performing regular code reviews for security.
Testing for security.
Conducting development reviews to ensure secure
configuration.
Attacks
Abuse of Functionality
Brute Force
Buffer Overflow
Content Spoofing
Credential/Session Prediction
Cross-Site Scripting
Cross-Site Request Forgery
Denial of Service
Fingerprinting
Format String
Attacks
HTTP Response Smuggling
HTTP Response Splitting
HTTP Request Smuggling
HTTP Request Splitting
Integer Overflows
LDAP Injection
Mail Command Injection
Null Byte Injection
OS Commanding
Path Traversal
Predictable Resource Location
Remote File Inclusion (RFI)
Attacks
Routing Detour
Session Fixation
SOAP Array Abuse
SSI Injection
SQL Injection
URL Redirector Abuse
XPath Injection
XML Attribute Blowup
XML External Entities
XML Entity Expansion
XML Injection
XQuery Injection

Weaknesses
Application Misconfiguration
Directory Indexing
Improper Filesystem Permissions
Improper Input Handling
Improper Output Handling
Information Leakage
Insecure Indexing
Weaknesses
Insufficient Anti-automation
Insufficient Authentication
Insufficient Authorization
Insufficient Password Recovery
Insufficient Process Validation
Insufficient Session Expiration
Insufficient Transport Layer Protection
Server Misconfiguration
Real Life Attack Examples:
WHID 2010-68: Daily Telegraph website hacked
Occurred: April 15, 2010
Attack Method: Unknown
Application Weakness:
Outcome: Defacement
Reference:
http://www.guardian.co.uk/media/2010/apr/15/daily-
telegraph-hacking
Real Life Attack Examples:
WHID 2010-67: Apache.org hit by targeted XSS
attack, passwords compromised
Occurred: April 9, 2010
Attack Method: Brute Force, Cross Site Scripting (XSS)
Application Weakness: Improper Output Handling
Outcome: Session Hijacking
Reference:
http://blogs.zdnet.com/security/?p=6123&tag=nl.e539


Real Life Attack Examples:
WHID 2010-66: Ads to blame for malware in
Facebook's FarmTown?
Occurred: April 12, 2010
Attack Method: Malvertising
Application Weakness: Improper Output Handling
Outcome: Planting of Malware
Reference: http://news.cnet.com/8301-27080_3-
20002267-245.html
References:
http://projects.webappsec.org/Threat-
Classification
http://projects.webappsec.org/Threat-
Classification-Enumeration-View
http://projects.webappsec.org/Web-Hacking-
Incident-Database

LIVE DEMO
Web Application Attacks

Probability to detect vulnerabilities depending on their origin

The most widespread vulnerabilities in web applications

The most widespread vulnerabilities in web applications

The most widespread vulnerabilities in web applications
The distribution of websites not compliant to PCI DSS

The distribution of websites not compliant to PCI DSS
The primary aim of the OWASP Top 10 is to educate
developers, designers, architects, and organizations
about the consequences of the most common web
application security vulnerabilities.

The Top 10 provides basic methods to protect
against these vulnerabilities a great start to your
secure coding security program.
A01 Cross-site Scripting
XSS flaws occur whenever an application takes user supplied
data and sends it to a web browser without first validating or
encoding that content. XSS allows attackers to execute script
in the victim's browser which can hijack user sessions, deface
web sites, possibly introduce worms, etc.

A02 Injection Flaws
Injection flaws, particularly SQL injection, are common in
web applications. Injection occurs when user-supplied data is
sent to an interpreter as part of a command or query. The
attacker's hostile data tricks the interpreter into executing
unintended commands or changing data.

A03 Malicious File Execution
Code vulnerable to remote file inclusion (RFI) allows
attackers to include hostile code and data, resulting in
devastating attacks, such as total server compromise.
Malicious file execution attacks affect PHP, XML and any
framework which accepts filenames or files from users.

A04 Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a
reference to an internal implementation object, such as a file,
directory, database record, or key, as a URL or form
parameter. Attackers can manipulate those references to
access other objects without authorization.

A05 Cross-site Request Forgery (CSRF)
A CSRF attack 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. CSRF can be as powerful
as the web application that it attacks.

A06 Information Leakage and Improper EH
Applications can unintentionally leak information about their
configuration, internal workings, or violate privacy through a
variety of application problems. Attackers use this weakness
to steal sensitive data, or conduct more serious attacks.

A07 Broken Authentication and Session
Management
Account credentials and session tokens are often not
properly protected. Attackers compromise passwords,
keys, or authentication tokens to assume other users'
identities.

A08 Insecure Cryptographic Storage
Web applications rarely use cryptographic functions
properly to protect data and credentials. Attackers use
weakly protected data to conduct identity theft and
other crimes, such as credit card fraud.

A09 Insecure Communication
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. Attackers can use this
weakness to access and perform unauthorized
operations by accessing those URLs directly.


LIVE DEMO
OWASP Top 10 Explained
Application VA
Web Application Pen-Test

Practical OWASP Top 10
Web Application Attacks
Application Vulnerability Assessment
Web Application Pen-Testing
The Security Development Lifecycle (SDL) is a security
assurance process that is focused on software development.

As a company-wide initiative and a mandatory policy since
2004, the SDL has played a critical role in embedding security
and privacy in software and culture at many companies.

Combining a holistic and practical approach, the SDL aims to
reduce the number and severity of vulnerabilities in
software.

The SDL introduces security and privacy throughout all
phases of the development process.

The four maturity levels of the SDL Optimization Model

SDL Optimization Model with capabilities and maturity levels

Simplified SDL Security Activities



PART II
Microsoft Case Study
Microsoft Windows 2000
Microsoft SQL Server 2000
Microsoft SQL Server 2005
Microsoft Windows XP
Microsoft Windows Vista
Microsoft Exchange Server 2000

LIVE DEMO
Code Review

Using SDL Tools
Threat Modeling
Code Review
References:
http://channel9.msdn.com/wiki/securitywiki/applicati
onsecuritymethodology/
http://channel9.msdn.com/Wiki/SecurityWiki/WebApp
licationSecurity/
http://msdn.microsoft.com/en-
us/library/ms994921%28v=MSDN.10%29.aspx
http://channel9.msdn.com/Wiki/SecurityWiki/WebSer
vicesSecurityChecklist/
http://channel9.msdn.com/Wiki/SecurityWiki/ArchAn
dDesignSecurityChecklist/

FINAL LAB
Challenge Exercises
Input Validation
Do validate input: length, range, format and type.
Do constrain, reject, sanitize input.
Dont trust input.

Authentication
Do use strong password policies.
Do encrypt communication channels to secure
authentication tokens.
Do use HTTPs only with Forms cookies.
Dont store credentials.
Authorization
Do use least privilege accounts.
Do consider granularity of access.
Do enforce separation of privileges.

Configuration Management
Do use least privileged service accounts.
Do use strong authentication and authorization on
administrative interfaces.
Do avoid storing sensitive information in the web space.
Dont store credentials in plaintext.
Dont use the LSA.

Sensitive Data
Do enforce separation of privileges.
Do encrypt sensitive data over the wire.
Do secure the channel
Dont store secrets in software.

Session Management
Do partition site by anonymous, identified and
authenticated.
Do reduce the timout.
Do avoid storing sensitive data in Session.
Do secure the channel.
Parameter Manipulation
Dont trust fields the client can manipulate (Query string,
Form fields, Cookie values, HTTP headers).

Exception Management
Do use structured exception handling (try-catch).
Do only catch and wrap exceptions if the operation adds
value/information.
Don't reveal sensitive system or app info.
Don't log private data (passwords ... etc.).
Cryptography
Do use CryptoServiceProvider for random numbers.
Do avoid key management (use DPAPI).
Do Cycle your keys.
Dont roll your own (XOR is not encryption).

Auditing and Logging
Do identify malign or malicious behavior.
Do know your baseline (what does good traffic look like).
Do instrument to expose behavior that can be watched (the
big mistake here is typically app instrumentation is
completely missing).

Know your threats.
Secure the network, host and application.
Incorporate security into your application life cycle.