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.
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.
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.
Cross-Site Scripting (XSS)
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.
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.
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.
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.
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.
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.
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.
The preventive measures for DoS and DDoS include implementing router filtering to drop connections from untrusted hosts and networks and configuring fault-tolerant and redundant server resources. In addition, the Web/Application server must be configured to perform host-name verification, identifying fake requests and denying them from further processing. At the application level, the Web server may adopt security patterns such as Secure Pipe, Intercepting Web Agent, and Intercepting Validator.
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. Man-in-the-middle is a security issue in application design and application infrastructure.
The preventive measures for safeguarding Web tier components and Web services communication is done by implementing transport-layer security using SSL/TLS or IPSEC protocols. At the application level, the components can make use of Secure Pipe pattern.
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.
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 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.