Application Security

Chapter Eight

Prepared by: Raval, Fichadia

Raval • FichadiaRaval • FichadiaJohn Wiley & Sons, Inc. 2007

2

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.

3

The Big PictureElements of an

application architecture.

Some risks that impact applications.

4

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.

5

Applications primer

Application: software that runs on the operating system providing various types of functionality.

Relationship between application and system software.

6

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.

7

Applications primer

Application architecture: applications are built as standalone programs or by layers.

Two-tier vs a three-tier application.

8

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.

9

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.

10

Risks and controlsBoundary 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.

11

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.

12

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.

13

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

14

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.

15

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’

16

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)

17

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.

18

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.

19

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’!!

20

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.

21

Risks and controls

Input manipulation: Application-specific input attacks.

HTTP headers and HTML form fields can easily be manipulated by end users.

22

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.

23

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).

24

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.

25

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.

26

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.

27

Risks and controlsSession 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.

28

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 non-persistent (in browser memory).

Cookies can have expiration dates.

29

Risks and controls

Session management: Cookies help maintain state.

Cookies can be secure (encrypted in transmission) or non-secure (not encrypted).

30

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.

31

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.

32

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.

33

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.

34

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

35

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.

36

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.

37

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.

38

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.

39

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.

40

Assurance considerationsAn 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.

41

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.

42

Recap