Main architectural patterns of web applications and web services using the example of banking systems

Today, web applications are firmly integrated into our daily lives. We not only use them as games and information resources, but also as means of orders and payments. Naturally, by conducting online payments, registrations and other similar actions, we transfer part of our personal data, as well as card data, phones, etc. Once in the hands of attackers, this data can cause irreparable harm. In this regard, the protection of web applications and services is seen as a very important aspect of modern network security. The content of this paper will be useful both to specialists in the field of information security and to ordinary users.


Introduction
Before analyzing the security of any web applications, we need to consider their features and differences [1,2].
The application itself, for example, a client bank, as the most interesting for attackers, is a program that can be installed on a smartphone or other gadget so that at any time you can perform the necessary actions, such as:  control the balance and the movement of funds;  monitor expenditures;  transfer funds;  quickly find the nearest branches, ATMs and payment terminals. Banking applications greatly simplify life for people, but at the same time pose a threat to bank customers. This is especially true in our time, when the number of cybercrime is growing every day and these crimes are mainly aimed at direct or indirect money making.
The most popular is remote banking (terminals, ATM, POS terminals, Internet and mobile banking). All these options of work with a bank contain web services or web applications, as well as the workplaces of operators [3][4][5].

Typology of banking systems
The following may be the users:  client;  employee;  partner. There are the following types of user interaction:  customer access to services;  employee access to automated systems;  data publication by external users;  data exchange between automated systems. By the location of the system in the network infrastructure, all systems may be divided into:  external (available via the network);  internal. This does not end with the typology of banking systems, but it should be borne in mind that each automated system has a web interface or uses certain web protocols.
Remote banking is divided into two main types:  Internet and mobile banking;  ATM and self-service kiosks. It should be borne in mind that there are different types of clients and servers, hence, the client may be:  thick;  thin.

Thin and thick clients
A feature of a thick client is that the system processes most of the information on the user's computer or on some other device. In case of a thick client, most of the information is stored on the user's device as temporary files. Since most of the data is processed on the user's computer, this mode is very demanding of the data channel.
The thin client performs all the actions on the server, the user only displays the received information. This mode of operation does not require large resources of both the system and the communication channel [6,7].
In turn, the server is subdivided into:  web application;  web service. The left image shows an example of a web application, the right image shows a web service.

Web system components
There are the following main components of a web application:  Browser and plugins;  Code (client, server);  Web Server;  Application server and framework;

MVP: Model -View -Presenter
MVPa user interface design template that was developed to facilitate automatic modular testing and improve the division of responsibility in presentation logic (separation of logic from display). The Presenter element in this template takes over the proxy function (similar to the MVC controller) and is responsible for managing user interface events (for example, using the mouse) in the same way as in other templates the View usually does.
MVVM: Model -View -ViewModel MVVM is used to separate the model and its view, which is necessary to change them separately from each other. For example, the developer specifies the logic for working with data, and the designer accordingly works with the user interface.

Interactions in the web services architecture
The web service architecture has two types of implementation, or in other words two styles of interaction: 1) REST Example of Rest request: PUT /services/payment/23 HTTP/1.1 Content-type: applicaiton/json {"to":31, "amount:"100.00"} 2) SOAP The Soap query will look slightly different: POST /url HTTP/1.

Differences between web applications and web services
The web application uses:  HTTP(S)  Internet and Intranet  "Live Client" The Web service uses:  SOAP via arbitrary protocol (in practice -HTTP (S))  Intranetmore often  "Client-sutomation"

Conclusion
The problems with the security of web applications, in particular the protocols that are the basis of these applications, arose due to the fact that during the creation of the HTTP protocol no one thought that users would attack each other and do so quite actively.
HTTP was originally created to access and receive data from the provider:  HTTPstateless, the server is not interested in client status;  Solution options (cookies, server sessionsanalysis of headers, sessions in parameters, hidden parameters).