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