The article explains about the several common vulnerabilities in web applications and a detailed explanation about their risks, causes and recommendations.
Cross-Frame Scripting (XFS):
Cross-Frame Scripting (XFS) also known as iFrame Injection is a web security vulnerability that occurs when malicious JavaScript merges with an HTML iframe that loads a legitimate third-party web page in an attempt to exploit and steal sensitive data from the victim user.
The attacker generally performs this attack with the combination of social engineering and suitable browser bug. Once the victim is redirected to a malicious web page and inputs credentials within the iframe, then the malicious JavaScript keylogger captures the victim’s keystrokes and sends them to the attacker’s server.
XFS vulnerability is more threatening than the standard phishing attacks as the iFrame utilization is entirely similar to the target website used to deceive the victim. The possible damages of XFS attack includes data and identity disclosure, denial of service (DOS), control of the victim’s system remotely, using the visible frame to perform clickjacking, installation of spyware on victim’s system for future sniffing.
Cross-Frame Scripting (XFS) works in a similar manner as Cross-Site Scripting (XSS) as both permit the execution of malicious JavaScript scripts. Only difference is that the XFS attack allows only the sniffing of user input for data collection where an XSS attack is performed that doesn’t have to be controlled by the attacker.
Recommendations:
- Implement X-Frame Options in the response header such as DENY, SAMEORIGIN, ALLOW-FROM.
- Framebusting code should be implemented to restrict webpage from being displayed with the frame.
- Content-Security Policy should be defined in the HTML when it is used.
- Block all tracking cookies for security.
- Keep sensitive data in secure encrypted storage.
Privacy Violation:
Privacy Violation vulnerability occurs when private sensitive information in the application is improperly handled and illegally accessed by a malicious attacker. The attacker utilizes this flaw and steals such as customer passwords, account information, social security numbers, credit card details, personally identifiable information (PII), etc.
The common reasons for this vulnerability generally arise due to first- Misplaced trust of sensitive data, where developers frequently trust the operating environment in which a program executes and stores sensitive information on the file system, registry and locally controlled resources. But even though sensitive data access is limited to specific resources, that doesn’t give assurance that the authorized resources are the trusted individuals.
Second one, User data is stored in the unprotected location, such as writing it to a local text or log file, storing personal information in plain text and insecure way of programming.
And, the third one, Exposing of sensitive information on end devices, where sensitive data is easily displayed on end devices such as computer monitors, mobile phone screens, which allows malicious attackers to collect the information by using internet sniffer and screen capture tools.
The damages generated due to the Privacy Violation vulnerability vary from sensitive data leakage, gathering of personal information data saved in plain text through data queries and statistics, identity disclosure, sensitive exposure through error messages.
Recommendations:
- Encrypt all the sensitive information as per standard policy for data at rest and in motion.
- Use strong, complex passwords and enforce secure password management policies for all users and implement strong credential management.
- Delete the sensitive personal information before writing to logs or other files.
- Perform periodic assessments of risks & controls to find flaws in security and privacy.
- Review the need and establish secure authorization of sending personal data to remote web services.
Trust Boundary Violation:
Trust Boundary Violation vulnerability occurs when the application incorrectly merge trusted and untrusted data in the same data structures, that leads to an event where the application trusts the unvalidated data before crossing a boundary.
If the trust boundary is not maintained and well fixed, the application developers will not be able to differentiate the validated and unvalidated data. Due to this the application places user untrusted input in the server side HTTP session folder without properly validating and treating the unvalidate data as trusted one.
Potentially, due to trust boundary violation flaws at user input will create many attacks such as SQL injection, cross-site scripting (XSS), bypass authentication, etc.
Recommendations:
- Implement proper input validation and output encoding of data prior storing or transmitting it into trusted boundaries.
- Avoid mixing untrusted user input with trusted data.
- Sanitize untrusted data and inputs that are passed across a trust boundary.
Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG):
When a standard weak PRNG is utilized in a cryptographic context, it can expose the cryptography to specific types of attacks. The attacker can predict the next value if the application generates insecure predictable values in a security sensitive context and then the attacker uses this guess to impersonate another user or access sensitive information.
For example, for authentication and authorization such as session ID or a seed, if PRNG is used for producing a cryptographic key, then an attacker will easily predict the ID of the cryptographic key and obtain unauthorized access to restricted functionality.
Weak generators basically occur processing power and/or do not use the precious, finite, entropy sources on a system. Such PRNGs might have useful features and be used to break cryptography. This weakness is generally caused during implementation stages of architecture and design of an application.
Recommendations:
- Apply functions or hardware that utilize a hardware-based random number generation for all crypto. Use CryptGenRandom on Windows, or hw_rand() on Linux.
- Prevent exposing the generated random value, store it in a secured database or file.
- Generated random values should be used only once.
Use of Hard Coded Cryptographic Key:
The use of a Hard Coded Cryptographic Key inorder to encrypt the information increases the probability of attackers to get access to unauthorized and encrypted data can be recovered. The weakness is generally introduced during the implementation stage of architecture and design of the application.
Static, unchangeable encryption keys in the source code can be stolen by an attacker with access to the source code or the application binaries. Once the attacker has the encryption key, this can be used to gain access to any encrypted secret data, thus violating the confidentiality of the data. Furthermore, it would be impossible to replace the encryption key once stolen. Note that if this is a product that can be installed numerous times, the encryption key will always be the same, allowing an attacker to break all instances at the same cost.
The application code uses an encryption key to encrypt and decrypt sensitive data. While it is important to create this encryption key randomly and keep it secret, the application has a single, static key embedded in plain text in the source code.
An attacker could gain access to the source code – whether in the source control system, developer workstations, or the server filesystem or product binaries themselves. Once the attacker has gained access to the source code, it is trivial to retrieve the plain text encryption key and use it to decrypt the sensitive data that the application was protecting.
Recommendations:
- Do not store any sensitive information, such as encryption keys in plain text.
- Never hard code encryption keys in the application source code.
- Implement proper key management, including dynamically generating random keys, protecting keys, and replacing keys as necessary.
- Remove the hard coded encryption key from the application source code. Instead, retrieve the key from an external, protected store.
Previous Page —————————————————————————————————— Next Page
Found this article interesting? Follow DefenseLead on Twitter, Facebook and LinkedIn to read more exclusive content.