We will start this topic by saying that the web app architecture is the important area of the security which is frequently overlooked when the security individual apps are appraised. The tiered architectures are commonly used, and when a failure for segregating the different tiers happens, that often means that a single defect in the one tier can be easily exploited to fully compromise the other tiers and therefore the whole app.
So, there is the different range of the security threats which arise in the environment where the multiple apps are hosted on the same infrastructure, or they even share the common components of a wider overreaching app. In such situations, the defects or malicious code within that one app may sometimes be exploited for compromising the entire environment and the other applications which are belonging to the different customers. If you remember, that happens when the recent ”cloud” computing increased the exposure of many organizations to the attack of such kind.
Well, we will here examine a wide range of different architectural configurations and describe how you can exploit defects within the app architectures for advancing your attacks. And before we go further, take a look at the internet security tips and cyber security tips.
Tiered Architectures
It is well known that most of the web applications use a multitiered architecture where the app’s user interface, business logic, and the data storage are divided between the multiple layers. That may cause using the different technologies which are implemented on the different physical computers. The three-tier architecture involves these layers:
-the presentation layer (implements the app’s interface);
-the application layer (implementing the core app logic);
-data layer (storing and processing application data).
There are, of course, the more complicated layer which uses Java for example. Those include, besides the three layers above: the app server layer, authorization and authentication layer, core app framework, business logic layer and much more.
Attacking Tiered Architectures
If the defects exist in the implementation of a multi-tiered architecture, these may definitely introduce security vulnerabilities. What can the multi-tiered model do for you? It can help you to understand and to attack the web app by showing you how to identify where the different security defenses (maybe the input validation) are implemented. It will also help you to know how these may break down across tier boundaries. In that case, you may be able to exploit trust relationship between the different tier for the advance attack from one tier to the another. Also, you can leverage a defect within the one tier for directly undercut the security protections which are implemented in the another tier. Besides that, you have one more option. You will be able for the direct attack on the infrastructure which is supporting the other tiers and therefore to extend your compromise to those tiers.
Securing Tiered Architectures
It is true that multi-tiered architecture can considerably enhance the app’s security if carefully implemented. And how can that be done? It is possible because it can localize the impact of a successful attack. When the architecture is safer and well-secured, the compromise of one tier is likely to lead to complete the compromise of the app.
Shared Hosting and Application Service Providers
There is a huge amount of the organizations which use the external providers to help deliver their web apps to the public. So, those arrangments may range from a simple hosting services in which the organization is given access to the web and the data server. Also, to a full-fledged app service providers (ASPs) that will actively maintain the app on behalf of the organization. It is ideal for small business that does not have the resources or some skills for deploying their own application, but they are used by some high-profile companies for deploying the specific applications.
They have many customers so they typically support them by using the same app’s infrastructure, or at least the one that is closely connected. But, they need to be aware of the following threats:
-it may happen that the malicious customer or even someone from the service provider attempts to interfere with the organization’s application and all of its data;
-it is also seen that an unwriting customer may deploy the vulnerable app which enables the malicious users to compromise that shared infrastructure and thereby attack the organization’s app and its data.
Securing Shared Environments
We talked about how the shared environments introduce nowadays the new types of threats to the app’s security, which are posed by a malicious customer of the same facility and by an unwriting customer who introduces the vulnerabilities into the environment. The shared environment must be very carefully designed in the terms of the customer access, segregation, and trust for addressing this twofold danger.
Besides that, it is a must to implement the controls which are not directly applicable to the context of some single-hosted app.
So how to secure customer access properly? For securing and avoiding the third-party by the malicious customers, the following advice must be applied:
-The remote access mechanism. It should be definitely implemented into a robust authentication and must use cryptographic technologies which are not vulnerable to eavesdropping, and to be fully security hardened.
-What about the individual customer? They need to be fully granted for having the access on a least-privileged basis. So, let’s show it on the example. If a customer is uploading some scripts to a virtually hosted server, he needs to read only and to write the permissions to his own document root and nothing more.
-When the customized app is used for providing the customer’s access, it is highly recommended for it to be subjected to rigorous security requirements and testing in line with its critical role in protecting the security of the shared environment.
It is a must to remember that the customers of the shared environment cannot be trusted for creating only benign functionality that is free of vulnerabilities. Besides that all, the robust solution has to use the authentical controls which we already talked about. So, each of the customer’s app should use a separate operating system account for accessing the filesystem which has read and write access only to that app’s file paths. Also, it is a must to restrict the ability of access powerful system functions and commands. Everything we have said needs to be also implemented within any other shared databases.
Let’s make a summary. I hope you’ve enjoyed this chapter and that you gathered so many new and useful information. I am pretty sure you did. I tried to make it all clear and simple, for your better understanding.
We saw how the security controls which are implemented within the web app architectures represent a range of various opportunities for the application owners to enhance the overall security posture of their deployment. We have also learned that the defects and oversights within an app’s architecture can often enable you to dramatically escalate an attack. It can be done even by moving from one component to another to eventually compromise the entire app.
There is so much for you to hear from us. Stay informed and follow the news!