OWASP Building Secure Web Applications

1
OWASP Building Secure Web Applications

• And the OWASP top 10 vulnerabilities

2
Background and Material

• Will Bechtel, Blue Oasis - CISSP
• 18 years of experience in Software Development,
  IT and Security.
• Development of web based applications for Sony,
  American Express, Cellular One, Federal Express,
  Sega, US Navy, Wells Fargo.
• Core of presentation from Open Web Application
  Security Project (OWASP) www.owasp.org

3
Overview

• How Much Security Do You Really Need ? how to
  assess the security need and perform risk
  assessments.
• Security Guidelines A set of high level
  principles that all applications should adhere
  to.
• Architecture Discussion on how Architecture
  considerations can ensure security where its
  needed.
• Authentication Describes the different types of
  authentication possible and the common problems.
• Session Management Describes the right way to
  manage sessions and generate session tokens.

4
Overview (cont)

• Access Control Describes access control
  concepts
• Event Logging Describes what to log and how to
  log user and system events
• Data Validation Describes strategies for
  dealing with unexpected input and what you need
  to block
• Common Problems Describes problems like cross
  site scripting and SQL Injection and offers
  practical advise on how to stop them cold
• Privacy Discusses privacy issues that may face
  your application.
• Cryptography - How to use cryptography and
  describes some common mistakes.

5
Risk Management

• How much security do you need?
• Risks, threats and vulnerabilities
• Quantitative approach utilize SLE x ARO ALE
• Most applicable to physical security or specific
  asset protection
• Qualitative approach ranking of potential risks
  and their ability to do harm. Subjective.
• Because data for the quantitative approach is
  usually hard to come by, many times a more
  subjective approach is needed.

6
Security Guidelines

• Validate ALL input and output
• Fail securely
• Use and reuse trusted components
• Defense in depth
• Only secure as the weakest link
• No security by obscurity
• Least privilege, separation of privilege

7
Architecture

• Design for a secure location
• Dont design in a test lab, then worry about
  working in a DMZ environment later.
• Realize at some point least privilege will be
  enforced.
• There is (usually) a trade-off between
  convenience and security.
• Separate, segregate and control access.
• OS and Network security

8
Authentication

• Determining if a user is who they say they are.
• Browser limitations consider all input
  tainted
• HTTP Basic/HTTP Digest
• Forms based authentication use SSL
• Digital certificates
• Entity Authentication Cookies

9
Authentication (cont)

• Password Based Authentication Schemes
• Limits on user names (reduce guessing)
• Storing username/passwords hashing or other
  secure storage
• Ensure password quality
• Password lockout, aging and history
• Automated password reset strategies risk
  remains

10
Managing User Sessions

• Cookies
• Session Tokens
• Session Management Schemes
• Access Control and Authorization
• Event Logging
• Data Validation

11
Preventing common problems

• Cross site scripting (validate)
• SQL injection (validate)
• Direct OS commands (URL filter)
• Directory traversal and path disclosure (URL
  filter)
• Null bytes (string termination)

12
Preventing common problems (cont)

• Parameter manipulation
• URL manipulation
• Cookie manipulation
• HTTP Header
• Form field manipulation

13
URL manipulation

• His/her choices are recorded by pressing the
  submit button. The page is actually storing the
  entries in form field values and submitting them
  using a form submit command. The command sends
  the following HTTP request.
• http//www.victim.com/example?accountnumber12345
  debitamount1
• A malicious user could construct his own account
  number and change the parameters as follows
• http//www.victim.com/example?accountnumber67891
  creditamount999999999

14
Form field manipulation

• All of the same rules apply to hidden forms
  fields as apply to regular form fields.
• Take the same application. Behind the login form
  may have been the HTML tag
• ltinput name"masteraccess" type"hidden"
  value"N"gt
• By manipulating the hidden value to a Y, the
  application would have logged the user in as an
  Administrator.

15
Cookie manipulation

• The extent of cookie manipulation depends on what
  the cookie is used for but usually ranges from
  session tokens to arrays that make authorization
  decisions. (Many cookies are Base64 encoded this
  is an encoding scheme and offers no cryptographic
  protection).
• Example from a real world example on a travel web
  site modified to protect the innocent (or
  stupid).
• Cookie langen-us ADMINno y1 time1030GMT
  
• The attacker can simply modify the cookie to
• Cookie langen-us ADMINyes y1
  time1230GMT

16
OWASP Top Ten

• Unvalidated Input
• Broken Access Control
• Broken Authentication and Session Management
• Cross Site Scripting (XSS) flaws
• Buffer Overflows
• Injection Problems
• Improper Error Handling
• Insecure Storage
• Denial of Service
• Insecure Configuration Management

17
Reasons behind poor web app security

• Lack of knowledge/education security has not
  been a focus for software engineers
• Lack of quality assurance in general, and
  specifically lack of security related testing
• Economic consumers have been willing to
  purchase poorly engineered software and have not
  made this a primary purchasing decision.

18
Web App security tools

• Proxy used to intercept traffic view/modify
  data.
• Web security training apps
• Foundstones Hacme Bank - .Net
• OWASP Webgoat Java

19
(No Transcript)