Recently, I wrote for one customer a review document on the security of web applications, after which I thought that it would be nice to put it on a general review.
The article was written for non-professionals, so in order to make it more interesting for demanding users of the Habr, I diluted the text with some real-life cases.
This document lists the main vulnerabilities of web applications and how to prevent them; each vulnerability falls into one of the main categories:

• Organizational — the basis of vulnerability is the human factor. This vulnerability is solved with the help of certain rules for working with the site or through special software.
• Designing is the vulnerability of the application itself. These vulnerabilities are eliminated by considering the possibility of an attack during development, most of them can be solved at the level of basic functionality, which allows minimizing the human factor.
• Operation— an attack can be made at the server or infrastructure level, these problems are solved by the administrators of the web sites.

Authentication and site access.

Unstable passwords.

Category: Organizational Vulnerability
Using simple passwords (qwerty, password, date of birth, phone number) allows you to access site management by brute force or social engineering.
In the general case, it is desirable to use automatically generated passwords, but only if there is confidence that a person will be able to remember it, and not write it on a piece of paper and hang it on the monitor.
Otherwise, you should use complex mnemonic passwords: the first letters of verses or songs in a different keyboard layout, with some letters changing to numbers or special characters.

There is also a favorite theme to leave passwords by default, such as root / nothing or admin / admin (in the Yotov egg ), and to think that no one will know about it.
It is best to force you to change "temporary" passwords when you first log in.

Intercept password.

Category: organizational, operational.
Interception of a password can be carried out when transferring it from the user to the server, this is solved by the mandatory use of a secure connection (https, ftps) when working with the server.

I remember Sergey Ryzhikov , speaking on Highload or RIT (I do not remember already), asked who was present to go to the admin panel through a secure connection, and in response not so many hands were raised. From which it can be concluded that a walk through a conference with a wi-fi sniffer can slightly change the runet.

In addition, theft is possible using a so-called “phishing” site, i.e. the site in the user's browser is replaced with an identical one, after entering data into the login form, the password goes to the attacker, in this case it is important to have a "signed site certificate". When using such a certificate, a special company (for example, http://verisign.com ) confirms that this is indeed the site that is supposed to, in addition to the signed certificate, certifies the same to the site user (which is important, for example, when paying). This service costs about $ 800 per year (the cost is affected by the level of protection and credibility of the company, the service provider)

I am amazed all the time by organizations that are too lazy to make a normal certificate, especially in this regard, webmoney is touching. Thank God, now they have already been honored to make a normal certificate, but a month ago, frankly, I juggled from the fact that the browser swears at the site on which I, by the way, keep money. In addition, self-signed certificates can cause various small bugs: for example IE + Flash does not work with them. I killed quite a lot of time, figuring out why the multi-loader stopped working on production, which at the same moment was quietly working on a test server.

Password theft

Category: Organizational
Password theft is accomplished with the help of social engineering or malware.
Prevention rules are pretty commonplace:

• Do not store or transmit the password in the clear, i. Do not send a password to the mail or via ICQ, Skype, etc. It is important to remember that if you send a password, then it is likely to be saved in the archive of the mail or historical messenger.
• Do not remember passwords in the browser or FTP client.
  Viruses that insert malicious code onto a site using stored FTP passwords are common.
• Use antivirus software
• Change passwords regularly

As a separate line, it should be noted that each person who has access to the site must have their own login and password, which will further help to identify the reason for hacking and protect themselves in case of dismissal of an employee.

The big headache of web studios is the passwords from client sites that persist in history, mail archives and shared files on the server. A separate pleasure is any master password that fits half of the sites and is known to managers, developers, their relatives, and a brilliant galaxy of dismissed and dismissed employees. Periodically attempts are made to go through the entire portfolio and finally change the master password for something better, which usually start somewhere in the beginning.
The simplest and most elegant way is to transfer the authorization to the studio server, i.e. You can log in to the site admin with OpenID (not any, but belonging to the studio domain), so each developer knows only his password, and permissions to enter are given centrally. In addition, a problem is solved with the system log, which finally shows who exactly deleted the news, in contrast to the classic case, when everything is done on behalf of some "most important administrator" who is all and at the same time nobody.

Proactive defense

Category: design.
Certain measures should be taken at the level of the site architecture, these measures will allow to partially protect themselves if the password is lost.

IP restriction

Access to the administrative interface should be limited by IP, i.e. Login must be possible only from the internal network of the company.
All other cases (work from home, work on a business trip, etc.) should be introduced as exceptions: it is clearly indicated at what time period, at what time (strangely, when someone comes in from an unofficial IP during working hours), from which IP (if possible) and which user can work with the site.

In fact, it's still a good idea to say goodbye to distant countries and anonymous proxy right away (unless of course you are developing the site Kavkaz Center)

Captcha

Captcha (characters from the image) in the authorization form will reduce the risk that a virus or other malicious program will enter the administrative interface.

The trouble with many captchas, by the way, is the developers' disbelief that the empty line is equal to the empty line, often deleting a session or cleaning some hidden field, you are surprised to find that the smart machine has compared nothing to nothing and missed you further

One-time passwords

The introduction of an additional “temporary” password is also an effective and inexpensive means: for each user, a matrix of random numbers is generated, and when entering or performing a critical operation, you need to enter 2 or more numbers located in a given column and column.
Thus, in the scheme below, it is proposed to enter, for example, a number from the 1st column of the 2nd line and the 3rd column of the 1st line, i.e. 34 and 323 respectively.

12	43	323
34	23	77
348	948	293
657	904	44

This solution allows you to make the interception of a password less dangerous, since the attacker knows only part of the matrix.

Client certificates.

It is possible to restrict access only to users who have a client certificate (i.e., all requests to the server subscribe to EDS).

We are responsible for those who have tamed — keeping track of our personal data, do not forget about the personal data of users.
Turn off automatic filling of fields in which the visitor enters personal data. The touching care of credit card payment aggregators that leave autocomlete in the fields of the card number and CVV2 always touches me, thank you guys, it looks very nice when you want to pay something from someone else's computer.
In general, user data can be illuminated in the most unexpected places. A few years ago, the Yandex RSS reader showed a list of tapes to which the user was subscribed, even though the tape of an authorized user in LJ contained a login and password ( http://bugtraq.ru/ review / archive / 2007 / 01-03-07.html ).
By the way, it is better not to store user data in the same place as these sites, such as the site of the organizing committee of the Olympiad 2014, some time ago I liked to display letters from job seekers in the list of recent news — amusing, I tell you, reading.

Application Vulnerabilities

This section outlines the main possible vulnerabilities in the application code, as well as methods for eliminating them and minimizing the “human factor” during development.

SQL injection

Category: Design
This vulnerability allows an attacker to modify the database query using the entered data. Using this vulnerability, an attacker can choose from a database that is not provided by the developer (which will allow, for example, enter the administrative interface without knowing the password) or replace the data in the database (for example, delete a table or replace tests).
As a rule, this vulnerability is eliminated by escaping data when building a query. In this section, it is highly desirable to initially remove the ability to access the database directly from the code, and work with the database exclusively through a special library that automatically performs the necessary conversions.

I will not restrain and let a small ray of hatred. Once, a third-party office screwed up its service to our site, these nice guys sent us a letter asking us to give them access to the database in order to make a general authorization. We responded to this proposal with an angry refusal and an authorization scheme, equipped with appropriate redirects and EDS.
In response, they complained to our superiors about how paranoid and saboteurs we are, as a result of which the integration of users was postponed to “someday” and decided to launch this whole thing “bye-bye”. What was my surprise when having entered into the password field a single quote on the subnet made by these “knights without fear and reproach,” I received a joyful message about the sql error.
A special piquancy was added by the fact that the system periodically produced beautifully formatted pieces of code in the event of an error, in one of which the comment “Kohl WTF” was found.

Code injection

Category: Design
Occurs when any executable code is connected or generated based on the data entered by the user. Eliminated by the introduction of additional checks, screening and the use of specialized libraries.

If you think that code injection is limited to the textbook bug “include $ _GET ['file']”, I want to upset you a little.

• The code parser can run the code or formulas between times (check once again how your {% username%} will be replaced).
• The template engine can go through the template several times and execute the data (you are sure that you once did not make two passes to perform some kind of sub-template).
• Regular expressions are executed, and they can also be made code injection.

If you are fond of meta programming, and your controller automatically calls methods on the basis of a request, make sure that you cannot call any “wrong” method (I somehow missed such a hole once — the controller could be pushed into endless recursion).

Cross-site script execution

Category: Design
The introduction of the html or javascript code on the site by the attacker due to insufficient verification and conversion of the entered data. Allows you to change the appearance of the site and in some cases, “steal authorization” (get into the administrative or user interface without entering a password).
It is solved by screening data during output, the optimal solution is automatic screening of all information displayed on the page, if the opposite is not explicitly indicated.

XSS is the second “our all”, here you can advise to follow the principle: “everything is forbidden that is not allowed”, which works much better than the principle “everything is not forbidden allowed”, XSS implementation methods are invented one hundred thousand million and who knows how many not yet invented.
Often, people fail to trust the input data, which is especially nice when, after checking a link (for example, for page-by-page navigation), they gather stupidly from a request. For example, the important fact that the line “1aaaa” is forgotten, in many languages, can be easily reduced to the numeral “1”, and instead of “aaa” you can put something worse
As a separate line, I want to mention the setting of the color gamut of sites, I somehow ran into the skin creation system, the author of which was completely unaware of IE’s nice ability to execute javascript code written in exspression.
We should not forget that code injection can also be done in javascript, so one photo site that made it possible to insert comments on a part of a photo did not bother to screen this commentary, as a result a lot of interesting things could be done from the cozy photo page. .
There are many more interesting cases related to webmasters who sympathize with different portals, and allowing to insert a link to their profile, while they are not very thoroughly checked, so if you want, you can enter something like http://myseosite.com/ ? and thus a little fix yourself TIC and PR.

CSRF. Cross Site Requests

Category: Design
This attack is aimed at the fact that the user commits some actions imperceptibly to himself.
The simplest example is that the attacker’s website has a picture whose address is the same as the address of the section deletion; when you go to this page, your browser requests the URL of the image, and if you are authorized in the system, you will unwittingly delete this section.
This problem is solved by introducing a confirmation mechanism, i.e. You can take a certain action only when switching from a certain page, on this page a link is formed with a unique time code, the validity of which is checked by the page on which the action is performed.

We have on one project, users have often become self-withdrawing from communities, the problem was in the malicious iframe'e that led to the suicide page.

Access hidden files

Category: design.
Allows an attacker, in a special way to form a request, to read an arbitrary file on the server.
It is solved by checking the correctness of the file name upon request.

Execution of downloadable files

Category: Operation
Files uploaded to the server can be executed, allowing an attacker with access to the administrator interface to gain full access to the system.
Precautionary measures (implemented at the server administrator level):

• Permission to write only to specific directories on the server
• Disable execution of scripts in this directory

Separately, it should be noted that it is necessary to check and when loading, but it is better to immediately ban the execution of all, and give some nginx.
When downloading, you should take care of both the essence of the file and its name, since the malicious code can be inserted into the image as well.
By the way, malicious code can also be inserted into .htaccess, there is a magic directive php_value auto_prepend_file that can include a php file.

Code disclosure

Category: operation / design
Access to service and development scripts, as well as to the source code, can give an attacker additional information for hacking.

• Location of debug, system and development scripts in open access
• Location of service scripts in open access: programs running with a certain periodicity (on the crown) can be launched from the outside, which makes it possible to create a large load to bring the site down.
• Source code is available for viewing: this vulnerability may be caused by incorrect configuration of the version control system.

A few months ago, thanks to the daddy svn, some inquisitive comrades learned a lot about the leading sites of the Runet, and by the way they wrote on Habré .

Disk full

Category: Design
Due to insufficient input validation or improperly organized caching, an attacker may clog the database or disk with unnecessary information, which will slow down the operation and may cause (if space runs out) the system’s inoperability.

1. Useless requests — this method is a special case of a DDOS attack, the attacker places a code on the site (either using his own or using XSS) that sends a feedback form / vote, or banally automatically accesses this URL. As a result of this attack, the site database or hard disk is filled with data (which, besides, eliminates the accuracy of the survey and disorganizes the support service). It is solved by turning on tags or, in severe cases, captcha (you can turn it on automatically if requests are very frequent).
   
2. Cache sprawl. The result of complex samples is usually cached (stored on disk or in memory to save resources), while the cache is formed based on the input request, if checking the input data is insufficient, you can enter additional parameters, create similar caches. On the one hand, it clogs the disk and memory, and on the other hand, it eliminates the positive effect of caching (that is, it can be regarded as a special case of DOS)
   Solved by more stringent data checking before caching or cache request.

If you like to identify the cache by the query string, be prepared for the fact that by supplying some stupid parameters, someone is very bad, will be able to riddle your cache, and between times and suck.
A special case is the previously described insufficient coercion to the whole, since "001" and "1" are identical tsiferki, but different lines, so that / \ d + / rehexp is so-so, but / ^ [1-9] \ d * $ / - good, suitable regexp.
In addition, when starting to read something, you need to make sure that you can read it, the mail.ru company somehow encountered this problem and started checking the archives for viruses, the fact is that it looks like a small archive, quite accidentally, can contain several terabytes of zeroes (perhaps this is a bike, but there is a reason for reflection).
And the Vkontakte website somehow decided to gossip , and made an invisible iframe on its page with the Runet’s website leading to the site, which made the prize a little popholly, in fact, this sweet act is closer to DDOS, but deserves a mention.

Pseudocryptography

Many people believe that a random number and md5 hash is cryptography. In fact, this is not the case, md5 has long been compromised and for security purposes it is better not to use it.
As for random sequences, they are often not entirely random, which automatically means that they cannot be used, for example, for payment cards.
In particular, the pseudo-random is the GUID generated by the MS SQL server, which is detailed and written in the RSDN .
Also of interest are the cases of the invention of proprietary encryption systems and the resulting common practice to encrypt something and, without going too far, also to decrypt (as an option to sign something with a public key)

Server configuration

Category: Operation
An important issue is the correct configuration of the server and periodic software updates. Administrators should monitor vulnerability messages (bagtraq) and software updates (web server, database server, etc.), as new errors and vulnerabilities are constantly detected.

One day I ran into one organization that insulted itself so much that their server was behind seven locks, but in order to update the site, you had to go there with an archive on a CD. In this case, all the software they had delivered 4 years ago and since then has not been updated, because it is scary and lazy.

DDOS

Category: Operation / Design
One of the most difficult in terms of preventing attacks. The bottom line is that there is a stream of requests to the server (flood), which is why the resources end up trite, and the server cannot handle the load.
As a rule, a DOS attack is distributed and carried out using a botnet: a network of virus-infected computers.
It should be understood that the attack is carried out by special programs, which, if desired, can be modified for a specific task, i.e. An attacker can bypass most of the tricks to protect.
DDOS attack is subject to sale, i.e. An attacker can be anyone who is able to pay the botnet owner
The cost of renting a botnet is rather vague, if previously it was estimated at several thousand USD, now prices have fallen dramatically and there is an offer of $ 100-150 per day of attack (although this implies an advance payment that in such a highly moral business means that the chances of just spending money, quite high). DDOS attacks are divided by the degree of rudeness:

1. Channel overflow — the number of requests is so large that the network connection resources are exhausted.
   Solutions:
   • buying a wider channel (10GBps speed should be enough), besides you need to have a backup channel.
   • directly server resources are protected by filtering by port using a hardware solution.
2. SYN flood.
   The point is that a special TCP packet with a SYN flag must respond with a SYN + ACK packet, and then wait for a response. In the case of a DOS attack response is not received, meanwhile, the server is busy waiting.
   In this case, the 'SYS-reflection` attack can also be used when a SYN packet is sent to a third server with a fake IP address: this does not change the essence, but a SYN / ACK packet will arrive at a periodicity of several minutes, which should be taken into account when blocking by IP.
   Solutions:
   • Using SYN-COOKIE
   • Installing a fast (preferably hardware) frontend that will handle such requests without distracting the application server
   • Limit the time to wait for a response and increase the number of simultaneous connections (within reasonable limits)
   • Calculation about the prohibition of problematic IP addresses.
3. HTTP flood.
   In this case, the application service assumes the main load, as a result, we have a large load.
   Solutions:
   • Separate real users from bots: installing COOKIE, setting flags using javascript or flash, captcha. The latter is not very pleasant for the user, although even Google and Yandex are not averse to this.
     Using your own tricks, you should consider that:
     a) in addition to DOS robots, search engine spiders enter the site, which do not need to be cut off
     b) bots can be programmed to bypass the protection (cookie protects from the simplest, and the most complex can perform javascript), so these solutions are designed to raise the cost of the attack
     c) the load from the protective equipment must be less than if the robot overcame it (first of all, it means captcha optimization)
   • Specialized software and hardware for tracking traffic anomalies
   • Traffic cleaning services — third-party resources ( http://ddef.ru/defence/ , http://highloadlab.ru/services/service_8.html ), which eliminate harmful queries. Some of them (highloadlab) are free.
     It should be noted that all these services strictly monitor the reputation of protected sites, and can refuse if the project is suspicious.

About DDOS has already been written a lot and for the most part sad, bots are getting smarter, more and more of them, Gondor will not stand, etc. In fact, with a serious approach, it is not so terrible (lib.rus.ec comes to a standstill without stopping and even henna), but you should always be prepared for the worst and make a splash page: “we were attacked and DDOS, while we are fighting here in the blood, look at the youtube video about our new services. ”