Web application security
The modern world carries thousands of threats and potential dangers at every step and at every point in time. A worldwide network that has become an integral part of our life, is no exception.
Cybercrime is now developed as ever-in fact, almost every company has its own website on the Internet, and an attacker on the network can easily remain completely anonymous.
All companies that have a website on the Internet, are divided into three types:
Those whose site is already broken;
Those whose site has not yet broken;
Those who are familiar with the main lines of attack and defended the application.
The number of threats is increasing in proportion to the growth of business, but as has been shown by many years of practice, 99% of attacks occur through a dozen standard incoming data validation errors or vulnerabilities in installed third-party software components, or banal, by the negligence of system administrators, using the settings and passwords that are installed by default.
Classification of vectors of attacks and vulnerabilities is engaged in the OWASP (Open Web Application Security Project). This is an international non-profit organization focused on the analysis and improvement of the security software.
OWASP created the list of 10 most dangerous vectors of attacks on Web applications, this list was named OWASP TOP10 and it concentrated the most dangerous vulnerabilities that may cost some people a lot of money, or undermining the business reputation, up to the loss of business.
OWASP A1 – Injections
All the data is usually stored in special databases, which are built in the form of queries, most often written in a special query language SQL (Structured Query Language is a structured query language).
Applications use SQL queries to retrieve, add, modify or delete data, for example when editing a user of their personal information or completing a questionnaire on site. With insufficient verification of data from the user, the attacker can embed in a Web interface application form a special code that contains a piece of SQL query.
This type of attack is called injection, in this case, the most common is SQL injection. This is a dangerous vulnerability that allows an attacker to gain access to the database and the ability to read/modify/delete information that is not intended for him.
For example, change together with the name and surname of your account balance, see someone else’s account balance, or steal sensitive personal data.
This vulnerability is a result of insufficient verification of data coming from the user. This allows the attacker to “shove”, for example, in a Web form, specially prepared requests that “deceived” application and allow you to read or write illegal data.
In General, this type of attack has a common name “Validation Errors”, it includes not only SQL injection and we will mention this vector again.
OWASP A2 – Broken Authentication and Session Management
In order to distinguish one user from another, a web application uses so-called session cookies. Once you have entered the login and password and application you propaganda, in the browser remains a special identifier, which makes the server browser in the future on each page request, your web application. So the web application understands that you it is you.
In case your attacker steals ID and have not been implemented in the system checks, let’s say the IP address of the session, or to verify the presence of more than one connection in one session, the attacker will be able to gain access to the system with the rights of your account. And if it’s Internet bank or the Office of the payment system, the consequences of such unauthorized access, you can easily guess yourself.
OWASP A3 – XSS (Cross-Site Scripting)
Cross-site scripting is another error validation of user data, which allows you to pass the JavaScript code to execute in the user’s browser. Attacks of this kind are often also referred to as HTML injections, because the mechanism of their implementation is very similar to SQL injections, but unlike the latter, the injected code is executed in the user’s browser. What this means?
First, the attacker can steal your session cookie, the consequences of which were described in the second paragraph, literally a couple of paragraphs above. It should be noted that not all of the application servers are vulnerable to this type of attack, we’ll talk about it separately in paragraph number 5.
Secondly, it can be stolen data entered into the form on the infected page. And this may be sensitive personal data, or worse, credit card data along with the CVC-code.
In the third, via JavaScript, you can change the data that is located on the page, for example, there may be details for a bank transfer, which the attacker with pleasure and will replace the dummy.
OWASP A4 – Insecure Direct Object References
This type of vulnerability is also a consequence of lack of validation of user data. The gist of it is that when displaying any sensitive data, such as personal messages or customer cards, is used to access the object ID that is passed in the open form in the address bar of the browser, and is not implemented check access rights to objects. For example, there is a page that displays a personal message and it has an address like:
mysite.ru/read_message.jsp?id=123654
Turning over the number after “id =” you can read other people’s personal messages. Exploitation of this vulnerability is very simple and does not require any special skills-just iterate over the number in the browser address bar and enjoy the result. Ironically, but this child disease, sometimes were exposed to fairly large European payment systems.
OWASP A5 – Security Misconfiguration
Web application security requires a secure configuration of all components of the infrastructure: the components of the application (such as frameworks-frameworks), Web server, database server and the platform itself. Server component settings by default are often unsafe and offer opportunities to attack. For example, the theft of a session cookie via JavaScript when XSS attack becomes possible by setting off by default cookie_http only.
If the server is configured correctly and enabled cookie_httponly, get a session cookie via JavaScript is impossible, but often this simple and important setting was missing in such critical areas as private offices of payment systems.
Another example of children’s vulnerability is to use by default settings in the database servers, such as Redis, Memcached and others-closed service can be available on the public IP address of the server, and/or passwords used by the manufacturer installed by default. This allows an attacker to easily read and edit the data, which are often and session cookies (than it is fraught with-we already know) and displayed to users in the browser data (which allows XSS attack and apply).
In addition, the software must be up to date: vulnerabilities find every day in a wide variety of software components-the operating system, web servers, database servers, mail servers etc and even if your application is written correctly and carefully checks all incoming data, and generally, well protected, this does not mean that at one point there is a vulnerability in your operating system or Web server.
OWASP A6 – Sensitive Data Exposure
Many Web applications do not protect sensitive data, such as credit cards and credentials for authentication. Attackers can steal or modify such poorly protected data to use for their own selfish purposes.
The simplest example is the transfer of data via the HTTP protocol. The thing is that the data is transmitted via the HTTP protocol is not encrypted, and when passing data from the user’s computer to the Web server, the data will be quite a lot of different sites: office router or home router, the router, the router provider on the channel, the router in the data center hosting provider server and so on. On each of these nodes can hide malware, so-called sniffer, a program that reads all the traffic and transmits the attacker. And the last scans obtained data on the subject of personal data and credit card data.
Such data should be transmitted solely through HTTPS, what should read the corresponding inscription in the browser address bar.
Another task of SSL certificate (namely so called a special key, which is authentication and encryption in HTTPS) is to confirm that it is issued for this site. If the certificate is expired or tampered with, you will see the following picture:
Another example is the lack of encryption of critical data, such as passwords or credit card numbers. If the data is encrypted, even in case of unauthorized access to the server, the attacker will not be able to steal critical data. Passwords, in particular, should be a one-way hash function is to decode the ciphered is not possible and verify the password occurs through the formation of the entered password and compare it with the existing database.
OWASP A7 – Missing Function Level Access Control
The essence of vulnerability, as the name suggests, is the lack of verification of proper access to the requested object.
Most Web applications check the access rights before you display the data in the user interface. However, the application must perform the same access control checks on the server when you request any function. After all, there are still a lot of ancillary service requests, which are often sent in the background asynchronously, using AJAX technology.
If the query parameters are not sufficiently carefully checked, attackers will be able to forge a request to access data without proper authorization.
Private, and perhaps the most common case of this vulnerability we have already covered in paragraph 4 of our article is the lack of verification of the user’s personal messages.
OWASP A8 – Cross-Site Request Forgery, CSRF/XSRF
CSRF attack vector, also known as XSRF, allows an attacker to perform on behalf of the victim’s actions on the server where additional checks are not implemented.
For example, in some payment system to transfer funds to another account, there is a page view:
demobank.com/transfer_money.jsp?transfer_amount=1000&transfer_account=123456789
where transfer_amount is the sum for translation and transfer_account-account number, which should be transferred to the funds.
If the victim comes to the site, created by an attacker, from her face was secretly sent a request to the above page of the payment system. As a result, the money goes to the account of the attacker, after which are likely to be quickly converted to Bitcoin or transferred to another non-returnable payment system, and get them back.
It is assumed that the victim had to pre-pass authentication in the payment system must be open and active session (say, a payment system page is open in another browser tab).
The problem is quite simple and we will tell you about it in a separate article on CSRF.
OWASP A9 – Using Components with Known Vulnerabilities
Often web applications written using special libraries or frameworks (Engl-framework), which are supplied by third-party companies. In most cases, these components are open source, which means that they are not only you, but also millions of people around the world who are studying works by their source code, including for vulnerabilities. And it is necessary to note that they do this is by no means without success.
Also look for vulnerabilities (and find) in a more low-level system components such as the database server, a web server, and finally, the components of the operating system down to its core.
It is very important to use the latest versions of components and follow the emerging known vulnerabilities on sites like securityfocus.com
OWASP A10 – Unvalidated Redirects and Forwards
Web applications often divert the user from one page to another. In the process can be used improperly verifiable parameters indicating the final destination of the redirect page.
Without proper checks, the attacker can use these pages to redirect the victim to a site which, for example, may have a very similar or indiscernible interface, but will steal your credit card details or other critical sensitive data.
This kind of vulnerabilities, as well as many other listed above is a kind of error checking incoming data (input validation).
