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

• Organizational - the basis of vulnerability is the human factor. This vulnerability is resolved using certain rules for working with the site or through special software.
• Design — vulnerability of the application itself. These vulnerabilities are eliminated by taking into account the possibility of an attack during development; most of them can be resolved at the level of basic functionality, which minimizes the human factor.
• Exploitation - an attack can be made at the server or infrastructure level, these problems are solved by website administrators.

Authentication and access to the site.

Insecure passwords.

Category: organizational vulnerability
Using simple passwords (qwerty, password, date of birth, phone number) allows you to access site management by enumerating passwords or social engineering.
In the general case, it is advisable to use automatically generated passwords, but only if there is confidence that the 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 the change of some letters to numbers or special characters.

There is still a favorite topic to leave the default passwords, such as root / nothing or admin / admin (in the Yotovsky egg ), and think that no one will know about it.
It is best to force the "temporary" passwords to be changed on first login.

Password hijacking.

Category: organizational, operational.
The password can be intercepted 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 Sergei Ryzhikov , speaking at Khayload or RIT (I don’t remember already), asked which of those present went to the admin area via a secure connection, and not many hands were raised in response. From which we can conclude that a walk through some conference with a wi-fi sniffer can slightly change the runet.

In addition, theft is possible using the so-called “phishing” site, i.e. the site in the user's browser is replaced with an identical one, after entering data in 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 be, in addition, 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, service provider)

All the time I am surprised by organizations that are too lazy to make a normal certificate, especially in this regard, touches webmoney. Thank God, now they have already managed to make a normal certificate, but a month ago, I honestly cringe from the fact that the browser swears at a site on which I, by the way, keep money. Besides everything else, self-signed certificates can cause different minor bugs: for example a bunch of IE + Flash refuses to work with them. I killed quite a lot of time, figuring out why the multiboot loader, which at the same moment quietly worked on a test server, stopped working on production.

Password theft

Category: Organizational
Password theft is carried out using social engineering or malware.
The rules of prevention are pretty commonplace:

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

As a separate line, it should be noted that each person with access to the site should have their own username and password, which will help to identify the reason for the hack in the future and protect yourself in case of dismissal of an employee.

A big headache for web studios is the passwords from client sites that persist in the history, mail archives and shared files on the server. A special kind of master password is one that fits half of the sites and is known to managers, developers, their relatives, and a brilliant galaxy of resigned and laid-off employees. Periodically, attempts are made to go around the entire portfolio and, finally, change the master password to something better, which is usually tied up somewhere at the very beginning.
The easiest and most elegant way is to transfer authorization to the studio server, i.e. you can enter the admin panel of the site with OpenID (not any, but related to the studio domain), so each developer knows only his password, and access permissions are given centrally. In addition, a problem is solved with the system log, in which it is finally clear who exactly deleted the news, in contrast to the classic case, when everything is done on behalf of some "most important administrator" who is everyone and at the same time nobody.

Proactive defense

Category: design.
Certain measures should be taken at the level of the site’s architecture; these measures will partially protect themselves in the event of a password loss.

IP limit

Access to the administrative interface should be limited by IP, i.e. Entrance should 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, at what time (it is strange when someone comes in from an unofficial IP during office hours), from which IP (if possible) and which user can work with the site.

Actually, it’s still not bad to say “goodbye” to distant countries and anonymous proxies right away (unless of course you develop the Kavkaz Center website)

Captcha

Captcha (symbols from the picture) in the form of authorization 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 unbelief of developers that an empty string is equal to an empty string, often deleting a session or cleaning some hidden field, you are surprised to find that a smart machine compared nothing to nothing, and missed you further

One-time passwords

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

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

This solution allows you to make password interception 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 are signed by EDS).

We are responsible for those whom we tamed — while monitoring your personal data, do not forget about the personal data of users.
Turn off the automatic filling of the fields in which the visitor enters personal data. I am always touched by the touching concern of credit card aggregators who leave autocomlete in the card number and CVV2 fields, thank you guys, it looks very nice when you want to pay something from someone else's computer.
In general, user data can be highlighted in the most unexpected places, a few years ago the Yandex RSS reader showed a list of feeds that the user subscribed to, while the feed of the user authorized in LiveJournal contained a username and password ( http://bugtraq.ru/ review / archive / 2007 / 01-03-07.html ).
By the way, it’s better not to store user data in the same place as these sites, for example, the site of the organizing committee of the 2014 Olympics, some time ago, liked to display letters from job seekers in the list of latest news — funny, I will tell you, reading.

Application vulnerabilities

This section provides the main possible vulnerabilities in the application code, as well as methods for their elimination and minimization of the "human factor" during development.

SQL injection

Category: design
This vulnerability allows an attacker to modify a database request using the entered data. Using this vulnerability, an attacker can select from a database data that is not provided by the developer (which will allow, for example, entering the administrative interface without knowing the password) or substitute data in the database (for example, delete some table or replace tests).
As a rule, this vulnerability is eliminated by data shielding during the assembly of the request. In this context, 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 transformations.

I can not resist and letting a small ray of hatred. Once a third-party office turned to our site to our site, these nice guys sent us a letter asking them to give them access to the database in order to make general authorization. We replied to this proposal with an angry rejection and an authorization scheme equipped with the appropriate redirects and EDS.
In response, they complained to our superiors about what paranoiacs and saboteurs we were, as a result of which the integration of users was transferred to “someday,” and decided to launch this whole thing “for now.” What was my surprise when driving a single quotation mark into the password field on the file made by these “knights without fear and reproach”, I received a joyful message about the sql error.
Particular piquancy was given by the fact that the system periodically issued beautifully formatted pieces of code in case of an error, in one of which the comment “Kolya WTF” was found.

Code injection

Category: designing
Occurs when any executable code is connected or generated based on data entered by the user. It is eliminated through the introduction of additional checks, shielding 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.

• Parser of text or formulas can execute code between cases (check once again how {% 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 in order to perform some kind of subpattern).
• Regular expressions are executed, and code injection can also be done in them.

If you are fond of meta-programming, and your controller automatically calls methods based on the request, make sure that you cannot call any “wrong” method (I once missed a similar hole myself — the controller could be driven into infinite recursion).

Cross-site scripting

Category: designing An
hacker injects html or javascript code into the site 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 best solution is automatic screening of all information displayed on the page, unless otherwise indicated.

XSS is the second “our everything”, here you can advise to follow the principle: "everything that is not allowed is forbidden", which works much better than the principle of "everything that is not forbidden is allowed", one hundred thousand million invented methods of XSS implementation and who knows how many of them not yet invented.
Often, excessive trust in the input data fails people, it looks especially nice when, after checking the links (for example, for page navigation) they are stupidly collected from the request. For example, an important fact is forgotten that the string “1aaaa”, in many languages, can easily be reduced to the number “1”, and instead of “aaa” you can put something worse
I want to mention a separate line for setting the color scheme of sites, I somehow came across a system for creating skins, the author of which was completely unaware of the cute ability of IE to execute javascript code prescribed in exspression.
We must not forget that code injection can also be done in javascript, so one photo site that made it possible to insert comments on the photo’s part didn’t bother to screen this comment, as a result of which a lot of interesting things could be done from the cozy photo page .
Many more interesting cases are connected with webmasters who are sympathetic to different portals, and that allow you to insert a link to your profile, while LJ is a nickname, they often do not check carefully enough, so if you wish, you can enter something like http://myseosite.com/ ? and thereby correct yourself a little TIC and PR.

CSRF Cross site requests

Category: design
This attack is aimed at the fact that the user performs some actions unnoticed by himself.
The simplest example is that on the attacker's site there is a picture whose address matches the delete address of the section, when you go to this page, your browser asks for the URL of the picture, and if you are logged in to the system, you delete this section unnoticed.
This problem is solved by introducing a confirmation mechanism, i.e. you can perform a certain action only when going from a specific page, a link is generated on this page with a unique time code, the validity of which is checked by the page on which the action is performed directly.

On one project, users often began to withdraw from communities, the problem turned out to be a malicious iframe 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.

Executing Downloadable Files

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

• Permission to write only to certain directories on the server
• Disallow scripts in this directory

It should be noted separately that it is necessary to check at boot, but it is better to immediately prohibit the execution of everything, and give it to some nginx.
When downloading, you should take care of both the essence of the file and its name, since the malicious code can also be inserted into the picture.
By the way, malicious code can be inserted into .htaccess, there is a magic directive php_value auto_prepend_file, which can connect a php file.

Code Disclosure

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

• The location of debugging, system and development scripts in the public domain
• Location of service scripts in open access: programs executed with a certain periodicity (on the crown) can be launched from the outside, which makes it possible to create a large load to disable the site.
• 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 Daddy svn some inquisitive comrades learned a lot about leading sites Runet, which is by the way, and wrote on the Habré .

Disk full

Category: design
Due to insufficient verification of input data or improperly organized caching, an attacker may clog the database or disk with unnecessary information, which will slow down the work and may cause (if the space runs out) system inoperability.

1. Useless requests — this method is a frequent case of a DDOS attack, the attacker places on the site (his or her using XSS) a code that sends a feedback / voting form, or he trivially automatically accesses this URL. As a result of this attack, the site database or hard drive is filled with data (which, among other things, levels the reliability of the survey and disorganizes the support service). It is solved by including tags or, in severe cases, captcha (you can turn it on automatically if requests go very often).
   
2. Overgrowing cache. The result of complex samples is usually cached (stored on disk or in memory to save resources), while the cache is formed on the basis of an input request, if the verification of input data is insufficient, you can enter additional parameters to create similar caches. This, on the one hand, clogs up disk and memory, and on the other hand, eliminates the positive effect of caching (i.e., it can be regarded as a special case of DOS) It is
   solved by a more rigorous check of data before caching or requesting a cache.

If you like to identify the cache by the query line, be prepared for the fact that by supplying some stupid parameters, someone is very bad, will be able to spoil your cache and, in the meantime, suck it up.
A special case is the previously described insufficient reduction to the whole, since “001” and “1” are the same digits, but different lines, so that / \ d + / regexp is so-so, but / ^ [1-9] \ d * $ / - good, suitable regexp.
In addition, when you start reading something, you need to make sure that you can read it, the mail.ru company somehow ran into this problem by starting to scan the archives for viruses, the fact is that, apparently, a small archive may contain a few terabytes of toe (maybe it's a bike, but there is reason for reflection).
And the site "Vkontakte" somehow decidedhooligan , and made on his page an invisible iframe with the Runet Prize leading to the site, which made the prize a little stupid, in fact this nice action is closer to DDOS, but deserves a mention.

Pseudocryptography

Many people believe that random number and md5 hash is cryptography. In fact, this is not so, md5 has long been compromised and for security purposes it is better not to use it.
As for random sequences, they often turn out to be 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 described in detail and with expression on RSDN .
Also interesting are the cases of the invention of their own encryption systems and the common practice that follows from this is to encrypt something and without going far also to decrypt (as an option to sign something with a public key)

Server configuration

Category: Operation
An important issue is the correct server configuration 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.

Once I came across one organization that vomited itself so much that their server stood behind seven locks, and in order to update the site, I had to go there with the archive on a CD. At the same time, all the software they had was delivered 4 years ago and has not been updated since, 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 flood of requests to the server (flood), which is why the resources run out trite and the server cannot cope with the load.
As a rule, a DOS attack is distributed and is carried out using a botnet: a network from computers infected with a virus.
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. most of the tricks to protect the attacker can bypass if desired.
DDOS attack is the object of 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 earlier it was estimated at several thousand USD, now prices have fallen sharply and there is a proposal at $ 100-150 per day of attack (though this implies an advance payment, which in such a high-moral business means that the chances are just to spend money, quite high) .DDOS attacks are divided by degree of brutality:

1. Channel overflow — the number of requests is so large that network connection resources are exhausted.
   Solutions:
   • buying a wider channel (10GBps speed should be enough), in addition, you must have a backup channel.
   • directly server resources are protected by filtering by port using a hardware solution.
2. SYN flood.
   The point is that the server should respond to the special TCP packet with the SYN flag with the SYN + ACK packet, and then wait for a response. In the case of DOS, no response is received, meanwhile, the server is busy waiting.
   In this case, a 'SYS-reflection` attack can also be used when a SYN packet is sent to a third server with a fake IP address: it doesn’t change the essence, but a SYN / ACK packet will come in with a frequency of several minutes, which should be considered when blocking by IP.
   Solutions:
   • Using SYN-COOKIE
   • Installing a fast (preferably hardware) front-end that will handle such requests without distracting the application server
   • Limiting response time and increasing the number of simultaneous connections (within reasonable limits)
   • Calculation of the prohibition of problematic IP addresses.
3. HTTP flood.
   In this case, the application service takes up the main load, as a result, we have a large load.
   Solutions:
   • Separation of real users from "bots": setting cookie, setting flags using javascript or flash, captcha. The latter is not very pleasant for the user, although even Google and Yandex do not disdain this.
     Using your own tricks, you should take into account that:
     a) in addition to DOS robots, search engine spiders come to the site, which just does not need to be cut off
     b) the bots can be programmed to bypass protection tools (cookies protect against the simplest ones, and the most complex ones can execute javascript), so these solutions are designed to increase the cost of the attack rather
     c) the load on the means of protection should be less than if the robot overcame it (first of all, captcha optimization is meant)
   • 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 ) that filter out harmful requests. Some of them (highloadlab) are free.
     It should be noted that all these services strictly monitor the reputation of protected sites, and may refuse if the project is suspicious.

Much has been written about DDOS and for the most part sad - bots are getting smarter, there are more and more of them, Gondor will not survive, etc. In fact, with a serious approach, he’s not so scary (lib.rus.ec is being stopped non-stop and at least henna), but you always have to be prepared for the worst and make a splash page: “they attacked us and DDOS while we fight here into the blood, watch a video on youtube about our new services. ”