Geekly Articles each Day
📜 ⬆️ ⬇️

Brief introduction to application security

Translation of Scott Arciszewski’s “A Gentle Introduction to Application Security” .

I have sad news for programmers reading this note. But, as you know, there is a blessing in disguise.

News one: if you are a web developer or are just thinking about starting to learn web development, then most likely you don’t think of yourself as a security specialist. Maybe you take into account some security threats, for example, when validating user data. But, most likely, you are still not an expert in this field.

And the second news: if your code is executed on a combat server, it is on the first line of defense of the entire system and, possibly, the entire network. Therefore, it is logical that the application you are developing must be safe.

Suppose you incorrectly handled the inclusion of user data in a database request and, as a result, someone will be able to access private data stored in the database or harm your application. You forgot to screen the data before it was output, or didn’t screen it properly - and “suddenly” your application turned against the users of your client, infecting their computers with malware.
')
In the understanding of many developers, all this often looks like an unnecessary complication of work. The most common argument I heard is: “Our customers do not pay for security; they want a new, beautifully implemented feature released“ just yesterday ”.”

I do not propose to become you an expert in computer security. In the end, it requires at least a certain education. But I want to bring the following thought: thinking about the security of the application is the responsibility of each developer . You can take only one step towards this and stop, and this will be enough for your organization and your customers. The main thing is to make the right first step.

Most often, when examining application security issues, it is advised to read lists of the most common threats, such as OWASP Top10 and SANS Top25. In my opinion, this recommendation does more harm than good. Indeed, in reality there are much more vulnerabilities. For illustration, you can use a kind of joke: “someone managed to hack the planet, using 11 OWASP vulnerabilities, because no one expected this.”

Malefactors think, using schemes, but not checklist. They are looking for the simplest way to achieve their goal, and their goal - being outside the system, to get a privileged position inside it.

If you want to release the application and not be afraid that someone will steal your data, infect your users' computers and use your network resources to spread attacks, then keeping the checklist in your head is hardly a good idea.

Therefore, I suggest looking at security vulnerabilities from a slightly different angle. Compared to the lists of threats, the model described below is better adapted for perception by beginners, and also develops a type of thinking that promotes the development of multi-level protection for the application.

Taxonomic model to describe application vulnerabilities


Instead of creating a checklist of a given size (OWASP Top10, SANS Top25, Paragon Top50, etc.), you can use the same approach used to classify living organisms to systematize application vulnerabilities. Like organisms, many vulnerabilities have features and similarities. The task of embracing the whole system with all the diversity of living things may seem unattainable, but using a high level of abstraction, we can combine them all into a small number of groups. A similar approach can be applied to vulnerabilities. Actually, this is the idea that I want to share in this article.

Below is my way of categorizing vulnerabilities. Even if you are not a very experienced developer, having studied each of them, you can become a more valuable specialist than someone who knows only protection strategies in a specific area, but does not understand the fundamental problem of vulnerability.

1. Violation in separating data from instructions


This category covers most of the vulnerabilities used by hackers of any kind, and includes the following subcategories:


The common thing in all these cases is that the end user (or another device) has the ability to enter some data into the system that changes the semantics of the instructions that process them.

2. Logical errors in the application


Many computer security researchers find application logic less interesting compared to changing the semantics of instructions. However, taking care of eliminating vulnerabilities that could lead to a web server hacking, logical errors are often forgotten.

Logic can be called defective if the data is received blindly, without validation, some steps are skipped, or when going to a new step of the algorithm, the result of the previous step is not checked.

Logical application errors are best illustrated by example.

Suppose you are developing an e-Commerce website that uses Paypal to process credit card payments. For a person who does not have a sufficient understanding of the work of checkout integration, the process looks like this:

  1. The user adds the goods to his cart, selects the Paypal payment method and goes to the payment system website.
  2. Some magic happens.
  3. The user clicks on the link (not unique to him), when clicking on the contents of the basket is marked as paid, and sees the page of the successful payment status.

There are several possible logical errors that can occur here, provided that you have clearly not worked to prevent them. User can:

  1. Add another item to the cart in the amount of -1 with the same price, reducing the total cost to $ 0.
  2. Skip the checkout process, knowing in advance a special link (step 3), and the transaction will automatically become paid.
  3. Add a cheap item to the cart, click on the Paypal link, go back to the store and add a group of expensive items to the cart. Then go to the previously opened Paypal tab and complete your purchase with a smaller amount. At the same time, it is marked as fully paid.

The first problem is fixed by simply checking the input data. In two other cases, only server-to-server API integration will be correct. Instead of relying on the user to follow the link provided to him (which can break even in a perfect world, where no one acts according to malicious intent), your checkout provider will tell your server which products were purchased and what amount was transferred for them .

All attempts at fraud in my example can be detected using manual control, which, unfortunately, does not scale to large volumes of transactions. And why create extra work for your clients. One of the advantages of software is the possibility of using automation. However, its reliability depends on the security of your system.

3. The working environment of your application


Your application does not exist in a vacuum. Its successful operation depends on a large number of other components:


Vulnerabilities in any of these components can weaken or frankly negate the security of your entire application. In this case, the only way to protect is to update the software on time and never use software that is no longer supported by its developers.

As an example, the problem of asymmetry of resources. Most websites physically work on the same machine and will not be able to cope with the load if they receive a large number of requests from thousands of machines at the same time. This is called a DDoS attack. The only effective way to deal with this is at the network level, not at the application level.

4. Encryption vulnerability


Although many encryption-related vulnerabilities may be the result of logical application errors or the incorrect operation of its components, encryption really deserves separate consideration.

For example, comparing two strings without encryption is not special. But you must be sure that when using encryption, this operation will take the same amount of time for different string options. Otherwise, your application becomes vulnerable to timing attack — a type of brute force attack that uses monitoring of the execution time of cryptographic algorithms to optimize brute force. When the developer himself tries to write algorithms using encryption, this can lead to disaster.

Encryption is difficult in itself, so leave it to the experts. It is useful to experiment with encryption to study it, but never put such a code on a combat server, much less recommend it to anyone.

Variety of security vulnerabilities


It is quite possible that there are security issues that I do not know about. It is also likely that there are security issues that do not fit into any of the categories outlined above. Or there are vulnerabilities that can be categorized into several categories.

I believe that my classification of vulnerabilities, trying to cover the whole picture entirely by enlarging categories and reducing their number, is a simpler and clearer way to get a holistic view of application security than to expect developers to learn an arbitrary list of common vulnerabilities for a certain year.

Of course, it is far from perfect. In the end, only the professional community can give answers to the questions which categories should be, where the boundaries should go and how many levels it should have.

All are invited to participate in the improvement of this model.

This is the first step, and if you follow these rules, you will be ready to move forward, in good shape:

  1. Protect instructions from being corrupted by the data they process.
  2. Get complete understanding and no doubt about the logic of your application.
  3. Keep the software of the system in which your application is running up to date and do not rely on software that is no longer supported.
  4. Forget about the independent implementation of any encryption algorithms.

Source: https://habr.com/ru/post/328810/

More articles:


All Articles