Web Security

1
Web Security

• Ben Johnston
• bjohnston_at_thoughtworks.com

2
Overview

• About ThoughtWorks
• What is security?
• Threats and threat modelling
• Secure technologies
• Web software vulnerabilities
• Development process

3
ThoughtWorks
http//www.thoughtworks.com
4
About ThoughtWorks

• Specialists in high technical risk custom
  software development and application integration
• Leaders in Agile software development
  methodologies, Patterns and Open Source software
• Offices in U.S., Oz, U.K., Canada, India and
  China
• 600 staff globally, 60 staff locally
• Equal opportunity employer
• Graduate boot camp

5
What is security?
6
Security defined

• Prevention of unauthorised actions
• Detection of authorisation failures and
  unauthorised actions
• Reaction to authorisation failures and
  unauthorised actions

7
Unauthorised actions

• Damage or access to equipment
• Disclosure of or access to confidential data
• Tampering with private data
• Destruction of data
• Data spoofing
• Identity theft
• Execution of malicious code
• Denial of service
• Covering of tracks

8
The defenders dilemma

• Every point must be strongly defended
• Attacker only needs to find one weak point to
  succeed
• Only known threats can be defended against
• Attackers can probe for undiscovered
  vulnerabilities
• Defenders can never sleep
• Attackers can strike at leisure
• No such thing as perfect security!

9
Threats and threat modelling
10
Threats

• Physical
• Network
• Environment (OS, app server, web server, db
  server)
• Application
• Social

11
Threat categories

• STRIDE categorises effects of threats
• Spoofing identity
• Tampering with data
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

12
Spoofing Techniques

• Web spoofing
• False copy of the WWW
• Not as difficult as it may sound!
• TCP spoofing
• IP packets have forged return addresses
• DNS spoofing
• Forged information about machine name , IP
  address correspondence
• Man-in-the-middle attacks

13
Whole-web spoofing
14
Assessing risk

• DREAD risk calculation
• Damage potential
• Reproducibility
• Exploitability
• Affected users
• Discoverability

15
Threat modelling

• Analyse data flows
• Construct threat trees using STRIDE (example)
• Assess threat priorities using DREAD
• Design mitigation

16
Security technologies
17
Using cryptography

• Dont write your own crypto algorithms
• Random number generation algorithms
• Dont use linear congruence functions. E.g. CRT
  rand()
• Can use approved algorithms from FIPS 140-1
  standard
• Crypto depends on secret keys
• Dont pass secret data around
• Key management is typically the biggest
  vulnerability

18
Protecting secret data

• Memory and file data is not secure
• Never hard code secret strings
• Random valued strings dont help
• Secret algorithms for recovering secrets can be
  debugged!
• Dont store secret keys unless you really have
  to!
• Hash passwords into verifiers
• Use salted hashing to improve protection against
  dictionary based attacks
• PKCS 5 computationally expensive hashing
  algorithms

19
Ciphers

• Symmetric ciphers use same key to encrypt/decrypt
• Typically used to encrypt large amounts of data
  due to speed
• Most symmetric ciphers (DES, RC4) require brute
  force attacks
• RSA is an asymmetric cipher
• Does not require a shared secret
• Typically used to encrypt small amounts of data
• Attackers must use a different technique call
  factoring
• Key sizes are not equivalent
• 70 bit symmetric key size ? 947 bit RSA modulus
  size
• Choose appropriate key length
• DES keys are 56 bit short term
• Password strength measure effective bit size
  (entropy)
• Bit size pwdLength log2(number of valid pwd
  characters)

20
Technologies

• Digital certificates
• Bind a public key to an identity that holds the
  private key
• Mostly based on X.509v3 standard
• Issued by a certification authority that verifies
  identity out of band
• Public Key Infrastructure (PKI)
• Comprises laws, policies, standards and software
• Regulates or manipulates certificates and public
  and private keys
• Secure Sockets Layer (SSL) / Transport Layer
  Security (TLS)
• Use digital certificates and short term keys to
  encrypt connections
• Firewalls
• Prevents unauthorised network access by limiting
  port access
• Provides packet filtering services

21
Web software vulnerabilities
22
Open Web Application Security Project (OWASP)

• Top ten most critical web application security
  vulnerabilities 2004
• Unvalidated input
• Broken access control
• Broken authentication and session management
• Cross site scripting (XSS) flaws
• Buffer overflows
• Injection flaws
• Improper error handling
• Insecure storage
• Denial of service
• Insecure configuration management

23
Unvalidated input

• HTTP requests can be arbitrarily altered
• URL, querystring, headers, cookies, form fields,
  hidden fields
• Telnet example
• Common input tampering attacks
• Cross site scripting (XSS)
• Buffer overflows
• SQL injection
• Hidden field manipulation
• Forced browsing
• Path traversal

24
Protection against malicious input

• Dont attempt to filter malicious input
• Accept well formed input and reject anything else
• Perform validation on the server
• Client side validation is easily subverted
• HTTP requests can be entered via Telnet session!
• Centralise validation routines
• Validation guidelines
• Data type, allowed character set, min and max
  length
• Can be null?, is required?
• Numeric range, specific legal values
  (enumeration)
• Specific patterns (Regular expressions)

25
Broken Access Control (Authorisation)

• Authorisation is difficult to implement correctly
• Separation of concerns is important in design
• Principle of least privilege applies
• Create an access control matrix
• Users/roles vs functions
• Ensure default deployment is secure
• Specific issues
• Insecure IDs
• Forced browsing past access control checks
• Client side caching

26
Broken authentication and session management

• Correctly implementing authentication and session
  management is difficult
• Flaws commonly found in credential management
• Password change, Forgot my password, Remember my
  password, Account update
• Authorisation
• Strong passwords
• Encrypted logins
• Always POST authentication data, never cache it
• Beware walk by attacks
• Re-authenticate ALL admin functions
• HTTP is stateless - sessions tokens provide
  state
• Attackers can assume identity is session token
  compromised

27
Cross site scripting (XSS) flaws

• Attacker uses web app to send malicious code to a
  different user
• Attacks might be stored in web server, database,
  message forum, visitor log, comment field,
• Victims can be lured via email reflected
  attacks
• Potential consequences
• Account compromise
• Disclosure of users files
• Installation of Trojan horse programs
• Re-direction
• Modification of content
• Many free tools available to hackers

28
Protection against XSS flaws

• Validate input!
• Positive validation, NOT negative
• HTML encode user supplied output
• lt ? lt ( ? 40 ? 35
• gt ? gt ) ? 41 ? 38

29
Buffer overflows

• Attacker causes stack or heap corruption with
  carefully prepared input
• Attacker can cause arbitrary code to be executed
• Protection
• Validate input!
• Managed environments JVM, CLR
• Principle of least privilege Apache, IIS 6

30
Injection attacks

• OS Command injection
• Web servers that call external services
• SQL Injection
• Constructing queries from user input
• Quote the input?
• Use stored procedures?
• SQL injection remedies
• Never connect as sysadmin!
• Use parameterised SQL queries

31
Improper error handling

• Exception conditions reported to user
• Stack traces
• Database dumps
• Error codes
• Fail-open
• Protection
• Error handling policy
• Handle all possible errors gracefully
• Log errors with sufficient details to indicate
  possible flaws

32
Denial of service

• Application failure
• Code quality issues check input!
• CPU starvation
• Profile application under load
• Dont optimise prematurely!
• Memory starvation
• Dont assume memory is limitless
• Dont allocate memory until its needed
• Resource starvation
• Allocation policy change behaviour under attack
• Network bandwidth attacks
• Dont respond to improper requests

33
Development process
34
What should you do about security?

• Educate the team about security issues
• Design continuously and consciously for security
• Amortize the cost across all feature development
• Factor threat modeling into design decisions
• Test for security preferably automated tests
• Identify a security expert for the project

35
Security - engineering practices and development
process

• Adopt a process that reduces cost of change
• Continuously refine the process through
  retrospectives
• Document shared knowledge in a Wiki
• Engineering practices
• Test Driven Development
• Continuous Integration
• Simple Design
• Coding standards
• Pair Programming

36
Security principles in software development

• Learn from your mistakes
• Minimize your attack surface
• Use defense in depth
• Use least privilege
• Use secure defaults
• Assume external systems are insecure
• Expect failure
• Fail securely
• Dont mix code and data
• Fix security issues correctly

37
Features of secure software

• Enables minimal functionality by default
• Allows least privilege
• Determine appropriate access control for
  resources
• Configurable security features via admin tools
• Provides audit logging
• Provides security documentation

38
References

• Writing Secure Code, 2nd Edition
• Michael Howard David LeBlanc
• Open Web Application Security Project
• http//www.owasp.org
• Web Spoofing
• http//bau2.uibk.ac.at/matic/spoofing.htm
• The Honeynet project
• http//www.honeynet.org

39
Please fill out the survey
40
ThoughtWorks contacts

• Follow-up from presentation
• Ben Johnston (bjohnston_at_thoughtworks.com)
• Recruitment
• Amanda Keleher (akeleher_at_thoughtworks.com)
• Commercial
• Natalie Phillips (nphillips_at_thoughtworks.com)
• John Sullivan (jsullivan_at_thoughtworks.com)