3.3 Software Architecture
4.1.3 Critical application security flaws and exploits
In this section the most common application flaws that are critical to security will be listed. It is important to have knowledge about common flaws and exploits so that during design and implementation the developer can mitigate the risks of these problems.
Input validation failures
Validating the input parameters before accepting a request is critical to application secu-rity. It is a good practice to validate all input, even from a trusted resource. Validating input 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 types, format, length, range, null-value handling, verifying for character-set, locale, patterns, context, legal values and validity, and so on. Not validating input can cause a malicious code injection attack. If an application relies on client-side data validation, a hacker may exploit any flaw in the server. It is good practice to re-verify and validate input even after client-side validation [18].
Output sanitation
Re-displaying or echoing data values entered by users is a potential security threat because it provides a hacker with a means to match the given input with its output. For example, if a Web 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. This weakness could be exploited to display pop-up banners or worse, change the content originally displayed by the site. To prevent these issues, the generated output must be verified for all known values. Any unknown values not intended for display must be eliminated. All comments and identifiers must be removed from the output as well [18].
Buffer overflow
Buffer overflow occurs when an application tries to store more data in a data storage or memory buffer than its fixed length or its capacity can handle. The extra information will most likely end up in adjacent buffers. This event is likely to cause corruption, caus-ing the application to crash. To perform this kind of attack, the hacker passes malicious input by tampering or manipulating the input parameters to force an application buffer overflow. These attacks are typically carried out using application weaknesses related to input validation, output sanitization, and data injection flaws [18].
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 injec-tion vulnerability). To avoid data injecinjec-tion flaws, it is important to enforce thorough input validation. All input values must be validated for known values only. The rest of them must be rejected [18].
Cross-site scripting (XSS)
With XSS, a Web application can gather information by using a hyperlink or script that contains malicious content. The attackers frequently use JavaScript, VBScript, ActiveX, HTML or Flash in a vulnerable Web application to gather data from the current user.
The script may hijack the user’s account information, change user privileges, steal cookie or session information, and so on. It is important to diagnose and test the application for XSS risks and vulnerabilities [18].
Improper Error Handling
Most applications are likely to be affected by 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 that a hacker can use to crash the application. 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 stored in log files for auditing. In the event of an attack, the log files provide diagnostic information for verifying the errors and for further auditing [18].
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. Using cryptographic mechanisms and data encryption helps ensure the integrity and confidentiality of data in transit or storage [18].
Weak session identifiers
Giving out or using session identifiers before authentication or over not encrypted com-munication channels allow hackers to steal session information and then hijack the associ-ated user sessions for unauthorized business transactions. The weakness of representing the session identifiers as clear text helps the hacker to spoof the user identity infor-mation. The weakness is intensified if the identity information is not validated by the service provider or has not got an expiry time. To prevent these issues, the application should issue encrypted session identifiers after initiating a secure communication channel using SSL because SSL ensures confidentiality and integrity of the session information [18].
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 to impersonate the user. Some Web applications may also echo back their passwords as Base64 values that are susceptible to an attack. If a Web application or HTML script echo the password or token, hackers may intercept them and then impersonate the user for unauthorized access. This is a common security problem in authentication and application session management. To address these issues one should adopt strong authentication, using for example digital certificates, biometrics, or smart cards. It is very important to protect
the password files and also to ensure that the passwords are strong enough so that they can not be easily guessed or cracked by hackers [18].
Weak encryption
Using computers with lots of processing power can compromise a weak encryption.
Algorithm key-lengths longer then 56 bits are considered strong encryption, but in most cases 128-bit key-length and above are recommended [18].
Session theft
Session theft is also referred to as session hijacking and occurs when attackers create a new session or reuse an existing session. Session theft is performed by hijacking a client-to-server or server-client-to-server session. This bypasses the authentication. The attack can be done at several different levels: Web application session level, host session level, or in the TCP connection. In a TCP communication, session hijacking is done via IP spoofing techniques. 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 applications the session hijacking is done via forging or guessing Session IDs or stealing Session ID cookies. To prevent session theft, one should consider the following best practices; always invalidate a session after logout, adopt PKI solutions for encrypting session information, and adopt a secure communication channel such as SSL/ TLS. This is important since session information usually contains sensitive information, such as passwords, credit card numbers, and so on [18].
Insecure configuration data
The most common examples of insecure configuration data are; misconfigured SSL cer-tificates and encryption settings, use of default cercer-tificates, default accounts with default passwords, and misconfigured Web server plug-ins. This particularly impacts the secu-rity in the Web and business tier. To prevent issues, it is important to test and verify the environment for configuration-related weaknesses [18].
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. Failure to enforce application-specific security policies and the lack of policy enforcement in application design are directly related to access control problems. To avoid problems with access control it is important to verify the application-specific access control lists for all known risks and to run penetration tests to identify potential failures [18].
Policy failures
Security policies are used to provide rules and conditions that determine what actions should be taken in response to defined events. If the rules are missing, conflicting or insufficient, or there are invalid conditions or prerequisites, the security processing will not be able to enforce the defined security rules. This can make hackers discover and
exploit any resource loophole. Policy failure is a security issue for application design and policy management [18].
Audit and logging failures
Auditing and logging provides non-repudiation by providing irrefutable evidence about all application events. They record all key application events and any audit or logging failure can cripple the ability to diagnose suspicious activity and foil malicious attacks.
The tracing of exceptions and specific bugs is made impossible if there are logging and audit failures present. The log files must be stored with restricted access [18].
Denial of service (DOS) and Distributed DOS (DDOS)
The worst forms of network-level attacks are DOS and DDOS. These attacks consume excessive amounts of nonrenewable resources in the form of network bandwidth and CPU utilization. They can also cause destruction of host configuration information, resulting in application failures and operating system crashes. DOS attacks are performed by a single machine attacking an other machine, while DDOS attacks are performed by coordinating several machines to attack a single machine. DOS or DDOS attacks are initiated by exploiting application weaknesses and flaws related to resource management, authentication, error handling, and application configuration. Web-based applications are highly susceptible to these kinds of attacks and sometime it is impossible to determine whether the incoming service requests are part of an attack or ordinary traffic. Some approaches to mitigate the threat include host name verification and implementation of router filtering to drop connections from attacks initiated from un-trusted hosts and networks [18].
Man-in-the-middle (MITM)
A MITM attack is a security attack in which a hacker is able to read or modify business transactions or messages between two parties without either party knowing about it.
A MITM attack can be executed by spoofing the business transactions, stealing user credentials, or exploiting a flaw in the underlying public key infrastructure or Web browser. MITM is a security issue in application design and application infrastructure [18].
Multiple sign-on issues
This is a common issue in enterprise application integration environments. It requires the user to log on multiple times because there is no common sign-on mechanism within the environment. When a user switches applications within a server, hackers can compromise security by using credentials from previous sign-on sessions. Since users are required to sign off explicitly from every application, there is an increased risk for human errors, loss of productivity, and failure to restrict the access to the applications which the user have access to [18].
Implementing single on (SSO) mechanisms, where the user only have to sign-on sign-once solves these problems by eliminating the need for users to remember several different usernames and passwords. SSO also gives an increase in productivity because users no longer need to physically enter repetitive usernames and passwords [18].
Deployment problems
Many security exposure issues and vulnerabilities occur by chance because of application deployment problems. Conflicts and inconsistencies within application configuration data and the deployment infrastructure (hosts, network environment, etc) are included in these problems. The factor of human error in policy implementation also contributes and in some cases deployment problems are related to design flaws. Therefore 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 [18].
Coding problems
Coding practices greatly influence application security. Issues related to coding can cause flaws and erroneous conditions in programming and application flow. To avoid issues with for example, input validation, race conditions, exceptions, and application failure it is recommended to adopt a coding review methodology followed by source code scanning for common mistakes. This is to identify all potential risks and vulnerabilities so that they can be corrected [18].