Transcript Controls

Raval • Fichadia
John Wiley & Sons, Inc. 2007
Application
Security
Chapter Eight
Prepared by: Raval, Fichadia
Chapter Eight Objectives

Learn the basic concepts of applications and associated
terminology.

Understand the risks that impact applications and the
controls to mitigate them.

Gain the skills to assess the security posture of an
application and make management recommendations.

Apply security principles and best practices to
application designs.
2
The Big Picture
Elements of an
application
architecture.
Some risks that impact
applications.
3
Applications primer
Application: software that runs on the operating system
providing various types of functionality.

Software programs that provide some functionality such
as word processing, spreadsheeting, browsing, e-mail,
etc. to end users and/or to other applications.

Application software resides on top of and needs an
operating system software to function.

Examples of popular application software includes
Microsoft Office, Lotus Notes, Apache web server, AOL
instant messenger.
4
Applications primer
Application: software that runs on the operating system
providing various types of functionality.

Relationship between application and system software.
5
Applications primer
Application architecture: applications are built as standalone
programs or by layers. Three typical layers include:

Presentation layer that provides the user interfaces and
the look and feel of the application.

Business layer that provides business logic to the user
inputs and the outputs.

Data layer that deals with the storage of application
related and user data, typically in a database.

Sometimes two of these layers maybe combined resulting
in a two-tier application. Sometimes, more than three
layers may be used.
6
Applications primer
Application architecture: applications are built as standalone
programs or by layers.

Two-tier vs a three-tier application.
7
Applications primer
Application architecture: Advantage of layering includes:

Allows for parallel development of layers.

Instills discipline in development since the layers have to
work with each other (agreed upon inputs and outputs).

Reusability of layers is possible.

Easier maintenance and support of application.

Possible to change one layer without impacting the other.

Layers can be distributed across different machines.
8
Management concerns
Concerns about application security typically include the
following:

Protecting the company’s reputation as it markets its
software.

Keeping up with existing and upcoming security threats
against applications & implementing mitigating controls.

Defining the optimal security posture for various internal
applications by IT and end users.

Having an effective backup, recovery, business
resumption and a disaster recovery plan.
9
Risks and controls
Boundary checking: Ensuring only valid length inputs are
accepted into input buffers.

Buffers are memory locations allocated by programmers
to store user’s inputs.

Attackers may provide malicious input that runs past the
size of the buffer.

Extra input could spill into sensitive portions of memory.

The results could range from nothing happening, to
application crashing, to compromise of the OS.

Examples of buffer overflow attacks include worms like
Code Red, Nimda, SQL slammer which resulted in
damages worth billions of dollars.
10
Risks and controls
Boundary checking: Ensuring only valid length inputs are
accepted into input buffers.

Buffer overflow attacks overwrite buffer space and run
into memory location that contains the address of the
next code to execute.
11
Risks and controls
Boundary checking risks:

Impact of buffer overflow ranges from application failing
its execution, to its crash, to running of malicious code
of attacker’s choice resulting in complete compromise.
Controls:

Enforce boundary checks before accepting inputs. Use
compilers that warn of potential overflow conditions.

Educate programmers in safe programming practices.

Use languages like Java (instead of C/C++) that don’t
let input easily run past its buffer allocation.

Use products like Stackshield that prevent return
address from being overwritten.
12
Risks and controls
Input manipulation: Manipulated input from attackers can
compromise applications.

Applications accept inputs from users.

Unexpected inputs can compromise application
security.

Several attacks that have become popular are done via
input manipulation.

Examples of input manipulation attacks include

SQL injection attacks

LDAP injection attacks

Application-specific input attacks
13
Risks and controls
Input manipulation: SQL injection attacks.

Applications, typically web-based, with back-end
databases are susceptible to these attacks.

These applications convert user supplied input into SQL
commands that are processed by the database.

Attackers can craft special input that make the SQL
commands malicious in nature.

The database processes these malicious SQL
commands and end up disclosing sensitive data or
running sensitive database commands.
14
Risks and controls
Input manipulation: SQL injection attack example.

Consider, a web application, that allows users to
change their password and asks for following inputs:
UserID: pankaj
Old password: reuse99
New password: simplify87

The resulting SQL executed by the database then is:
UPDATE usertable SET pwd='simplify87' WHERE
userid='pankaj';

This changes the pwd value in the usertable for the user
‘pankaj’
15
Risks and controls
Input manipulation: SQL injection attack example contd.

Now consider, if the user provides the following special
input:
UserID: pankaj' OR userid = 'administrator';-Old password: reuse99
New password: simplify87

The resulting SQL executed by the database then is:
UPDATE usertable SET pwd='simplify87' WHERE
userid='pankaj' OR userid = 'administrator';--';

This changes the pwd value in the usertable for the user
‘administrator’!!
(the - - ask the database to ignore any characters that follow)
16
Risks and controls
Input manipulation: LDAP injection attacks.

LDAP – Lightweight Directory Access Protocol – is used
for accessing and updating directories.

Directories contain information such as individual
names, phone numbers, and addresses.

These applications convert user supplied input into
LDAP commands that are processed by the directory.

Attackers can craft special input that make the LDAP
commands malicious that disclose sensitive data.

Conceptually similar to SQL injection attacks.
17
Risks and controls
Input manipulation: LDAP injection attack example.

Consider, a web application, that shows a phone
number given a person’s name:
UserID: sujala

The resulting command passed to the directory is:
http://www.company.com/search-ldap?user=sujala

This results in information for user ‘sujala’ being
disclosed.
18
Risks and controls
Input manipulation: LDAP injection attack example contd.

Now consider, if the user provides the following special
input:
UserID: sujala)(|postalAddress=*)

The resulting command passed to the directory then is:
http://www.company.com/search-ldap?user=sujala)(|postalAddress=*)

This discloses the postal address of for the user
‘sujala’!!
19
Risks and controls
Input manipulation: Application-specific input attacks.

Web browsers exchange information with applications
on web servers via HTTP headers and hidden HTML
form fields.

These are often relied upon developers for security
checks and identity validation.

However these can easily be manipulated by end users
before sending it to server – thereby bypassing the
security checks.
20
Risks and controls
Input manipulation: Application-specific input attacks.

HTTP headers and HTML form fields can easily be
manipulated by end users.
21
Risks and controls
Input manipulation risks:
Input manipulation can lead to malfunctioning, user
impersonation, loss of sensitive data, etc.

Controls:

Do not trust user’s inputs.

Sanitize user inputs by:


Rejecting known bad data/characters.

Accepting only valid data.

Cleaning bad data.
Do not rely on HTTP headers/HTML hidden fields for
security checks.
22
Risks and controls
Application authentication: The process of establishing
application user’s identity before allowing access.

Different applications used different authentication
means. Some of the ways include are listed below.

HTTP basic authentication is a basic form of
authentication for web applications.

Web server maintains a list of userID/passwords.

Access to secure page prompts the user to provide userID/pwd.

The credentials are passed in clear-text.

There is no way to allow users to log out (discarding of
credentials is not possible).
23
Risks and controls
Application authentication: The process of establishing
application user’s identity before allowing access.
HTTP digest authentication is an enhancement to HTTP
basic authentication for web applications.


Web server maintains a list of userID/passwords.

Access to secure page prompts the user to provide userID/pwd.

The credentials are not sent to the server – instead a hash of
the password is sent to the server. The server computes the
hash of known password and matches it to incoming hash.

The hashes are transmitted along with a timestamp, thereby
preventing replay attacks.
24
Risks and controls
Application authentication: The process of establishing
application user’s identity before allowing access.

HTML form-based authentication is an authentication
scheme designed by the developer to meet their needs.

Non-web applications also have custom application
schemes as designed by developers.

Some applications use third-party-based authentication
schemes. In that, they rely on a trusted third-party to
handle authentication – say an operating system.
25
Risks and controls
Application authentication risks:

Credentials maybe sniffed.

Credentials maybe replayed, even if they are encrypted.

Users may select poor passwords.

Third-party maybe compromised or untrustworthy.
Controls:

Send hashes of credentials, not credentials themselves.

Encrypt transmission of sensitive information.

Timestamp the transmissions to prevent replay attacks.

Ensure third-party is trustworthy and secure.
26
Risks and controls
Session management: Allows web apps to maintain state
(remember what happened in the previous exchange).

HTTP is stateless protocol – every transaction between
the browser and the server is independent of each
other. Subsequent transactions don’t know anything
about previous transactions (state is not maintained).

This poses problems for applications that need state
information to manage a session.


For example, it may authenticate a user in a transaction, and
would need to remember the user is authenticated for
subsequent transactions until the user logs out.
Web developers achieve session management via a
couple of means: cookies and session IDs.
27
Risks and controls
Session management: Cookies help maintain state.

Cookies are small data files that are given to a browser
by a web application when a user first visits.

Every subsequent visit, the application checks if a
cookie exists (and if so, its contents) and thus knows if
a user has previously accessed the application and
what was done in the previous transaction.

Cookies can be persistent (written to hard drive) or nonpersistent (in browser memory).

Cookies can have expiration dates.
28
Risks and controls
Session management: Cookies help maintain state.

Cookies can be secure (encrypted in transmission) or
non-secure (not encrypted).
29
Risks and controls
Session management: Session IDs help maintain state.

Session IDs are token numbers given to a client by a
web application when a user first visits.

The session data associated with the user is stored on
the server side (as opposed to cookies which are stored
on client) and can be referenced via the session ID.

Every subsequent visit, the client provides the session
ID to the application which checks the session store and
thus knows if a user has previously accessed the
application and what was done in the previous
transaction.
30
Risks and controls
Session management: Session IDs help maintain state.

Session IDs can be passed via the URLs or via hidden
fields in the forms submitted.
31
Risks and controls
Session management risks:

Cookies can manipulated by end users to elevate
privileges or impersonate others.

Cookies can be sniffed/stolen leading to impersonation.

Session IDs maybe predictable allowing attackers to
impersonate other users.

Session IDs may be sniffed.
Controls:

Encrypt the contents of the cookies to prevent
manipulation.
32
Risks and controls
Controls contd.:

Encrypt the contents of the cookies to prevent
manipulation.

Implement checksums on cookies and/or session IDs to
ensure they haven’t been tampered with.

Avoid storing authentication credentials in cookies.
Server side storage of data is more secure.

Session IDs should be random preventing its prediction.

Use SSL or other encryption methods to prevent
sniffing.
33
Risks and controls
Change control and management: Process to manage
changes to applications with minimal business impact.

Periodic changes to software or its supporting
infrastructure are required for a variety of reasons.

Change control is the process of managing changes.
Typically this process includes the following steps:






Formal change request
Change authorization and approval
Change documentation
Change testing
Change scheduling
Implementation and followup
34
Risks and controls
Change control and management: Process to manage
changes to applications with minimal business impact.
Change management is a broader concept than change
control that aims at ensuring changes don’t step on
each other.


For example, one may not want to change a web application at
the same time when the DB behind it also is being upgraded.
Change management also aims at minimizing the
business impact of changes.


For example, one may not want introduce change an
accounting system right before end of a fiscal year.
35
Risks and controls
Change control and management risks:

Unauthorized changes can lead to conflicting changes
to fraud.

Lack of communication can lead to changes stepping
on each other.

Circumvention of change control process.

Inadequate testing resulting in application misbehavior.

Lack of documentation could undoing changes and
maintenance difficult.
36
Risks and controls
Controls:

Establish a well defined to a change control and change
management process.

Enforce disciplined adherence to a change control and
change management process.

Implement segregation of duties to reduce risk of
collusion towards a malicious act.

Perform peer reviews of code for changes.
37
Risks and controls
Application infrastructure: The infrastructure surrounding
an application necessary for its functioning.
Application need supporting infrastructure to for its
functions.


Database store application and end-user related data

Networks handle communication related to applications.

Operating systems host applications.

Application can’t be secured if infrastructure is insecure.

Security is only as strong as the weakest link.
38
Risks and controls
Application infrastructure risks:

DB compromise can disclose application passwords.

Network compromise can lead to disclosure of user
credentials, of sensitive data, and an application DoS.

OS compromise lead to keystroke capturing, DoS, loss
of sensitive data, etc.
Controls:

Enforce best practices for OS, DB, and network
security.
39
Assurance considerations
An audit to assess application security should include the
following:

Review the capabilities and training of the development
team to build secure applications.

Ensure applications have quality authentication
mechanisms.

Ensure that the applications have mechanisms to filter
out untrusted user inputs.

Review the security of the supporting infrastructure
(operating system, databases, networks).

Assess if the applications are running with least
privileges and have no hidden backdoors.
40
Assurance considerations

Ensure changes to applications are made in a
controlled fashion and segregation of duties is in place.

Determine if software components are standardized and
reused.

Ensure that functional plans for backup and recovery,
business resumption, disaster recovery are in place.
41
Recap
42