Web Application Security

1
Web Application Security

• Jim Hewitt, CISSP PMP
• CGI-AMS
• james.hewitt_at_cgi-ams.com

2
What is Out of Scope

• Out of scope for today
• Protection from all fraud
• Social engineering, covert channel attacks,
  corrupt insiders
• Speaking sensibly to management
• Does this information really belong on the
  Internet?
• Specific exploits (mostly)
• Network security, high availability, backup and
  recovery, DoS attacks
• Get IE out of the building

3
What is In Scope

• Before you begin
• Requirements analysis
• Testing
• Security design patterns
• Implementation
• Testing
• Support

4
What is Different About Web-Based Applications?

• Uncontrolled user environment
• Assume the worst about the users machine
• May be unpatched, or hacked outright
• If an external person has an ID and password,
  assume they are on a whiteboard in large letters
• Minimize the impact of a compromised ID
• No way to sanction or influence users behavior

5
What is Different About Web-Based Applications?

• Rapid emergence of vulnerabilities in the
  environment
• Technologies are less mature, tend to have more
  weaknesses
• Libraries are less mature and turn over more
  rapidly
• 12 months 3 months
• Remark by (former) CEO at (defunct) software
  company
• Likelihood of breach of greater
• Impact of breach is greater

6
What is Not Different About Web-Based
Applications?

• Importance of policy, architecture and design
• Desire for faster time-to-market,
  time-to-deployment
• Usually outweighs security concerns
• Schedule and cost limitations win out
• Need to think about alternative architectures,
  alternative approaches to satisfying requirements

7
Decisions The Developer Should Not Make 1

• IT policy, standards and guidelines
• Not just security policy
• This should already exist, in enough detail for
  developers to do their work
• Developers should refer to them and make sure
  their work complies
• If you don't have them, it's time to push back on
  management
• If you are in management, make sure your people
  have what they need to design, build and roll out
• These are needed for any application yours may
  not be up to date for web applications

8
Decisions the Developer Should Not Make 2

• Security policy
• Better yet, start with your organizations IT
  governance structure
• A new app will bring up new policy areas
  builders must not be tasked with deciding these
• Get help, get clarification
• Who owns this data, who owns the process?
• Developers need to know data classifications /
  sensitivities, requirements for system
  integrity, auditing, change management
• Get these before you start
• Compliance with security policy is part of the
  applications requirements
• Developers Get policy and security requirements
  information before you commit to functionality,
  resource requirements and schedule
• Complying will take extra work and cost
• Build it into your plan, dont let it make you
  late
• Introducing it near the end of development will
  take massive extra work and cost

9
Meet the Security Architect

• As in card games, if you don't know who the
  security architect is, you're it.
• Get business people, developers, other architects
  and stakeholders to agree, or at least accept
  security measures
• Focus at the enterprise level first
• Many of the requirements are set at the
  enterprise level and not really negotiable
• Enterprise LDAP structure, single signon,
  firewall policies
• Think about what to protect
• Wait until later for how to protect

10
Bad

• Start coding right away.
• Stay on the happy path.
• This project doesnt officially exist.
• Reference Project Management Body of Knowledge
  Project Charter, www.pmi.org

11
Good 1

• Application checklist
• Defined, signed-off business requirements
• Service level requirements (security, support)
• User roles and responsibilities
• Project plan, schedule, resource requirements
• Pre-production testing scheduling
• Marketing, promotion of service
• Communication Plan
• Features and limitations (Cookies and JavaScript)
  
• Establishment of Help Desk

12
Good 2

• Development Requirements
• Defined and documented technical requirements
• Architecture diagram
• Data flow diagram
• Review application design against requirements
• Requirements and design sign-off
• Supporting plans
• Where SSL certs will come from, DNS, Trusted time
  service
• User Enrollment, for portal-style applications
• Handling of shared secrets
• Allocation of user time for acceptance testing
• Rollout of Application
• Will it run on a hardened server?
• Will its traffic be allowed through the
  enterprise firewall?
• Migration to production
• Maintenance
• Likely failure modes, for support reference

13
Good 3

• Security and privacy requirements
• Data classifications / sensitivities
• Applicable policies, legal, regulatory
• Results of risk assessment
• Residual risks
• Risks to privacy
• Requirements sign-off
• Threat and Risk Assessment
• Privacy Impact Assessment
• Program/Application Certification and
  Accreditation
• Audit requirements

14
Know Before You Start Coding Deployed Apps
Security Profile

• Input validation
• Authentication
• Authorization
• Configuration management
• Session management
• Cryptography
• Exception handling
• Auditing and logging

When you see a good move wait - look for a
better one. Emanuel Lasker World Chess Champion
1894-1921
15
You Are Here

• Before you begin
• Requirements analysis
• Testing
• Security design patterns
• Implementation
• Testing
• Support

16
In the Beginning Requirements

• What are the security requirements of the
  application?
• What are service level expectations?
• Is the application capable of meeting those
  requirements?
• Preserve requirement traceability. Your
  credibility depends on it.
• Aids in understanding reasons countermeasures
  were put in place
• Makes it easier to deal with future, changing
  threats
• Be creative in thinking about what could go wrong

17
How Will You Make Your App Secure?

• Probably not with specific countermeasures,
  fixing every bug, hardened operating system for
  external servers, IDS, PKI and firewalls
• Clear, complete requirements, correctly
  implemented, operated and maintained.
• Assume underlying components have security flaws
  and will continue to develop them
• Assume operation and maintenance will not be
  perfect, that environment will be changing

18
More on Requirements

• Requirements are always changing
• Getting stable requirements may be the biggest
  challenge of almost any project
• Not getting them may be the most common cause of
  project failure
• Real-world requirements always have gaps,
  conflicts and ambiguities
• Beware the dreaded "implicit requirement"
• Everyones understanding of the business, the
  environment, and their problems will change as
  the project progresses

19
Policy Examples

• Policies
• -gt Requirements
• -gt Features
• -gt Mechanisms
• All non-console administrative access will be
  encrypted
• Applications will not assume the client is
  properly configured
• Things to know before you start Romanowsky
• Security principles
• Monitor, audit, promote awareness
• Security policies
• Security approaches to satisfying business
  requirements
• Security procedures
• Tools, tasks e.g. no telnet, do secure remote
  admin, central log server

20
Policy Example from SANS Policy Project

• Requirements for securely storing and retrieving
  DB credentials for use by programs running on
  ltyourNameHeregt network.
• - DB credentials must not be stored in a location
  that can be accessed through a web server.
• - DB user names and passwords may be stored in a
  file separate from the executing body of the
  program's code. This file must not be world
  readable.
• - DB credentials may reside on the DB server. In
  this case, a hash number identifying the
  credentials may be stored in the executing body
  of the program's code.
• - DB credentials may be stored as part of an
  authentication server such as an LDAP server used
  for user authentication. DB authentication may
  occur on behalf of a program as part of the user
  authentication process at the authentication
  server. In this case, there is no need for
  programmatic use of DB credentials.
• - Pass-through authentication (i.e. Oracle OPS
  authentication) must not allow access to the
  database based solely upon a remote user's remote
  authentication on the remote host.
• - Passwords used to access a DB must adhere to
  the Password Policy and be under password control.

21
You Are Here

• Before you begin
• Requirements analysis
• Testing
• Security design patterns
• Implementation
• Testing
• Support

22
Testing 1

• Write the acceptance tests first
• Give them to the user, saying, This is what this
  transaction will do.
• If the user disagrees, its still easy to change
• Write your app to satisfy the tests

23
Testing 2

• If you're not sure what to do, look at the
  requirement, write a test scenario
• If you can't write a test scenario against it,
  the requirement is incomplete
• Write a scenario for what is meant to trigger a
  security failure

24
More Requirements Design Considerations

• Draw site map
• Where can the user go without session
  information?
• What are public areas?
• What should show up in search?
• What will Google site search reveal?
• Segregate these areas into own directories
• Where are entry points?
• Find each one, determine path from it, secure
  that path
• By users -- try to keep the number of entry
  points to a minimum
• By search agents -- don't expose indexing
• Pick pages for indexing early on, designate them
  as public, give them their own subdirectory
• Put what you want in robots.txt
• Some search agents purposely ignore this
• Test with (e.g.) SamSpade

25
Risk AssessmentWWWhats in Your App?

• Identify Application Assets
• Database tables
• System tables
• Application tables
• Database pools
• (default and application-specific pools)
• Private key stores
• Connector resources from JNDI for platform
  components

26
OWASP Top 10 Web Application Vulnerabilities

• 1. Unvalidated Input
• Information from web requests is not validated
  before being used by a web application. Attackers
  can use these flaws to attack backend components
  through a web application.
• 2. Broken Access Control
• Restrictions on what authenticated users are
  allowed to do are not properly enforced.
  Attackers can exploit these flaws to access other
  users' accounts, view sensitive files, or use
  unauthorized functions.
• 3. Broken Authentication and Session Management
• Account credentials and session tokens are not
  properly protected. Attackers that can compromise
  passwords, keys, session cookies, or other tokens
  can defeat authentication restrictions and assume
  other users' identities.
• 4. Cross Site Scripting (XSS) Flaws
• The web application can be used as a mechanism to
  transport an attack to an end user's browser. A
  successful attack can disclose the end users
  session token, attack the local machine, or spoof
  content to fool the user.

27
OWASP Top 10 Web Application Vulnerabilities 2

• 5. Buffer Overflows
• Web application components in some languages that
  do not properly validate input can be crashed
  and, in some cases, used to take control of a
  process. These components can include CGI,
  libraries, drivers, and web application server
  components.
• 6. Injection Flaws
• Web applications pass parameters when they access
  external systems or the local operating system.
  If an attacker can embed malicious commands in
  these parameters, the external system may execute
  those commands on behalf of the web application.
• 7. Improper Error Handling
• Error conditions that occur during normal
  operation are not handled properly. If an
  attacker can cause errors to occur that the web
  application does not handle, they can gain
  detailed system information, deny service, cause
  security mechanisms to fail, or crash the server.

28
OWASP Top 10 Web Application Vulnerabilities 3

• 8. Insecure Storage
• Web applications frequently use cryptographic
  functions to protect information and credentials.
  These functions and the code to integrate them
  have proven difficult to code properly,
  frequently resulting in weak protection.
• 9. Denial of Service
• Attackers can consume web application resources
  to a point where other legitimate users can no
  longer access or use the application. Attackers
  can also lock users out of their accounts or even
  cause the entire application to fail.
• 10. Insecure Configuration Management
• Having a strong server configuration standard is
  critical to a secure web application. These
  servers have many configuration options that
  affect security and are not secure out of the
  box.
• Reference www.owasp.org

29
You Are Here

• Before you begin
• Requirements analysis
• Testing
• Security design patterns
• Implementation
• Testing
• Support

30
Design Patterns

• Design Patterns originated in the construction
  industry.
• Software design patterns were popularized in 1994
  by the Gang of Four
• Rule 0 Don't invent anything. Someone has
  faced this problem before.
• (Not absolute, but nearly.)
• Design patterns give developers the benefit of
  widely-applied successful solutions to recurring
  problems
• Each pattern has a problem, a context, and a
  solution
• In practice, patterns may include UML diagrams
  and sample code
• The purpose of security design patterns is to
  close the divide between developers and security
  people.
• Developers Security people dont understand
  that security is part of our job, not all of it.

31
Design Patterns 2

• Requirement Keep sensitive data confidential.
• Architecture Encrypt communications
• Design Encrypt session traffic with
  out-of- band
  authentication
• Development Use these algorithms, program
  libraries, code, key
  strengths
• Ref Darrell Kienzle, Matthew Elder, David
  Tyree, James Edwards-Hewitt, Security Patterns
  Template and Tutorial

Most useful security design pattern work is done
here.
32
Design Patterns 3

• Name
• Intent (problem, motivation, context)
• Solution (applicability, rationale)
• Static structure (components, elements)
• Dynamic structure (interactions, collaborations)
• Implementation issues (pitfalls, common mistakes)
• Common attacks that affect this pattern
• Ex. For password lockout, attacker can purposely
  lock out an innocent users ID
• Known uses
• Sample code
• Consequences
• Impact on other requirements (CIA,performance,supp
  ort,user confusion)
• Related Patterns
• References

33
Security Design Patterns

• Identify actors and resources
• Policy, e.g. Only recipient can read email
• Define communication
• Confidentiality restricts read permissions
• Authorization restricts user name
• Describe resource, e.g. need user name
• Set security context, descriptors and
  associations
• Ref Opengroup.org

34
Simple Design Pattern
aClient
aSafeguard
aPolicy
aResource
request
allowAccess
(denied)
request
response
response
35
You Are Here

• Before you begin
• Requirements analysis
• Testing
• Security design patterns
• Implementation
• Testing
• Support

36
Technical Architecture

• Software processes and interfaces
• Technologies
• Network topologies
• Servers, locations, usage of each
• Design your application as if no firewall were
  protecting it
• For most organizations, most of these decisions
  are already made for you and you must work with
  them as constraints
• Reporting, archiving, auditing are probably
  outside the applications core servers
• Anything confidential?
• Risk of interception?

37
Network Components

• Excerpts from Payment Card Industry Data Security
  Standard
• Dont allow internal addresses to pass into the
  Internet from the DMZ
• Secure and synchronize router configuration files
  (e.g. running configuration files used for
  normal running of the routers, and start-up
  configuration files used when machines are
  re-booted, should have the same, secure
  configuration).
• Implement only one primary function per server,
  (e.g. web servers, database servers and DNS
  should be implemented on separate servers)
• Reference www.visa.com/cisp

38
Network Components

• Consider a Reverse Proxy
• Proxy receives HTTP requests
• Looks for disallowed commands
• Limits source addresses
• Passes on valid requests to web server
• Consider Content Validation (XML firewall)
• Prevents external clients from invoking critical
  web services

39
Web application environment

• Don't use the production server to develop code
• Keep production server as clean as possible
• Start from minimal, trusted image
• Nothing on it except the app
• Consider whether to do remote administration
• Massive risk versus massive inconvenience
• Consider a 2-part DMZ, one with public sections
  of the app, the other with private, on 2 separate
  servers
• May be able to limit backend access to the
  private server only
• Still need integrity protections on public part

40
Exploits

• Concentrate on causes, not specific exploits
• Specific exploits will be stale, and new ones
  will be raging, by the time the app is rolled out
• Find design patterns that address multiple
  vulnerabilities

41
Example Cookie-based Vulnerabilities

• Almost all Cookie-based problems are one of
  these three
• Replay / re-use
• Misuse of information in cookie, that should be
  private
• Tampering with cookie
• Encrypt a hash of the cookie with a timestamp,
  and validate it on the server
• Do this and you wont have to worry about this
  range of cookie exploits, which are sure to arise
  in the future

42
Storing Sensitive Data The Obvious

• Dont store it if you can avoid doing so retain
  as briefly as possible, securely dispose as soon
  as possible
• You have a policy for that, right?
• Dont store full authentication data after
  authentication
• Hash, truncate and encrypt user-identifying
  information
• You probably dont need to display or transmit
  full identifying information, such as a full SSN

43
Storing Sensitive Data Less Obvious

• Don't put anything confidential or important on
  an external, unprotected proxy
• For a large object with sensitive content,
  consider streaming it and displaying it via a
  browser plug-in
• Consider the 'no-store' cache control directive
• Dont rely on this for anything really sensitive
• Different browsers behave differently, some
  behavior is user-configurable
• IE and Mozilla seem to disagree about what
  no-cache and no-store do

44
Secure Coding 0

• The obvious
• Establish coding rules, check for them in the
  build
• But Im an artist, and code is my canvas!
• No comparing Class objects by name, no passing
  byte arrays to DataOutputStream
• Desktop checking?
• The build takes an hour!
• Unit test for reliability
• Functional test after each unit is touched
• Regular full regression test

45
Secure Coding 1

• The obvious
• Separation of code and data
• Modularity
• Strong typing
• PHP, if you must
• www.whip3.net/whitepapers/phpguide.php
• www.zend.com/zend/art/art-oeli.php
• Perl, if you must
• www.perldoc.com/perl15.6/pod/perlsec.html

46
Secure Coding 2

• What keeps a users typed input from being
  executed on your server?
• Malicious code, wrapped in HTTP request, unpacked
  by web application, passed to interpreter (OS,
  database), executed on behalf of web app
• Use extreme care when invoking an interpreter
• Use limited interfaces where possible
  (PreparedStatement)
• Check return values for harmful content before
  doing anything else with them

47
Secure Coding 3

• Example App uses input to construct dynamic SQL
  statements to access the database
• Test the database driver to ensure it has
  implemented the "PreparedStatement" without room
  for SQL injection
• Validate input for SQL
• Don't do batch execution of JDBC package without
  validating input
• Use Least Privilege on database tables
• Protect the connection pool with roles and access
  policies

48
Secure Coding 4

• Before
• selectStatement connection.prepareStatement(
  "SELECT UserID FROM USERS WHERE Username '"
  user "' AND Password '" password "'")

49
Secure Coding 5

• After
• PreparedStatement selectStatement null
• selectStatement connection.prepareStatement(
  "SELECT UserID FROM USERS WHERE Username ? AND
  Password ?")
• selectStatement.setString (1, user)
• selectStatement.setString (2, password)
• resultSet selectStatement.executeQuery()

50
Secure Coding 6

• Prevents most of the OWASP Top Ten (e.g.)
• Never use a Request object on a Response.Write
  statement
• Response.Write "You have entered "
  Request("UserInput")
• Instead, assign the user input to a variable,
  check for tags
• Pass it through Server.HTMLEncode filter A-Za-z
• Do this before any other processing occurs
• Cross-site scripting
• Validate input, checking that it does not contain
  an URL string
• Set character encoding explicitly, to limit how
  input can be represented
• ltMETA http-equiv"Content-Type"
  content"text/html charsetISO-8859-1"gt
• requestEncoding and responseEncoding attributes
  in Web.xml

51
Secure Coding 7

• Try for least programming-intensive solution you
  can find
• Example
• As control against "forced browsing", in Struts,
  check HTTP_REFERER in header
• Only a rudimentary control, because it can be
  forged
• Check that user has permission for URL, via
  role-based access control (many tools for this)
• Use Struts support for roles map user ID,
  permitted URLs
• Servlet filter would be effective

52
Secure Coding 8

• Parasoft Java Coding Rules
• Avoid dangling "else" statements
• Avoid "try", "catch" and "finally" blocks with
  empty bodies
• Do not assign loop control variables in the body
  of a "for" loop
• Do not compare Class objects by name
• Do not pass byte arrays to DataOutputStream in
  the 'writeObject()' method
• Make your 'clone()' method "final" for security
• Close input and output resources in "finally"
  blocks
• Prevent potential memory leaks in
  ObjectOutputStreams by calling 'reset()
• Use 'String' instead of 'StringBuffer' for
  constant strings

53
Validate Everything from the Client

• Protects against OWASP Top Ten Nos. 1,4,5,6 and
  most of 9
• Dont believe anything the browser tells the
  server
• Reject everything, then decide what you
  specifically want to accept
• Gracefully disallow anything that could be
  metadata
• Dont allow anything that might be a database
  command
• For a name field, filter out anything that
  isnt A-Z,a-z
• Protects against cross-site scripting, parameter
  tampering, buffer overflows
• You need something to validate against

54
Validate Everything from the Client 2

• Create a pattern for encoding the incoming
  transaction
• Use a single, canonical encoding scheme, the same
  scheme for all requests
• Check all incoming data against it, before you do
  any other processing
• Decoding against the canonical encoding scheme
  should always be the first thing you do
• Run validation checking of incoming parameters,
  right after decoding
• Ref Developing and Deploying Secure Web
  Applications, whitepaper, www.watchfire.com

55
Validate Everything from the Client 3

• Check the size of incoming parameters before
  doing any more processing of them
• JavaScript checking doesn't count for security
• Use it for user convenience only
• Don't let users type input unless it is
  unavoidable
• Give them checkboxes or dropdowns
• Use POST instead of GET to hide data and make it
  harder to tamper with
• Parameters are passed in the body of the request,
  not in the URL
• Will slow down curious users
• Consider signing and encrypting links
• Use hidden parameters as a last resort, consider
  signing and encrypting them

56
Validate Everything from the Client 4

• Don't use user-entered parameters to create a
  page dynamically and send it to the user, without
  validating what the user has entered
• i.e. When Bob enters his name, the page says
  'Hello Bob
• Example from www.cert.org/advisories/CA-2000-02.ht
  ml
• Malicious link ltA HREFhttp//example.com/commen
  t.cgi? mycommentltSCRIPTgtmalicious codelt/SCRIPTgtgt
  Click here lt/Agt

57
Validate Everything from the Client 5

• Don't trust HTML headers
• Consider signing and encrypting
• Don't assume they have any integrity -- the user
  can change them to anything he or she wants
• OK ex. for setting sequence of screens the user
  can tamper with it, but it's extra work

58
Validate Everything from the Client 6

• Decision tree Processing Authentication form,
  before checking user ID and password
• 1. Accept input from web client
• (system expected some input from this client)
  (else fail)
• 2. Validate login form
• (this session just requested a login form, this
  is really my form, it hasn't been modified
  illegally) (else fail)
• 3. Validate user input (username and password are
  2 strings, no illegal characters) (else fail)
• 4. Authenticate user (this is a real user, right
  account number, right password, etc.) (else fail)

59
Validate Everything from the Client 7

• Search your code for HttpServletRequest calls to
  getCookies(), getHeaders(), getIntHeader(),
  getQueryString(), and getParameterValues(). Then
  check to see if the values returned from these
  calls are carefully scrubbed before they get
  used. (see Ref)
• Williams recommends assigning regular expressions
  to each piece of the HTTP request, aggregating
  all the regexs, and creating a callable
  validation component.
• The engine takes pieces of the HTTP request as
  arguments, and returns errors fitting the regular
  expressions
• Example Test JSESSIONID against A-F0-932
• 32 chars in length, A-F or 0-9
• Ref Jeff Williams, How to Build an HTTP Request
  Validation Engine for Your J2EE Application,
  www.owasp.org/columns/jwilliams/jwilliams2.html

60
Dont Tell the Client Anything Useful

• Nothing in HTML source that reveals anything
  about the application
• Nothing sensitive in headers or elsewhere

61
Make the URL Untouchable

• Dont let user browse freely
• Infile../../
• Dont expose useful information
• Dont put tamper-prone parameters in the URL

62
Fail Securely

• Know your failure modes
• Dont put anything useful in exception messages
• For error pages, i.e. 404 not found, dont
  repeat any of users input
• Risk of cross-site scripting

63
Secure Roll-out

• Clean up development backdoors
• Turn off debug
• Remove strings where possible

64
Secure Misconfiguration

• To the extent possible, dont let an OS or
  datastore problem turn into a problem for your
  app
• Even if server is compromised, your app should
  stay secure, or fail securely
• Assume future vulnerabilities will appear, and
  the server your app runs on will be unpatched
• If you are trusting your configuration files,
  make sure they are trustworthy
• You have integrity controls on your config files,
  dont you?
• If you are trusting information from third-party
  software, how do you know it is securely
  configured and operating properly?

65
Authoritative / trusted source of data

• Does data come from a trusted database, or from
  possibly corrupt source?
• Which system / source / version of the data is
  the system of record
• Know the validity of all data, and its origin
• Business process owner decides what is valid,
  what is One Trust Source
• If bad data is introduced it is not propagated
• Data has explicit ownership and accountability
• Ref Romanowsky

66
Third party Communication

• Know the risks of third party relationships
• Does your upwind neighbors fire turn into your
  fire?
• Can you detect anomalous traffic behavior from
  your business partner?
• Do partners risks bleed over to yours? Will a
  breach in their network lead to a breach in
  yours?
• What are partners security requirements and
  considerations?
• Identify authorized origin and target access
  points for each connection
• What external users / processes need privileged
  access?
• Start with none and negotiate downwards
• Consider separate subnets for each 3rd party
• Get audit and compliance reports from the 3rd
  party

67
Decoupling

• Abstract security services away from single
  applications, to Security Provider Service
• Centralize management and functionality
• Less complexity better security
• Single, authoritative user authentication (SSO)
• Use (e.g.) a SAML token for SSO access across
  different services using the external
  authentication service
• Single role assignment and policy enforcement
  (authorization)
• Centralize and maybe delegate policies
• Example Use SSO system to pass trust back to
  the users home authentication service
• Consolidate auditing and reporting
• Downside must make each app work with service

68
You Are Here

• Before you begin
• Requirements analysis
• Testing
• Security design patterns
• Implementation
• Testing
• Support

69
Areas for Testing 1

• 12 areas of testing source / attribution??
• Authentication
• User-ID complexity, lockout after n tries, user
  name harvesting
• Local saving of passwords, login error messages,
  password policy
• Authorization
• cookie use and complexity, caching, tracking
  logic
• susceptibility to session hijacking / session
  replay
• Information leakage
• HTML page source no revision history, comments,
  email addresses
• Internal host information, hidden form fields,
  error messages

70
Areas for Testing 2

• Field variable control
• Buffer overflows, SQL injection, cross-site
  scripting, system calls, URL re-writing
• Session time-out and logout
• No back-button, cookie invalidation, multiple
  logins per single user
• Reusing older credentials to gain access
• Cookie replay attacks
• Interception of cookie
• Use encrypted cookie, cookie timeout mechanism to
  force authentication
• Cache control
• No sensitive information stored locally
• No tracking material stored that could replay
  session

71
Areas for Testing 3

• Server side application logic
• Web application execution environment, database
  interaction, internal proxying
• APIs, unauthorized command execution
• Client side software vulnerabilities
• Code obfuscation, client connection DOS, client
  code reverse engineering,
• Client function manipulation, client privilege
  escalation
• Error handling
• No 404 errors, no database or middleware errors
  that reveal software used,
• No customized error pages revealing useful
  information
• No default error message showing your server
  still has untouched defaults

72
Areas for Testing 4

• Security of third party applications
• Check for single signon, middleware or content
  control applications with published security
  flaws
• Communication protocols used between
  applications, secure configuration of software
• Secure integration of software into web
  environment
• Application administration
• Policy, procedures, ports, login credentials,
  remote access security
• Use of encryption
• Obfuscation, password storing, key management /
  revocation, scalability

73
Test Tools

• Test the application as built
• Will be different from as-designed, but by how
  much?
• What are you really sending over the wire?
• Test before moving to production, then repeat
  against production environment
• Run Netcraft against your public URL
• Does your site return more than minimal
  information?
• Is there anything you would be uncomfortable with
  a would-be Kevin Mitnick knowing?
• SamSpade
• Google penetration testing
• OWASP WebScarab
• OWASP WebGoat
• Analyzer look at what is really going over the
  wire
• Uh, those hidden fields got added in v0.9 and I
  forgot to tell you.
• What do you mean were passing SSN in the clear?

74
Test Tool Analyzer

• Analyzer 3.0exp from NetGroup, Politecnico di
  Torino, Italy

75
You Are Here

• Before you begin
• Requirements analysis
• Security design patterns
• Testing
• Implementation
• Testing
• Support

76
Support and Maintenance 1

• Write procedures for change control and audit
• Future generations will revere you
• As a reward, they will leave you alone
• Put time for this in your plan
• versus, Write code and run away.

77
Maintenance and Support 2

• Lock down configuration files consider (e.g.)
  Tripwire
• Make sure the admin console uses SSL
• Set the security for specific jars so they cannot
  access configuration files
• Run the admin server with an OS user with write
  permissions to the configuration files
• Run the managed servers with a user having only
  read permissions
• Isolate what you were not able to make secure

78
References

• Putting Security into SDLC-OWASP, Curtis Coleman,
  OWASP San Jose, 2004
• Security Design Patterns, Bob Blakeley, Craig
  Heath, Open Group, 2004
• A Guide to Building Secure Web Applications and
  Web Services, The Open Web Application Security
  Project, 2004 (see www.owasp.org and www.fwf.org)
• Digitalparadox.org, news, exploits, reference
  materials
• Payment Card Industry (PCI) Data Security
  Requirements, www.visa.com/cisp
• Bulletproof Java Code, whitepaper, Parasoft.com
• Security Guidebook for Implementing Unemployment
  Insurance Internet Applications, Information
  Technology Support Center, sponsored by the State
  of Maryland, www.itsc.org
• SamSpade.org
• WebScarab, WebMaven see OWASP.org
• Blackhat 2003 Peterson "Security Design Patterns"
• www.arctecgroup.net/articles
• Guttorm Sindre and Andreas L. Opdahl, "Templates
  for Misuse Case Description"
• Asa Grehag, "Requirements Management in a Life
  Cycle Perspective"
• ISO 7498-2 reference for security solution design
• J.J. Whitmore, "A Method for Designing Secure
  Solutions" IBM Sys Jrnl vol 40 no 3 2001
• Sasha Romanosky, "Security Design Patterns
  www.opengroup.org/projects/sec-des-pat/
• SANS Policy Project policies.sans.org
• Simon Byers, Aviel D. Rubin, David Kormann,
  Defending Against an Internet-based Attack on the
  Physical World