Application security: it's almost simple

- Give me a certificate that my program is safe.

- No problems! And what did you do for this?
')
“Um ... Well ... This is ... Nothing ..."

“Why do you think she is safe then?”

- Well, you check!

- No problems! All the fun will cost X0000 dollars.

-?!

About the article

In this article, I talk about some of the practices of creating secure software.

The first part is dedicated to secure programming.

On the one hand, secure programming techniques are well known. Accumulated experience of their use, written a lot of literature.

On the other hand, they are not used very often. For many programmers and project managers, they remain not very clear exotic.

The article, of course, does not claim to fully cover this issue. But let it be a small step in the right direction. And, I hope, you will be convinced that in safe programming there is nothing so unusual.

In the second part, I talk about the less well-known aspects of application security. But, in a sense, these aspects are even more important than the use of secure programming techniques.

Attention! The article is large and implies careful reading.

Part I. Safe Programming

Know your technology

Each technology has two sides. One side - the properties that are useful to our user, we use them in our products; the second side is the properties that a hacker can use, the weaknesses of the technology. Sometimes technology is so weak that its use cannot be justified under any circumstances. For example, the gets function in a C program is almost always evil. Other technologies can be used by taking the necessary measures to protect. So using a SQL server could potentially open up the possibility for sql injection. But we know how to deal with this and just have to take the necessary protection measures.

We need to know both sides of our technology. How to make a useful program is the main knowledge of any programmer, thanks to this knowledge we make money. Therefore, it is completely understandable that we devote most of our time to studying this aspect.

But a good specialist understands the other side. We do not have to know how a hacker will attack us, we are not obliged to be able to create an exploit for this or that vulnerability. But we need to understand what our actions can lead to the appearance of vulnerabilities, and how we can avoid it.

On the Internet now there are several good resources devoted to this topic.

One of these resources is The Open Web Application Security Project . As the name implies, the project focuses on web application security, but the same information can also be used when programming in other areas. The site is made in the now popular form of Wikipedia, and consists of separate articles; There are lists of these articles, grouped according to different principles. A pointer to articles grouped by technology can be found at the following address .

I will continue to repeatedly refer to OWASP. This project is a very valuable resource for application security professionals.

A very good source of information is the Common Weakness Enumeration site. The site contains information interesting to us in the form of a catalog that lists the causes of vulnerabilities in software. It is perceived to be more complicated than OWASP, but it may be more convenient, for example, when generating checklists.

Check with these sites regularly. Information about security technology is constantly updated, here as in the looking-glass: to stay in place, you must run as fast as you can.

Use libraries

Do not reinvent the wheel! Of course, we all are very interested to do something of our own. But safe invention leads to very unpleasant consequences, so use proven tools.

Now there is a large variety of libraries. You can find ready-made solutions for almost any task, and you can find both paid libraries and open source libraries.

For example, openssl can be recommended for implementing cryptographic methods. The library is well known, tested to an extent sufficient for most of us, distributed under a free license .

Web developers using Java EE might like ESAPI . This library was created within the framework of the OWASP project already mentioned here; it implements many of the methods necessary to create secure web applications. The library contains functions that filter input data, authenticate users, verify access rights, and much more. The code is licensed under a BSD license that allows for very widespread use.

Unfortunately, ESAPI is not developing now. Nevertheless, this is a well-established library, and there is reason to hope that its support will be resumed.

Perhaps it makes sense to pay attention to another library for JAVA, the Coverity Security Library . The library was released at the end of last year and there are not so many reviews about it. Nevertheless, it was created by a company known in the field of application security, and, one hopes, they understand what they are doing.

These are just some of the features. I mentioned them solely as an example; the list of libraries is far from being limited to them. Moreover, many modern frameworks also contain the necessary functions. Pay attention only to who developed this library, how well it is tested and tested.

Sometimes in the project it is impossible to use other people's libraries. In the extreme (very, very, very extreme!) Write your own, carefully check and test it, ask the experts to check and test, once again carefully check and test yourself. Use functions from this library in your code, do not write new methods every time you need them.

In general, safety is like this: fewer bikes - a better solution.

Do a self test

We are all in a hurry. The code that we are writing now had to be handed over yesterday, therefore the only quality necessary for it is to compile. Well, maybe he still has to do something useful, take some set of tests.

Stop it. When you have just written your code, before compiling it, take a short break, rest, forget about the code. After the break, look at what is written from different angles: check the syntax, the compliance of the code with the corporate standard; check the code logic; check its compliance with safety requirements (“know your technology”, remember?).

You will save a lot of time. Although it seems that time is wasted in vain, it will return due to a significant reduction in debugging the application.

Self-testing is a recognized practice for creating quality software. So it is included in the PSP (Personal Software Process), a process designed specifically to create a quality product in the face of tight time and financial constraints.

Pay attention: vanity is the enemy of not only quality, but also speed.

Use code verification tools

It is human nature to make stupid mistakes. In this case, all programmers know that precisely stupid errors are the hardest to detect: some undelivered semicolon can lead to the loss of a whole day (if not more).

It's hard for a person to remember everything at once. There are a huge number of reasons for vulnerabilities; to avoid problems, we must remember them all, we must check the program for their presence. Moreover, hackers do not stand still: what was considered safe yesterday may be vulnerable today.

Partially reduce problems with stupid errors and rapidly changing world can utilities of automated analysis . These programs scan the code and look for signs of potential security problems. Automated utilities are good because they can quickly and almost without human intervention find many types of vulnerabilities, allowing the programmer to pay more attention to other problems. Often, these utilities can carry out a rather complex analysis that would take a very long time for a person. Some of these features are already built into modern compilers, you just need to know how to turn them on.

Do not just rely too much on automated analysis. Information issued by similar programs should be treated in the same way as we treat compiler warnings. We all know that the absence of a warning does not mean the absence of an error; such scanners do not detect all vulnerabilities, even of the type well known to them. On the other hand, the presence of a warning is not yet evidence of a problem, and a thoughtless desire to get rid of all warnings can sometimes only lead to more serious vulnerabilities.

Automation can free up our time for something more interesting. If part of your work can be charged to a computer, then why not do it?

Test

To be safe, a program must exhibit certain behavior. For example, if you try to enter too long a line, the program must either reject it or cut it; when trying to enter special characters, the data must either be rejected or the characters must be encoded in a special way.

This behavior can be tested. And we get all the benefits of automated program testing: it can be done frequently, practically without human intervention.

I will not give here any links. There are no features in safe behavior testing compared to regular functional testing. You can use all your work, including TDD, continuous integration, and everything else that you know better than me. Of course, you should be able to describe safe behavior (again, “know your technology”).

Not everything can be tested effectively. For example, using the gets () function almost always causes a buffer overflow; This problem can be detected by testing. But it is more efficient to detect it with the help of an automated code scan: simple grep easily copes with it. The example, of course, is highly exaggerated, but it can be a good starting point for considering security testing possibilities.

Testing can not solve all security problems. But if something is possible to test automatically, why not use it?

Do code review

Code revision is the most effective way to detect errors. Moreover, it is most effective both in terms of the number of detected defects and in terms of the cost (time) of their detection. So Steve McConnell in his book "Perfect Code" cites a link to IBM's research, in which they found that one hour invested in code revision stores up to 100 hours of testing and eliminating errors. Although I think that the number 100 will be achieved very rarely, nevertheless, this is a very good reason to think.

Code revision can be organized in different ways. This role can be played by pair programming, and informal viewing of the code by fellow programmers, and by a very formal inspection involving a safe programming specialist. Much depends on the goals: the higher the requirements for the program, the more people should be involved in the audit, the more formally it should be carried out.

The organization of the audit depends on the qualifications of programmers. Obviously, if they themselves are sufficiently familiar with the principles of secure programming, it does not make sense to involve an outside specialist, and an informal procedure may well be enough. On the other hand, the involvement of an outside specialist to participate in highly formalized code inspection can be an important part of the programmer's training program.

And again OWASP. Of course, this project could not bypass such an important methodology side. Therefore, if you are going to conduct a revision of the code in your project (I have not yet convinced you to do this?), The corresponding page of this site is a good starting point.

So you are not doing code review yet? There is no forgiveness for you !!!

Use all measures in the complex

Uh ... Do you have to write something here?

Part II. Security Design

Motivating analogy

Let's take a break from security. One of the most common tasks for programmers is to change an existing program. We are not very often able to create a program from scratch, but to change (“support”) an existing one - as many as you like.

So, we have to change the existing program. And let it be a "significant" change, so that it does not mean, each programmer can easily think out the situation himself.

There is one problem. The program with its initial development was not intended to change. I do not know why: either they didn’t think, or they were in a hurry - it doesn’t matter if there is a result. The program consists of a large number of modules that are highly dependent on each other. By making small changes in one module, we break the others. Familiar?

Is this a serious problem?

Suppose we have a program in 100 lines. I think that every more or less qualified programmer will easily make any change, even a very “significant” one. And it will take him, if not a day, then no more than two or three, it’s ridiculous to even discuss “change”.

Program in 10 thousand lines. The task will not be the easiest, but if you try, you can solve it.

The program is 1 million lines. Here everything is very difficult: you can strongly rest and solve the problem, but it may be faster and cheaper to throw out all the code and write again.

Of course, I took the size of the programs from the ceiling. It is clear that everything will depend on the "materiality" of the changes, and on the degree of neglect of the problem. But we all encounter a similar situation, and each represents how quickly the complexity of modifying a program grows with its size.

Therefore, we all know about SOLID and, possibly, about other similar principles. If the program was designed and developed from the very beginning taking into account these principles, then it becomes much easier to maintain it. For very large programs, designing with further support in general becomes a prerequisite for its capability.

Now back to safety.

Principles of safe architecture and design

Safe has its own "solid". I do not think that this statement will surprise anyone of you: everyone (or almost everyone) knows about the existence of these principles, they are regularly referred to in discussions on this site.

Let me remind these principles:

• simplicity of mechanisms (economy of mechanism);
  
• default security (fail-safe defaults);
  
• complete penetration of protection (complete mediation);
  
• open design;
  
• separation of privilege;
  
• minimum privileges (least privilege);
  
• minimization of resource sharing (least common mechanism);
  
• psychological acceptability.
  

These principles were formulated almost 40 years ago in the article “ The Protection of Information in Computer Systems ”. Now they like to add a few more rules ( example ), but the fact is that these principles have been known for a long time, and they remain true to the present. There are examples of successful solutions built in accordance with these principles.

It would seem, design your health, people safety.

But principles alone are not enough. Building a secure system, knowing only the general principles of security, is possible. But it will resemble the solution of problems in geometry, based only on its axioms. In order for design to be effective, it is very useful to know typical approaches, ready-made solutions.

We have to use templates.

Secure Architecture and Design Templates

In our work there are constantly repetitive tasks. Each system, each program is somewhat similar to many others. And for standard tasks there are standard solutions - templates.

Patterns are good for their verification. Each template arose from experience, it is the result of trial, error, improvement, and removal of found problems. By applying a pattern, we can fairly accurately predict what consequences this will lead to, what benefits it will have, what problems will have to be dealt with.

In programming, well-known design patterns. These are sample solutions to problems arising in the design of programs. Their use greatly simplifies our life: we must bring the task before us to the standard one, and apply the existing, obviously working solution. Therefore, the book "gang of four" - almost mandatory reading for any programmer.

Patterns design business is not limited to: patterns exist at all levels. There are architecture templates (remember, at least MVC), there are code writing templates, there are user interface templates, there are patterns of program behavior. Almost every emerging problem has its own template solutions.

Security also has its own templates. Template solutions are for all levels of building an information system. There are patterns of enterprise security in general, including organizational protection measures; there are templates for building an information system as a purely technical entity; and there are templates for secure applications.

We are, of course, interested in application security patterns. Here you can also talk about different levels: there are patterns of safe behavior, and patterns of the structure of a safe program.

The security of a program is often associated precisely with its safe behavior. It includes, for example, user authentication, authorization checking, input filtering. Behavior is something that can be easily shown, tested; this is why marketers usually “sell” security features exclusively.

But I want to draw the attention of readers to the structure of a safe program. Yes, it is in the shadow: it is difficult to demonstrate, it is difficult to sell.

But security depends on the structure of the program to a lesser extent than on its behavior. From the structure of the program depends on the probability to make a mistake in it; it depends on the structure of the program whether this error will become a vulnerability; it depends on the structure of the program how severe this vulnerability will be. For example, think about which error will lead to more serious consequences: in the code that has access to important data, or in the code that does not have such access?

I think you understand the importance of the architecture and design of the program even without my explanations. Therefore, I dare to recommend you two publications on structural patterns of secure programs.

The first publication is Security Design Patterns ( pdf ). In my opinion, this is one of the most high-quality publications devoted to the structural patterns of safe programs. It was published almost 10 years ago, in 2004, by the Open Group consortium. In this publication, you will find how to design security using templates, as well as a description of many of them.

For example, the description of the “Protected System” template is very interesting. In other sources, it is better known as the “Reference Monitor,” and is very often mentioned in the literature. But, most often, it is mentioned: in most other publications, half a page is dedicated to it. In the Open Group, the use of the “Protected System” template is discussed in great detail, including the possible options for its use.

The second publication is “Secure Design Patterns” ( pdf ). This is more recent information, a report on the work done at the Software Engineering Institute and sponsored by the US Department of Defense.

The SEI report is a catalog of security templates known at the time of publication. And there are three different levels of patterns: architecture patterns, design patterns and implementation patterns. Therefore, the work can be used as a very good source of information on this topic.

There is another literature. But, in my opinion, the two mentioned sources will be enough, at least for a start. Having dealt with the information in them, you can already create significantly more secure programs.

Read, think, apply.

Conclusion

A simple program to make safe is very easy. To do this, you do not need to think a lot, plan: you only need to pay attention to security, apply the safe programming practices described in the first part of this article.

Thinking about the design of the average complexity of the program, you will save yourself a lot of time, money and, possibly, save your reputation.

Quality architecture and design of a complex program is the only way to make it safe.

Remember this when you next plan a new program or refactor an existing one.

PS The article turned out great. I did not divide it into parts, I really wanted to preserve its integrity. I hope it was interesting, and I didn’t download you too much.

As a small bonus, I will add a micro-review of literature on the topic of the article.