Curbing the Security-Related Challenges in Today’s Web Application Development

Main Thoughts

• Web app security starts with adherence to the secure coding practices like OWASP or the SEI Cert Coding practices.
• It is essential to deploy databases on a protected internal network.
• Microservice software architecture is a great deal more secure than monolithic software architecture.
• While Data Encryption should be used wherever it makes sense to use it, in some cases like the storage of credit card data, Data Tokenization is a better option.
• Biometric Identity Verification is the most reliable means of securing user access to a Web application.

Introduction

Cyberthreats are proliferating and growing in sophistication at a staggering rate. This and a series of loud security flops and related public settlements have made the Web application security an ever hot issue.

To counter the existing risks, both Web developers and their clients need to be aware of the full spectrum of the countermeasures they can use. The knowledge of the available security options can help CIOs or CTOs collaborate with external software providers more effectively. With this knowledge, they can also have a better handle on their Web application development projects.

Although many of the generic security aspects are described by the well-known standard secure coding practices like the OWASP or the SEI Cert Coding practices, there is a need to detail the means, techniques, and approaches one can use to meet the related requirements and objectives.

This article will help CIOs, CTOs, and startup founders do exactly this – get the right bearings and see to it that the Web apps they need are designed and developed with enough security in mind.

Building Secure Software Architecture

The very way a Web application is architected can have a very serious impact on its security.

One of the underlying principles in the design of any Web application’s architecture must be the Role-Based Access Control (RBAC) principle, which means that only users with the corresponding access privileges can gain access to certain functionality or sensitive data. The need to implement the RBAC approach throughout your application makes it necessary to come up with a well-thought-out, flexibly configurable, and fully scalable user hierarchy.

The backend of your Web application must reside on an isolated network with strict firewall rules that only allow traffic between “known” hosts and services.

None of the important business logic should be deployed on the frontend – it’s a severe security hazard. Not excluding the possibility to manage a Web app’s business logic directly from its frontend creates the possibility for malicious actors to edit and abuse this business logic.

Microservices

The interrelated tangles of functionality in monolith applications make it possible to find one single vulnerability and gain a hold on the whole of an app and the entirety of the data it contains. Because of this, what works much better is microservice architecture – both security- and scalability-wise.

With a service- or microservice-based architecture, each action is handled by a separate service. Gaining access to one service doesn’t automatically allow accessing any of the other services. Putting it differently, even if a breach does occur, the fallout is unlikely to be very negative.

To illustrate, imagine you have an eCommerce Web application where the actions that make up the Ordering workflow, like address validation, purchase, shipment tracking, and more, are handled by separate microservices. Accessing the address data alone or purchase order placement alone gets the hacker nothing.

Depending on the specific Web app architecture, in some cases, it might be beneficial to have a separate DB for each of your services. This approach would further improve service isolation and mitigate the impact from any potential breaches. Also, one can isolate and protect additionally even those services that interact with one another within the backend. For example, you can do this using encryption.

And, finally, it is also possible to isolate microservices using containers.

Containerization

One way to better secure Web applications would be to use the approach called Containerization.

Under this approach, applications or, in the case of Cloud applications, separate microservices are placed in portable, isolated computing environments or containers. A container holds the full range of the components an application needs to run, including libraries, binaries, configuration files, and dependencies.

Different containerized applications can share the same operational system. They can seamlessly run in different environments (on bare hardware, as part of a Virtual Machine, or in the Cloud) without any additional configuring.

In addition to the ability to deploy applications faster, increased scalability, and better fault isolation, Containerization offers a much higher level of security. Containers prevent any malicious code from entering any other parts of the application or the host operational system.

It is possible to implement real-time anti-malware within a container, or use the Runtime-Self-Protection (RASP) security control.

The RASP control can additionally protect Web applications by analyzing their behavior. The control can take a protective action (for example, instruct a database accordingly when it detects a SQL injection attack), or alert the security personnel responsible for the application if it is set to the corresponding mode.

In addition, the RASP control can also analyze traffic and terminate a user session if a threat is detected. Its most prominent strength is the ability to add an additional layer of protection to the perimeter protection the system has. In essence, RASP can secure the entirety of a containerized app by looking at things like the application logic, event flows, logins, administrative functions, database queries, and more.

Multi-Tier Architecture

For scalability reasons, many businesses opt for multi-tier architecture that allows replacing single system components without having to overhaul the whole of the system functionality. Indeed, multi-tier architecture can take the scalability of your Web application a notch higher.

At the same time, the interactions between the components of the different levels create potential vulnerabilities that can too be exploited by hackers. Because of this, to make multi-tier architecture not only scalable, but also truly secure, it’s necessary to safeguard such inter-tier interactions too.

Some Other Things to Know About Web Application Protection

The web server and database of your Web solution must have the right settings. For example, the standard ports must be changed to non-standard ones. All the ports that are not used must be closed, and access to the system from the outside must be denied.

The choice of a database can play a role to some extent too. The structure of data in relational databases makes it somewhat easier to understand the system architecture. Conversely, with non-relational databases, it is more difficult to get a handle on the business logic.

In the case of Cloud solutions, you can additionally protect the account that has access to your Cloud environment where the network is configured (AWS, GCE, Azure) by implementing two-factor authentication (2 FA) or multi-factor authentication (MFA). Besides,  you can limit access to the network to some specific IPs.

Implementing and Securing the APIs

Simply put, Applied Programming Interfaces or APIs are embeddable pieces of code that enable different Web applications to interact with one another.

Unfortunately, serving as entry points to Web applications, APIs can potentially create avenues for unauthorized access to them. Of all the network components, APIs are usually exposed to dDOS attacks the most and can also become the target of brute-force attacks. Malicious actors can try to modify request identifiers to access other user accounts, launch SQL injection attacks, or take advantage of any excessive data, provided by poorly adjusted APIs.

This makes it imperative to reliably secure all APIs and try to select the more reliable implementation options in implementing this functionality.

The diversity of the related risks makes it necessary to take a comprehensive approach to API security.

First and foremost, one must protect access to APIs. To identify users, it’s better to use 2FA or MFA. To identify user applications, one can use various one-time tokens these applications can include in their API calls. In the latter case, one can use OpenID Connect, JSON Web tokens, SAML, or OAuth 2.0. It should be said that API keys that are often used for the same purpose are much less secure due to the inability to control the way these keys are managed by the party that uses them.

To avert any potential Denial-of-Service (dDoS) and SQL injection attacks one must implement rate limiting and firewall the APIs. The firewall you use should preferably also contain a middleware geo-fencing capability. The more modern approach would be to use a Cloud Web Application Firewall (WAF) that is capable of preventing dDoS attacks, SQL injection attacks, and many other threats.

As to Geo-fencing, it can be very helpful in dealing with dDOS attacks. Geo-fencing allows you to block all traffic from a geography one or multiple attacks are originating from regardless of the number of different IPs being used. You can also automatically apply additional authentication if the locations of the login attempts are a too long distance away from one another. With geo-fencing, you have better safeguards in place 24/7, including those time periods, when you may not have enough staff to quickly respond to  incoming threats.

API Gateways and Web Application Security Features They Can Include

Ensuring API security can be improved and made a lot easier by API gateways. API gateways serve as a single point of access to multiple services and can create a powerful additional protection layer.

API gateways have the ability to protect multiple ports or API endpoints that use different formats (the latter can, incidentally, also be done with the help of a WAF) . They also don’t need any manual tuning every time an API is modified, which greatly reduces the odds of an error being made.

An API gateway can comprise the security means to counter dDos, XSS, and SQL injection attacks, as well as configurable authorization and authentication policies. They can enforce SLAs or configurable business rules that govern the use of the services they grant access to, encrypt traffic using SSL, and include rate limiting functionality and 2FA or MFA. Notably, it is possible to add Biometric Identity Verification to API gateways too.

API gateways should always be protected with web application firewalls. It should also be noted that those API gateways that use open-source components may be less secure and reliable.

All the API traffic must be TLS- or SSL-protected. One must also necessarily use https for any APIs.

Finally, it is definitely advisable to use Restful APIs. In Restful APIs, each call is standalone. This means that it is not linked to any other calls in any way. Even if a hacker does manage to get a hold of the token a call contains (which is immensely difficult to do indeed), the data they can gain access to is unlikely to provide enough context for a serious fraudulent activity.

Using Data Encryption and Other Data Security Means

Data security is of utmost importance at all times and it is key to be aware of the ways to ensure it. The main Data Security approaches include Data Encryption and Data Tokenization.

Data Encryption

Data Encryption represents a premier data security technique that can be applied to data at rest, data in motion, and data in use alike. One can use Data Encryption to secure files, disks, databases, policies, and backups.

Currently, the main modern data encryption algorithms include 4 algorithms: AES, Twofish, Blowfish, and RSA. While all of these algorithms provide roughly the same level of protection, there are several important nuances to know.

The AES algorithm can use keys of three different lengths – 128, 192, and 256 bits. As the more bits a key contains the stronger the encryption, AES 256 is a more preferable option to use.

Unlike AES, Twofish, and Blowfish, RSA is an asymmetric algorithm. This key trait makes it possible to combine it with any of the other three algorithms that are symmetric. Basically, while this may affect your Web application’s processing power some, you can create a virtually unbreakable encryption combination to protect the more sensitive of your data.

As we’ve already mentioned, encryption keys vary in length. The minimum length one can consider as reliable constitutes 128 bits for symmetric keys. However, although asymmetric encryption keys can be a great deal longer, this doesn’t necessarily mean the level of protection they provide equals or exceeds that of a 128-bit or longer symmetric key. While applying the asymmetric RSA algorithm, you should consult your IT provider as to the length of the key that would be sufficient in your case.

Extract, Transform, Load (ETL) and data transformation operations can create temporary vulnerabilities that can be exploited by malicious actors. That is why you need to encrypt any temporary files created during these processes, and erase them as the operations are complete.

Logging security threats can be extremely useful in eliminating gaps in Web applications’ security. Simultaneously, the info collected as a result of security monitoring can be leveraged by hackers. To prevent this, encrypt all your security-related logs too.

In addition to being encrypted, your data in transit must be TLS- or SSL-protected.

Data Tokenization

The modern encryption algorithms we’ve mentioned certainly provide a very high level of protection. However, in those cases, when security is absolutely critical, like, for instance, in the case of credit card and cardholder data or Social Security Numbers, it is better to use a technique called Data Tokenization.

Unlike Data Encryption that essentially represents data scrambling (where the scrambled data can be reverted to a readable format by using a key) data tokenization is replacing the sensitive data elements with tokens. The tokens are randomly generated unique identifiers that are in no way related to the original numbers.

The original data and the tokens that represent it are stored separately. One can store tokens in a well-protected Cloud or on a blockchain. They can be connected with the original data by means of a secure mapping system. Therefore, the loss of theft of a token does not automatically result in data exposure.

Furthermore, in some cases, for example, in the case of card payments via terminals at various businesses, Data Tokenization can be more secure than the point-to-point encryption (P2PE), commonly used for this purpose. Using Data Tokenization from the start of the payment process eliminates the storing of sensitive card data on the vendor’s own IT network that may not be completely protected against hacking attempts.

For Data Tokenization, it is essential that the data tokenization method used be immune to cryptanalysis, direct and brute force attacks, and side channel analysis. Besides, unfortunately, Data Tokenization as a security approach also has several downsides that need to be mitigated. More particularly, it may be hard for software systems that process tokenized data to interact with one another. Some of the data can get distorted. It may also become difficult to scale or exchange tokenized data.

Performing User Authentication

It makes no sense to thoroughly protect a Web application otherwise if the user access to it is not sufficiently protected. Fortunately, modern user authentication technologies allow solving this challenge reliably enough. However, it is critical to know which of these technologies you can really bank on.

The simplest way to authenticate users is to use a conventional password alone. While this is definitely a security hazard, conventional passwords can become an important component of 2FA that represents the minimum sufficient level of protection. In this sense, they should be paid very close attention.

It is better to use conventional passwords that are at least 13 characters long – including capitals, digits, and symbols. At least, your users should be made aware of this and be given such an opportunity. The minimal permissible password length is 8 characters.

No less close attention should be paid to the secondary security factors of 2FA. Of the widespread secondary security factors, a call to a user device is a much more robust security factor than a SMS – an unprotected message hackers are known to sometimes be able to intercept.

If ease of use is not your top priority, you can significantly enhance your security combination by adding a certificate or some other security means on a portable device to it.

The advent of such technologies as Face Recognition and various Identity Verification technologies have taken user access security in Web applications to an entire new level. In addition to often being able to provide very high or 100% accuracy of the verification result, these technologies allow seamlessly creating multi-factor authentication combinations without compromise on the user experience.

However, there are several vastly important nuances that can make or break the effect:

1. It’s pretty dodgy to opt for Face Recognition solutions that are not well-protected against advanced spoofing means like video replays, 3D masks, and deep fakes. While choosing a Face Recognition app for your Web solution, make a point of checking whether they have the right advanced protections, like CNNmodels to detect video replays and a 3D Mask Presentation Attack Detection (PAD) algorithm to analyze the reflectance characteristics of images, or some others.
2. Given the present-day sophistication of spoofing attacks, Identity Verification apps that verify identity by using user selfies, including those made online, cannot be considered as reliable enough for authenticating access to many types of applications.
3. Identity Verification apps that use government IDs can provide a high level of protection but cannot be regarded as a viable option for UX-related reasons.
4. The Biometric Identity Verification methods like Iris Recognition, Fingerprinting, and Vein Recognition (for example, Finger Vein recognition) are extremely reliable and can serve as the primary or, even, single security factor.
5. Voice Recognition is also quite reliable. For greater security, all these methods can be seamlessly combined with other security factors, like conventional passwords or basic 2FA security combinations.

Summing it up, one can say that the most reliable way to secure user access to a Web application is using a 2FA combination that involves a Biometric Identity Verification method.

Using Wall Application Firewalls (WAFs)

Wall Application Firewalls act as intermediaries between users and applications, detecting and intercepting threats that are targeting the application layer of a software system.

To do this, they analyze the incoming http or https requests, and identify and deflect the kinds of attacks the security policy they are governed by includes. Usually, a WAF is capable of detecting and averting attacks, listed among the top 10 in OWASP. This includes injection attacks, broken access control, XXE attacks, XXS attacks, and so on.

WAFs constitute a powerful means of creating a viable first line of defense for a Web application. For protecting a software application comprehensively, they can be used in conjunction with IPS engines or RASP control. However, they still do have several drawbacks that must necessarily be taken into account and mitigated.

First of all, a WAF must be configured very meticulously unless some security gaps still occur.

Secondly, a WAF may be less efficient in countering such types of the OWASP-listed attacks as SQL injections and XXS attacks. Because of this, the other security means you use in conjunction with a WAF must include effective safeguards against these types of attacks.

FAQs

What are the important security features in Web applications?

The more important security features, means, and approaches in Web applications can include API gateways, Wall Application Firewalls (WAFs), containerization, data encryption, data tokenization and more.

What is the most reliable way to secure user access to a Web application?

The most reliable way to verify user identity without affecting the user experience is probably using a 2FA combination that involves a Biometric method as one of the security factors. For example, this combination can be a conventional password + Iris Recognition.

When can Data Tokenization be preferable to Data Encryption in ensuring Secure Web Application Development?

Data tokenization is a better option for securing critical data, like, for example, credit card data. It does not use any key, which makes it impossible to decipher it and eliminates any risks related to key management and storage. Although data tokenization and data encryption are used in conjunction to secure card payments via terminals at various businesses, using data tokenization alone can be more secure and it eliminates storing data on the vendor’s IT network.