Security Flaws in Web Application and its Mitigation

The inability to identify vulnerabilities in a web application can leave it unprotected against potential attackers, resulting in the most severe consequences. Web application vulnerabilities include a system weakness or flaw in a web-based application that leaves you susceptible to security attacks, risking the loss of valuable company or customer data.The inherent complexity of a web application’s source code increases the possibility of malicious code manipulation and unattended vulnerabilities. High-value rewards such as sensitive private data obtained by successful source code manipulation have made web applications a high-priority target for attackers. This makes it essential to thoroughly understand web security vulnerabilities and how to prevent them.

Types of Web Application Vulnerabilities

Common Web Application Vulnerabilities | EC-Council University Official Blog

Web application vulnerabilities are caused due to misconfigured web servers, application design flaws or not validating or sanitizing form inputs. They are prioritized based on their detectability, exploitability and impact on software. So, here is a list of some of the most critical web security risks according to the Open Web Application Security Project (OWASP):

  1. Injection: Injection flaws, including SQL, OS, LDAP and NoSQL injection, take place when a query or command with untrusted data is received by an interpreter. The hostile data by an attacker can trick the interpreter into accessing data without authorization or executing unintended commands. This can lead to the unauthorized viewing of lists, unauthorized administrative access and deletion of tables.

 

  1. Broken Authentication: This occurs when application functions related to session and authentication management are implemented incorrectly. It allows attackers to not only easily compromise passwords, session tokens or keys but also assume the identities of other users temporarily or permanently.

 

  1. Sensitive Data Exposure: Sensitive data can easily be compromised if special precautions are not taken when exchanged with the browser or some extra protection, like encryption at rest or in transit, is not implemented. Many web applications are unable to protect sensitive data properly, which allows attackers to steal or modify it, resulting in credit card fraud, identity theft and a number of other crimes.

 

  1. XML External Entities: Attackers can exploit poorly configured XML processors to access confidential data, inject additional data, create remote tunnels and execute applications. This vulnerability can also lead to Server Side Request Forgery (SSRF), denial of service attacks and remote code execution.

How to Execute an XML External Entity Injection (XXE) | Cobalt | Cobalt.io

 

  1. Broken Access Control: With access control, you can manage the sections of a website and application data accessible to different visitors. If these restrictions are not enforced properly, attackers can easily take advantage of these flaws to get access to unauthorized data or functionality. This can enable these attackers to access the accounts of other users, view sensitive files, change access rights and modify the data of other users.

 

  1. Security Misconfiguration: Counted amongst the most critical web application security vulnerabilities, it offers attackers an easy way into your website. Attackers can exploit unsecure default configurations, open cloud storage, incomplete or ad hoc configurations, verbose error messages with sensitive information and misconfigured HTTP headers. All operating systems, libraries, frameworks and applications can be susceptible to security misconfigurations.

 

  1. Cross-Site Scripting: This vulnerability occurs when untrusted data is included in a web page without validation. It injects malicious code into the web application and executes it on the client-side. It helps attackers execute scripts in a user’s browser to hijack user sessions, redirect the user to malicious sites or deface websites.

 

  1. Insecure Deserialization: Often resulting in remote code execution, deserialization flaws allow cybercriminals to perform a variety of attacks including injection attacks, privilege escalation attacks and replay attacks.

 

  1. Use of Components with Known Vulnerabilities: Various components such as frameworks and libraries run with the same privileges as the web application. Even if a single vulnerable component is attacked, it can cause server takeover and serious data loss. For this reason, a web application that uses components with known vulnerabilities can seriously compromise its defences, leaving it open to attack.

 

  1. Insufficient Monitoring and Logging: Insufficient logging and monitoring along with ineffective or missing integration of incident response can cause another major vulnerability. It can help attackers further attack systems, tamper, destroy or extract data and maintain persistence, pivot to more systems. According to security studies, it often takes more than 200 days to detect a breach. And it is usually detected by an external party instead of internal monitoring or processes.

 

How to Prevent Web Application Vulnerabilities?

How to prevent top 7 Web Application Vulnerabilities?

Organizations that do not properly secure their web applications are more susceptible to malicious attacks, resulting in information theft, revoked licenses, damaged client relationships and legal proceedings. There are several measures that you can take for securing your web applications:

  1. Web application firewalls (WAFs): WAFs are hardware and software solutions designed to examine and monitor incoming traffic for blocking any attack attempts. They offer the best way of compensating for any code sanitization deficiencies.

 

  1. Information gathering: Classify third-party hosted content and review the application manually to identify client-side codes and entry points.

 

  1. Authorization: Test your application thoroughly for path traversals, missing authorization, insecure, direct object references and horizontal and vertical access control issues.

 

  1. Cryptography: Secure all data transmissions, encrypt specific data, check for randomness errors and avoid using weak algorithms.

 

  1. Denial of service: Test for anti-automation, HTTP protocol DoS, account lockout and SQL wildcard DoS for improving your application’s resilience against denial of service threats. Use a combination of scalable resources and filtering solutions for protection against high-volume DDoS and DoS attacks.

Apart from the above measures, running a periodic Vulnerability Assessment and Penetration Testing is essential too. VAPT looks for possible and common vulnerabilities related to the platform, technology framework APIs, etc., and runs exploits on the web application to evaluate its security loopholes. It provides the organizations with reports on discovered vulnerabilities, the nature of the vulnerability, threat level, its impact and measures to eliminate it.

 

Avoid those security vulnerabilities in your iOS

Every program is a potential target for hackers. They would want to tear you down and make you kneel. So, what do we do? I think we should stop writing programs and put our laptop lids down?Naah…. Just kidding!!Attackers will try to find security vulnerabilities in your application. They will then try to use these vulnerabilities to steal secrets, corrupt programs and data. Your customers’ private information and your reputation are at stake.

Security is not something that can be added to software as an afterthought; just as a shed made out of cardboard cannot be made secure by adding a padlock to the door, an insecure tool or application may require extensive redesign to secure it. You must identify the nature of the threats to your app and incorporate secure coding practices throughout the planning and development of your product.

Five weak spots of iOS app security and how to address them - DEV Community

Secure coding is the practice of writing programs that are resistant to attack by malicious or mischievous people or programs. Secure coding helps protect a user’s data from theft or corruption.

Most software security vulnerabilities fall into one of these small set of categories:

  • Buffer overflows
  • Unvalidated input
  • Race conditions
  • Access-control problems
  • Weaknesses in authentication, authorization, or cryptographic practices

I am not going to bore you with the theory of each type of vulnerability here. Duhh!! Who does that nowadays??

Instead, I am going to share a few examples from my own experience which I came across while going through an enterprise based security scan of my code.

Observation 1- Buffer Overflow

Abstract- The program writes outside the bounds of allocated memory, which could corrupt data, crash the program, or lead to the execution of malicious code.

As you can see in line 2 of the method, variable ‘has_storage’ has been declared as an unsigned 32 bit integer and assigned a value. However in line 3, a value is assigned to some index value of it. This is the classic example of possibility of Buffer overflow.

How Buffer Overflow Attacks Work | Netsparker

This code snippet is a part of Google’s Firebase/Messaging pods framework.

Fix

Avoid declaring the variables by keeping such vulnerabilities in mind i.e you can define this as:-

uint32_t  _has_storage_[0];

Observation 2- Privacy Violation: HTTP GET

Abstract- The identified call uses the HTTP GET instead of POST method to send data to the server.

Explanation- HTTP requests which utilize the GET method allow the URL and request parameters to be cached in the browser’s URL cache, intermediary proxies, and server logs. This could expose sensitive information to individuals who do not have appropriate rights to the data.

Example 1: The following code makes an HTTP request using the GET HTTP method instead of POST.


let url = URL(string: “https://www.somesvr.com/someapp/user”)
let request = NSMutableURLRequest(URL: url!)
request.HTTPMethod = “GET”
let connection = NSURLConnection(request:request, delegate:self)

Example 2: If the application uses NSURLRequest then the default HTTP method is GET.

let url = URL(string: “https://www.somesvr.com/someapp/user”)
let request = URLRequest(URL: url!)
let connection = NSURLConnection(request:request, delegate:self)

Since most of us are not aware that while making a URLRequest in Swift, if we do not provide any HTTP method then the default method is “GET” which can be treated as a major vulnerability in many of the Static Code Analyzers.

Fix

Make an extension of the URLRequest class and add a method with some added parameters as per your convenience.

Observation 3- Insecure Storage: HTTP Response Cache Leak

Abstract- The identified method performs a URL request without configuring the URL loading system to prevent the caching of HTTP(S) responses.

Explanation- The HTTP(S) responses may contain sensitive data such as session cookies and API tokens. The URL loading system will cache all the HTTP(S) responses for performance reasons, storing them unencrypted in the {app ID}/Library/Caches/com.mycompany.myapp/Cache.db* files. Developers may think that by setting the diskCapacity or memoryCapacity properties of the URLCache class to 0, they may be effectively disabling the HTTP(S) response cache system. However, the NSURLCache documentation states that both the on-disk and in-memory caches will be truncated to the configured sizes only if the device runs low on memory or disk space. Both settings are meant to be used by the system to free system resources and improve performance, not as a security control.

Fix

The combination of two solutions works best for plumbing these types of leaks. Firstly, after the response has been received, remove all the cache that has been saved to the memory by using this small snippet

Observation 4- Insecure Transport: Weak SSL Protocol

Abstract- The SSLv2, SSLv23, and SSLv3 protocols contain several flaws that make them insecure, so they should not be used to transmit sensitive data.

Explanation- The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision was designed to address the security weaknesses discovered in the previous versions. Use of an insecure version of TLS/SSL will weaken the strength of the data protection and could allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL may exhibit one or more of the following properties:

– No protection against man-in-the-middle attacks
– Same key used for authentication and encryption
– Weak message authentication control
– No protection against TCP connection closing

The presence of these properties may allow an attacker to intercept, modify, or tamper with sensitive data.

Example 1: The following example configures the session to use SSL v3.0:

Fix

In most of the networking libraries that we use in iOS like Alamofire and AFNetworking, the default setting is to use SSL Protocol and hence if we explicitly update the minimum supported protocol in our code to the latest TLS protocol version, then we can easily prevent this vulnerability in our code.

Observation 5- Input Interception: Keyboard Extensions Allowed

Abstract- The application allows third party keyboard extensions to be allowed.

Explanation- Keyboard extensions are allowed to read every single keystroke that a user enters. Third-party keyboards are normally used to ease the text input or to add additional emoticons and they may log what the user enters or even send it to a remote server for processing. Malicious keyboards can also be distributed to act as a key-logger and read every key entered by the user in order to steal sensitive data such as credentials or credit card numbers.

Fix

If you want that no third party keyboard can be installed while using your application, then add this code snippet into your AppDelegate.swift file.

Observation 6- Insecure Storage: Lacking Data Protection

Abstract-  The identified method writes data to a file lacking sufficient encryption settings.

Explanation- Even though all files on an iOS device, including those without an explicitly assigned Data Protection class, are stored in an encrypted form; we can specify NSFileProtectionNone which results in encryption using a key derived solely based on the device’s UID. This leaves such files accessible any time the device is powered on, including when locked with a passcode or when booting. As such, usages of NSFileProtectionNone should be carefully reviewed to determine if further protection with a stricter Data Protection class is warranted.

In the following example, the given data is not protected (accessible anytime the device is powered on):

Fix

-NSFileProtectionCompleteNSDataWritingOptions.DataWritingFileProtectionComplete:
The resource is stored in an encrypted format on disk and cannot be read from, or written to, while the device is locked or booting. It’s available in iOS 4.0 and later.

-NSFileProtectionCompleteUnlessOpenNSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen:
The resource is stored in an encrypted format on disk. Resources can be created while the device is locked, but once closed, cannot be opened again until the device is unlocked. If the resource is opened when unlocked, you may continue to access the resource normally, even if the user locks the device.
Available in iOS 5.0 and later.

-NSFileProtectionCompleteUntilFirstUserAuthentication, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication:
The resource is stored in an encrypted format on disk and cannot be accessed until after the device has booted. After the user unlocks the device for the first time, your app can access the resource and continue to access it even if the user subsequently locks the device.
Available in iOS 5.0 and later.

-NSFileProtectionNoneNSDataWritingOptions.DataWritingFileProtectionNone:
The resource has no special protections associated with it. It can be read from, or written to, at any time.
Available in iOS 4.0 and later.

Oh!! My God… So many observations. Who writes such a vulnerable code anyway??

Me, you??

Let me tell you something folks! Privacy and Security are two important constructs of today’s digital umbrella which covers a huge part of our society. And moving forward we are going to be more dependent on all these digital devices lying around us exploiting the technologies like AR, AI, IoT etc. Did I just sound like Mr. Snowden?? Believe me, I am “No One”(pun intended).

But, it’s the least, we as developers can do to make our code less prone, a little bit more secure by keeping in mind certain techniques while coding. After all, good code is contagious. It spreads.

error: Content is protected !!