Application Security

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.

The Big Picture Elements of an application architecture. Some risks that impact applications.

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.

Applications primer Application: software that runs on the operating system providing various types of functionality. • Relationship between application and system software.

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.

Applications primer Application architecture: applications are built as standalone programs or by layers. • Two-tier vs a three-tier application.

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.

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.

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.

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.

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.

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

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.

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’

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)

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.

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.

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

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.

Risks and controls Input manipulation: Application-specific input attacks. • HTTP headers and HTML form fields can easily be manipulated by end users.

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.

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

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.

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.

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.

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.

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.

Risks and controls Session management: Cookies help maintain state. • Cookies can be secure (encrypted in transmission) or non-secure (not encrypted).

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.

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.

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.

Risks and controls Controlscontd.: • 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.

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

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.

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.

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.

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.

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.

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.

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.

Recap

Application Security