The Impact of Application Security


A Gartner Group report [CSO online] estimates that employees of companies are responsible for more than 70% of the unauthorized access to information systems in those companies. It is also employees of companies who perpetrate more than 95% of the information systems intrusions that cause significant financial losses. The survey also highlights that a majority of organizations tend to see the importance of security only after actually suffering damage from security breaches. Real-life experience must generally occur before these organizations will allow architects and application developers to get involved with instituting security measures. Businesses are becoming more aware that computer security incidents can originate inside the organization as well as outside. Insider attacks are worse than outside attacks and are usually more malicious. The attacker abuses user privileges or steals application-specific administrator rights and then gains access to resources such as financial applications and other confidential information repositories. With the wide adoption of Internet-enabled applications, businesses and organizations are experiencing a growing rate of security-related damage, such as denial-of-access, exposure of confidential data, unauthorized transactions, identity theft, and data corruption. Most of these issues are more associated with application-specific security flaws and the failure of applications to defend against known threats.

According to an FBI survey [eWeek] of 500 companies, 90 percent said they'd had a computer security breach, and 80 percent of those said they'd suffered financial loss as a result. A 2003 Federal Trade Commission survey [FTC findings] found that 27.3 million Americans have been victims of identity theft in the last five years, including 9.9 million people in 2002 alone. According to the survey, businesses and financial institutions in 2002 lost nearly $48 billion due to identity theft; consumer victims reported losses of $5 billion. After some prodding, the University of Washington Medical Center [AMNews] acknowledged that a hacker had infiltrated its computer system and stolen the confidential records of thousands of patients. Another interesting story [online-kasino] comes from an online gambling casino, where a hacker gained access to the gaming application and corrupted the game so that gamblers could not lose. In just a few hours, gamblers racked up winnings of $1.9 million dollars.

In most organizations, the importance of application-level security is often underestimated until an application faces a major security breach that causes a serious loss or downtime. Most of the time it is clear that the probable cause of the failure is related to deficiencies in the application architecture and design, the programming, the coding security, the runtime platform, and the tools and utilities used. The primary responsibility, of course, belongs to the application architects and developers who contributed to the application design and program code. As a result, today it is mandatory to adopt a proactive security approach during the application development life cycle that identifies critical security aspects. Architects and developers today must design security into their applications proactively.

Let's now take a look at how the most common application-specific security flaws and exploits compromise the security of an application or service.

Critical Application Security Flaws and Exploits

In this section, we will see the most common application flaws that are critical to security and how they can be exploited by hackers.

Input Validation Failures

Validating the input parameters before accepting the request and resuming the process is critical to application security. It is also a good practice to validate all inputsfrom both trusted and untrusted resources. This practice will help in avoiding application-level failures and attacks from both intentional hackers and unintentional abusers. Input validation is a mechanism for validating data such as data type (string, integer), format, length, range, null-value handling, verifying for character-set, locale, patterns, context, legal values and validity, and so on. For example, if a form-based Web application fails to encode square brackets ("[" and "]"), a remote user can create a specially crafted URL that will cause the target user's browser to execute some arbitrary scripting code when the URL is loaded. This can cause a malicious code injection attack, depending on the impact of the scripting code executed. If an application relies on client-side data validation, any flaw may be exploited by a hacker. It is always a good practice to re-verify and validate input, even after client-side validation. From a security perspective, it is very important that all input data are validated prior to application processing. Refer to [InputValidation] for details.

Output Sanitation

Re-displaying or echoing the data values entered by users is a potential security threat because it provides a hacker with a means to match the given input and its output. This provides a way to insert malicious data inputs. With Web pages, if the page generated by a user's request is not properly sanitized before it is displayed, a hacker may be able to identify a weakness in the generated output. Then the hacker can design malicious HTML tags to create pop-up banners; at the worst, hackers may be able to change the content originally displayed by the site. To prevent these issues from arising, the generated output must be verified for all known values. Any unknown values not intended for display must be eliminated. All comments and identifiers in the output response must also be removed.

Buffer Overflow

When an application or process tries to store more data in a data storage or memory buffer than its fixed length or its capacity can handle, the extra information is likely to go somewhere in adjacent buffers. This event causes corruption or overwrite in the buffer that holds the valid data and can abruptly end the process, causing the application to crash. To design this kind of attack, a hacker passes malicious input by tampering or manipulating the input parameters to force an application buffer overflow. Such an act usually leads to denial-of-service attacks. Buffer overflow attacks are typically carried out using application weaknesses related to input validation, output sanitization, and data injection flaws.

Data Injection Flaw

Security intruders can piggyback user data or inject malicious code together with user data while exploiting a weakness in the user data input environment. Data injection flaws are often found in browsers with pop-up windows (window injection vulnerability) or in SQL statements when external input is transmitted directly into SQL (SQL injection vulnerability). In a window injection flaw scenario, security intruders can "hijack" a named Web browser window after a user opens both a malicious Web site and a trusted Web site in separate browser windows. This assumes that the trusted Web site opens up a pop-up window and that the malicious Web site is aware of the name of the pop-up window. To avoid data injection flaws, it is important to enforce thorough input validation; that is, all input values, query strings, form fields, cookies, client-side scripts must be validated for known and valid values only. The rest of them must be rejected. Refer to [SQLInjection] and [InjectionFlaw] for details.

Cross-Site Scripting (XSS)

With XSS, a Web application can gather information by using a hyperlink or script that contains malicious content. An attacker typically uses this mechanism to inject malicious code into a target Web server or to deliver to users a malicious link that redirects them to another Web server. The attackers frequently use JavaScript, VBScript, ActiveX, HTML, or Flash in a vulnerable Web application to gather data from the current user. Based on the user interaction with the target Web server, the script may hijack the user's account information, change user privileges, steal cookie or session information, poison the user-specific content, and so on. Thus, it is important to diagnose and test the application for XSS risks and vulnerabilities.

Improper Error Handling

Most applications are susceptible to security issues related to error handling when they display detailed internal error messages about application conditions such as out of memory, null pointer exceptions, system call failure, database access failure, network timeout, and so on. This information usually reveals internal details of implementation, failure conditions, and the runtime environment. Hackers can make use of this information to locate a weak point in the application and design an attack. This information helps hackers crash applications or cause them to throw error messages by sending invalid data that forces the applications to access non-existent databases or resources. Adopting proper error handling mechanisms will display error messages as user-specific messages based on user input; no internal details related to the application environment or its components will be revealed. All user-specific error messages are mapped to underlying application-specific error conditions and stored as log files for auditing. In the event of an attack, the log files provide diagnostic information for verifying the errors and for further auditing.

Insecure Data Transit or Storage

Confidentiality of data in transit or storage is very important, because most security is compromised when data is represented in plain text. Adopting cryptographic mechanisms and data encryption techniques helps ensure the integrity and confidentiality of data in transit or storage.

Weak Session Identifiers

Issuing or using session identifiers before authentication or over unencrypted communication channels allows hackers to steal session information and then hijack the associated user sessions for unauthorized business transactions. Representing the session identifiers as cleartext helps the hacker to spoof the user identity information using the session attributes. This weakness intensifies if the service provider or Web applications do not validate the identity information obtained from the session identifier of the service requester or if they do not set an expiry time for the session. To prevent these issues, the application should issue encrypted session identifiers after initiating a secure communication channel using SSL that ensures confidentiality and integrity of the session information.

Weak Security Tokens

Weak security tokens refer to the use of password security tokens that allow hackers to guess passwords by using a dictionary or token decrypting tools and to impersonate the user. Some Web applications may also echo back their passwords as Base64 values that are susceptible to an attack and are easily reproducible. If the HTML scripts or Web applications echo the password or security token, hackers may intercept them and then impersonate the user for unauthorized access. A weak security token is a common security problem in authentication and application session management. To address the vulnerabilities they cause, adopting strong authentication or multifactor authentication mechanisms using digital certificates, biometrics, or smart cards are usually considered. Thus, it is important to protect the password files and also ensure that the passwords being used on accounts cannot easily be guessed or cracked by hackers.

Weak Password Exploits

Passwords are the weakest mechanisms for user authentication because they can be easily guessed or compromised by a hacker who is watching the keystrokes or using password-cracking tools to obtain data from password files. When a password is stolen, it is very difficult to identify the culprit while an application is being abused or attacked. Thus, it is important to protect password files by using encrypted files and to ensure that the stored passwords cannot be retrieved, easily guessed, or cracked by hackers. Adoption of strong authentication or multifactor authentication mechanisms using digital certificates, biometrics, or smart cards is strongly recommended. Weak password exploits are one of the most common security issues in network-enabled applications. Refer to [PasswordExploit] for an example.

Weak Encryption

Encryption allows the scrambling of data from plaintext to ciphertext by means of cryptographic algorithms. Using computers with lots of processing power can compromise weaker algorithms. Algorithm key-lengths exceeding 56 bits are considered strong encryption, but in most cases, using 128-bits and above is usually recommended.

Session Theft

Also referred to as session hijacking, session theft occurs when attackers create a new session or reuse an existing session. Session theft hijacks a client-to-server or server-to-server session and bypasses the authentication. Hackers do not need to intercept or inject data into the communication between hosts. Web applications that use a single SessionID for multiple client-server sessions are also susceptible to session theft, where session theft can be at the Web application session level, the host session level, or the TCP protocol. In a TCP communication, session hijacking is done via IP spoofing techniques, where an attacker uses source-routed IP packets to insert commands into an active TCP communication between the two communicating systems and disguises himself as one of the authenticated users. In Web-based applications, session hijacking is done via forging or guessing SessionIDs and stealing SessionID cookies. Preventing session hijacking is one of the first steps in hardening Web application security, because session information usually carries sensitive data such as credit card numbers, PINs, passwords, and so on. To prevent session theft, always invalidating a session after a logout, adopting PKI solutions for encrypting session information, and adopting a secure communication channel (such as SSL/TLS) are often considered best practices. Refer to [SessionHijack] for details.

Insecure Configuration Data

A variety of configuration-related issues in the application or its server infrastructure impact the security of business applications, particularly in the Web Tier and the Business Tier. The most common examples are misconfigured SSL certificates and encryption settings, use of default certificates, default accounts with default passwords, and misconfigured Web server plug-ins. To prevent issues, it is important to test and verify the environment for configuration-related weaknesses. Refer to [InsecureConfig] for details.

Broken Authentication

Broken authentication is caused by improper configuration of authentication mechanisms and flawed credential management that compromise application authentication through password change, forgotten password, account digital update, certificate issues, and so on. Attackers compromise vulnerable applications by manipulating credentials such as user passwords, keys, session cookies, or security tokens and then impersonating a user. To prevent broken authentication, the application must verify its authentication mechanisms and enforce reauthentication by verifying the requesting user's credentials prior to granting access to the application. Refer to [BrokenAuth] for details.

Broken Access Control

Access control determines an authenticated user's rights and privileges for access to an application or data. Any access control failure leads to loss of confidential information and unauthorized disclosure of protected resources such as application data, functions, files, folders, databases, and so on. Access control problems are directly related to the failure to enforce application-specific security policies and the lack of policy enforcement in application design. To prevent access control failures, it is important to verify the application-specific access control lists for all known risks and to run a penetration test to identify potential failures. Refer to [ACLFailure] for details.

Policy Failures

Security policy provides rules and conditions that are used to determine what actions should be taken in response to defined events. In general, business and organizations adopt security policies to enforce access control in IT applications, firewalls, anti-spam processing, message routing, service provisioning, and so on. If there are insufficient or missing rules, invalid conditions or prerequisites, or conflicting rules, the security policy processing will not be able to enforce the defined security rules. Applications can thus be vulnerable due to policy failures. With such failures, hackers can discover and exploit any resource loophole. Policy failure is a security issue for application design and policy management.

Audit and Logging Failures

Auditing and logging mechanisms facilitate non-repudiation services that provide irrefutable evidence about all application events. They help to record all key application events. Any audit or logging failure can cripple the ability of an application to diagnose suspicious activity and foil malicious attacks. Applications also cannot trace exceptions and specific bugs if audit and logging failure is present. Monitoring of auditing and logging processes of applications with high-availability is vital. Log files must be secured by restricted access.

Denial of Service (DOS) and Distributed DOS (DDOS)

DOS and DDOS are the worst form of network-level attacks. They can affect applications in many ways, including excessive consumption of nonrenewable resources such as network bandwidth, memory, CPU utilization, storage, and so on. They can also cause destruction of host configuration information, resulting in application failures and OS crashes. Traditional DOS is an attack by a single machine on another machine; DDOS initiates an attack by distributing and coordinating it from several machines. Hackers initiate DOS or DDOS attacks by exploiting application weaknesses and flaws related to resource management, authentication, error handling and application configuration. Web-based applications are highly susceptible to DOS and DDOS attacks, and in some cases it is impossible to identify whether the incoming service request is an attack or ordinary traffic. It is extremely difficult to adopt preventive measures for DOS and DDOS, although possible approaches include hostname verification and implementation of router filtering to drop connections from attacks initiated from untrusted hosts and networks. Refer to [DOS] for details.

Man-in-the-Middle (MITM)

A MITM attack is a security attack in which the hacker is able to read or modify business transactions or messages between two parties without either party knowing about it. Attackers may execute man-in-the-middle attacks by spoofing the business transactions, stealing user credentials, or exploiting a flaw in the underlying public key infrastructure or Web browser. For example, Krawczyk illustrates a man-in-the-middle attack on a user using Microsoft Internet Explorer while connecting to an SSL server. Man-in-the-middle is a security issue in application design and application infrastructure. Refer to [Krawczyk] for details.

Multiple Sign-On Issues

Multiple sign-on is a common issue in an enterprise application integration environment. It requires a user to log on multiple times because the integrated application does not share a common sign-on mechanism within the environment. This makes an application vulnerable due to the required multiple sign-on actions. When a user switches applications within a server, hackers can compromise security by using credentials from previous sign-on sessions. In addition, users are required to explicitly sign off from every application session within the server. This can result in an increase in human error, loss of productivity, and frequent failure to access all the applications in which they have access rights.

Adopting Single Sign-On (SSO) mechanisms solves these problems by eliminating the need for users to remember usernames and passwords other than their initial application login. SSO also increases productivity, because users no longer need to physically enter repetitive usernames and passwords or other forms of authentication credentials.

Deployment Problems

Many security exposure issues and vulnerabilities occur by chance because of application deployment problems. These include inconsistencies within and conflicts between application configuration data and the deployment infrastructure (hosts, network environment, and so on). Human error in policy implementation also contributes to these problems. In some cases, deployment problems are due to application design flaws and related issues. To prevent these problems, it is important to review and test all infrastructure security policies and to make sure application-level security policies reflect the infrastructure security policies, and vice versa. Where there are conflicts, the two policies will need to be reconciled. Some trade-offs in constraints and restrictions related to OS administration, services, protocols, and so on may need to be made.

Coding Problems

Coding practices greatly influence application security. Coding issues also cause flaws and erroneous conditions in programming and application program flow. Other issues related to input validation, race conditions, exceptions, runtime failures, and so on may also be present. To ensure better coding practices are followed, it is always recommended to adopt a coding review methodology followed by source code scanning so that all potential risks and vulnerabilities can be identified and corrected.




Core Security Patterns. Best Practices and Strategies for J2EE, Web Services, and Identity Management
Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
ISBN: 0131463071
EAN: 2147483647
Year: 2005
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net