We protect the web application: how to close it from third-party intervention
From the translator: we publish for you an article by Jim Medlock, a programmer and software architect. Medlock talks about the basic ways to protect your application or web service. It is worth noting that this material is likely to be useful for novice programmers. Although if the pros leave their comments - everyone will be grateful.
Why bother about someone hacking the application at all? Yes, if only because those who want to do this over time becomes more and more. These are “ordinary” hackers, for whom overcoming someone's defense is of sports interest, cybercriminals who break services and websites for profit, government organizations.
Over the past few months, many large organizations have been caught in the news after giant leaks of information. Among them, Facebook and its 50 million stolen accounts, FIFA with 3.4 TB of data and 70 million documents, Google with 0.5 million accounts, Marriott Hotels with data of 427 million customers of the entire network.
Skillbox recommends: A two-year hands-on course “I am a PRO web developer . ”
We remind: for all readers of "Habr" - a discount of 10,000 rubles when writing to any Skillbox course on the promotional code "Habr".
Not only the number of hacker attacks grows, but also the amount of damage that cybercriminals inflict. According to experts, the average size of direct and indirect losses, the cause of which is cybercriminals, is $ 3.86 million per successful hack. Of course, this is an average for the market; real numbers vary, and pretty much.
Some more statistics. The damage caused by cybercriminals can be judged by the following data:
- $ 148 - "price" of one stolen account;
- $ 40 million - for 1 million accounts;
- $ 350 million - for 50 million accounts.
Money is not the only argument: think about how long it will take to put everything in order.
Infrastructure security vs. application security
Most of the security measures are aimed at protecting the basis of the IT infrastructure, such as a server, storage, data center. This is necessary, but it is not only their need to be protected.
Security measures for the application itself are also extremely important. They provide a whole range of methods to find, fix, and prevent malicious use of loopholes in your software. It is necessary to highlight these:
- review of the code performed by information security specialists, when the goal is solely to search for problematic places in terms of cybersecurity;
- Blackbox audit based on the application;
- Review of the application architecture before writing the bulk of the code;
- the use of automatic tools that help evaluate protection;
- launching bounty programs that allow third-party specialists to find problem spots.
The most effective measures are based on the concept of layered security. In this case, for each of the protected items using its own set of tools.
You can't do anything with the client-side
The problem is that you can hardly protect your project on the user's side. Modern browsers are vulnerable, despite all the efforts of their creators.
In the case of web services, the weak component of the entire system is the key required for authorization. For example, applications that use the GitHub API must support token authentication. If the offender can get the key in his hands, then he will have all access to the code and projects of the victim on GitHub.
For a frontend developer, the danger is that he is confident in the complete security of his service if measures such as private keys and tokens are provided. All this is good, but all the same browsers are a weak link.
How safe is it to separate security data like keys from the whole project?
Usually, environment variables are used to extract data to a file, for example .env. An additional step is to add the name of such files to .gitignore, which prevents git push commands from being executed for uploading to public repositories, where the file will be open to everyone.
All this is good, but .env files are not encrypted. In the case of the Create React App, they can be checked using the Developer Tools option in the browser, in the build / static / js directory. Here, for example, that we will find out at inspection 0.chunk.js.
As you can see, this approach does not provide particular advantages, in some cases it is better to store important security elements in the source code. There is another attractive scenario where code separation is used to delay the loading of scripts containing environment variables until the user authenticates the application. But if the client computer is compromised, it will not work, because its file system is accessible to hackers.
Unlike the client side, server applications can be protected so that important data does not fall into the hands of intruders. For this, you can use Oauth to gain additional levels of authentication and access control, encryption, and protocols like HTTPS and TLS.
The dilemma about securing application secrets can be solved by implementing the server-side API. It also acts as a proxy server to isolate the client application from service providers, which it also uses. Instead of using private data on the client side to authenticate it in the service, the API is authenticated from the server application, executes queries, and only then returns the results to the client. The private keys or other data are not disclosed to the latter under any circumstances.
A complex approach
Yes, complexity is not just words. In order to provide users with confidence in the reliable protection of their data, careful planning, well-thought-out security strategy, which is based on in-depth protection and attention to detail, is needed.
It is not enough to rely on the “islands of technology”. It is necessary to tie all the elements together, understanding how the whole system will work.
Only in this case the application or service will be safe.