6 Common security pitfalls in architecture design

"Schema Source Address"

In the natural world, congenital defective organisms are always susceptible to bacterial virus intrusion, and robust mobs are more resistant to bacterial viruses, computer systems are the same, if there is a congenital architecture design security flaws, then in the face of cyber attacks, it is more likely to be invaded or destroyed, even because of the design of the structure of the reasons, Some loopholes can not be repaired at all! This article will describe the security pitfalls that need to be avoided in architecting to help our developers design a more secure and robust software architecture. Examples of this article are both hardware architecture, software architecture, and infrastructure, among other things, but the principles apply to all architectures. Below will be from the compatibility design misunderstanding, reduce the cost design misunderstanding, data and code not separate design misunderstanding, closed design misunderstanding, blacklist design misunderstanding, no security as one of the design goals of the misunderstanding, a total of 6 aspects to explore the problem of design safety misunderstanding.

Myth One: Compatibility design

The better-compatible architecture adapts to the needs of future changes, so architects will be very concerned about the architecture's compatibility design, but some compatibility designs can lead to serious security breaches that cannot even be fixed with a simple patch of vulnerability.

Use Apple's USB-C interface design as a case study. The USB-C interface is not only used to realize power supply, but also to support the data transmission of mouse, keyboard and other devices, which simplifies the design structure and facilitates the user's purpose. Google's new Chromebook Pixel also has a USB-C interface, signaling that the industry is basically endorsing the MacBook's USB-C interface design. However, security experts think this is a bad design. At the Black Hat technology conference in 2014, security experts demonstrated an attack on the USB-C interface by inserting a specially crafted USB stick into an Apple computer that uses the USB-C interface, so that the attacker could automatically implant the backdoor or virus into the Apple computer without doing any work. It is very scary to allow the computer to be remotely controlled by an attacker or to automatically destroy files within the computer via a virus. More tragic still behind, Apple has not been able to fix the loophole, why? This is from the use of this loophole, said the attack requires a special USB flash drive, security experts changed the hardware and software of the USB flash drive and content, when the USB drive into the USB-C interface of the Apple Computer, the computer will identify the U disk as a keyboard, and then use the chip in the USB stick and stored attack code, It can be disguised as a keyboard to send control commands to the host, thus fully control the host, regardless of whether the user turned on AutoPlay, can be successful. So the key to the loophole is that the USB stick and keyboard and other devices can share the same interface and computer interaction, there is no way to distinguish between the computer system disguised as a keyboard and the real keyboard, so if not change USB-C interface can be compatible with USB stick, keyboard and other hardware design, they can not repair the vulnerability, To fix the vulnerability you must overturn the original design, so that the USB interface is no longer compatible with the keyboard, mouse input hardware, input class hardware still use the original PS/2 interface or other different interfaces.

Apple's USB-C interface design creates a loophole that must be reversed to fix, so it's a bad design. For hardware and software compatibility design, first, must pay attention to the compatibility of the object is the same class, not the same kind of object is best not strong, apple this design does not control the input device (keyboard) and the data input device (U disk) These two categories of objects, resulting in the creation of this ultra vires loophole; The compatibility designer needs to ensure that the authentication mechanism can recognize different object input, take different processing to different object input, avoid the appearance of the control command input device can disguise the data input device, the code can disguise as the vulnerability of data entry, borrow a classic words-"The circle is different, do not strong capacity."

misunderstanding two: reduce cost design

Architecture designers will be very concerned about the cost of the architecture, to achieve the minimum cost of implementation of the system is an important symbol of the designer level, so the design of the architect has a tendency to reduce the cost of hardware and software, this tendency is not wrong, but if in the wrong place cost, bring great security risk to the system, it is not worth the candle.

For example, here is a scenario in which the server cannot protect against CC attacks because of cost reduction. Many designers will set the load rate of each server is very high, up to 50%-70%, want to reduce the deployment of servers to reduce costs, but in normal business scenarios have such a high load, the CC attacks can easily be paralyzed, security experts have no way to implement security policies on the server to protect against attacks. CC (Challenge Collapsar) is a DDoS attack on the HTTP layer that sends a large number of HTTP layer requests for the purpose of disabling the targeted Web site that is being attacked. Challenge Collapsar's Chinese meaning is to challenge the black hole, you may think its name is a bit strange, here is involved in attack naming and a firewall product entanglement, black hole is a well-known firewall products, meaning is obvious, the name of the black hole firewall can not resist his attack. At present, some of the leading DDoS cleaning equipment security vendors can be based on features to defend some common cc attacks, but for some without data segment features, and there is a large number of proxy IP cc attacks still have no way. This time the focus of the defense battlefield must be transferred to the server, through more business scenarios on the Business Server data, and more easily programmed to implement complex security policy advantages to detect attack requests, for example, we usually in the business scenario, from Henan Province, the number of visits, While attacking, the province's visits increased 10 times times, and we could lose 80% of the traffic to the province, defending against attacks, and minimizing the impact on the business.

As a result, the design guarantees a certain amount of server redundancy, which reduces the probability that the system will be attacked to paralysis at the beginning of the attack, and provides computing resources for the DDoS security expert's security defense strategy. If there are conditions, it is best to deploy the business in the cloud, so that when the attack can dynamically increase the number of servers, both to save costs and to protect against the effective protection of the attack.

Myth Three: The design of data and code not separated

Data and code does not separate means that the data can be executed as code, and the data can be defined by the user (the attacker), that is, the user (the attacker) can customize the code executed on the system, then the attacker can construct Trojan code, as data input to the system, the system executes these Trojan code, The system will be controlled by the attacker, and such a design will pose a significant risk to the system. In our system development process in fact, there are many such cases, let us first look at a design-led upload attack vulnerability case.

For example, an upload attack vulnerability of the design case, the first simple description of the upload attack principle, most of the application system has the ability to upload images or files, attackers use these features to upload a Web trojan, if the directory to upload files have the right to execute scripts, The attacker could then directly get a Webshell to control the Web server. This vulnerability has two necessary conditions, one can be uploaded Trojan, and the other is to store the directory to upload files with the permission to execute the script. Upload is the function of the business needs, even if there are a variety of security filtering, limit Trojan upload, but there are various ways to bypass the filtering attack, more difficult to limit. So the key to the vulnerability is whether the uploaded directory has the ability to execute scripts, many designers will be based on cost reduction considerations, the location of the storage upload files and the Web application on the same server, or even the same directory, so that the uploaded directory and the Web application has the same permissions to execute the script, This results in a high-risk upload vulnerability in the system.

And if the location of the storage upload file is designed on another file server or database with only storage capabilities, separate from the Web application server, so that even if the Trojan is uploaded, the file server cannot execute the script without the means to implement the attack.

Myth four: Closed design

Architect design usually follows the design principles of openness to extensions, and closure of modifications. For the modification of the closure, that is, the external can call the system's interface to use the system's functions, but do not see the internal implementation of the system code, nor the internal implementation of the code to modify. This often gives the designer an illusion, that the external user does not know how the system is implemented, do not know the existence of security flaws, so it is safe to boldly leave many security risks inside, the most common is the use of private encryption algorithm.

Designers often intuitively think that private algorithms have the secret of the algorithm, so security is more than the public commonly used encryption algorithm. But in fact, the secret of private algorithm is also difficult to protect the first, China has an old saying-"The world Foolproof", refers to when your algorithm will be leaked out through teammates, if you think this statement Taixu, to give a practical example, developers like to use GitHub, Is it possible that a pig teammate (possibly himself) will upload all of your algorithms to GitHub and the hacker will miss such a good chance? Of course not, these loopholes are everywhere in the clouds. Second, if the algorithm is not disclosed, the hacker will not know your algorithm? Of course not, the hacker can deduce the cryptographic algorithm by many mathematical derivation, for example, the formula of the cryptographic algorithm is usually as follows:

y= f (x) where F is the encryption algorithm, Y is ciphertext, X is clear text

But as long as there is enough X, y to push the export of F, such as the following set of "X, y" data:

X=[0 0.9375 1.8750 2.8125 3.7500 4.6875 5.6250 6.5625 7.5000

8.4375 9.3750 10.3125 11.2500 12.1875 13.1250 14.0625 15.0000];

y=[0.000000e+000 8.789063E-003 3.515625E-002 7.910156E-002

1.406250E-001 2.197266E-001 3.164063E-001 4.306641E-001

5.625000e-0017.119141e-001 8.789063E-001 1.063477E+000

1.265625E+000 1.485352E+000 1.722656E+000 1.977539E+000 2.250000E+000];

The formula of F can be calculated by using the least squares method of Matlab as follows:

The encryption algorithm is so, the other design is the same, the hacker can always collect a lot of information through various methods of attack target, to know that the first step of the attack is intelligence collection. Therefore, the use of private encryption algorithm does not guarantee the privacy of cryptographic algorithms, the security increase is negligible. In addition, the mathematical complexity of the private algorithm is difficult to achieve and open the same level of common algorithms (for example, the RSA algorithm is "easy to multiply two large prime numbers, but it is extremely difficult to factorization the product"), in the implementation of the algorithm is not as good as the public commonly used algorithms, Therefore, even if the encapsulated private encryption algorithm is not used, encryption should be used to open the common encryption algorithm, the secret of the key and not the secret of the algorithm to ensure security.

Therefore, through this kind of closed design to hide the implementation of the software, thus hiding some security risks is very undesirable! The State Institute of Standards and Technology (NIST) expressly states that "the security of the system should not depend on the secrecy of the execution or its parts," the official agency said, with a clear view of such conduct, and against the secrecy of implementation or implementation to ensure the safety of the product. Software design should be assumed to be open-users and hackers know how the software is implemented, and even if the realization of the software does not endanger the security of the product, through the key or authentication factor to ensure the security of product data.

Myth Five: Blacklist defense

Often designers will know the need to protect against SQL injection and XSS attacks, such as security issues, but in the choice of defense scenarios often go into some misunderstanding, they often choose to use filtering methods to protect against SQL injection and XSS attacks, such as the Blacklist of defense is simple and convenient, the amount of modification is small, And they don't think the hackers are coming in. They underestimate the intelligence and perseverance of hackers, and it turns out that any product that uses filtering to protect against SQL injection and XSS is not a dog.

This bypassed case is ubiquitous in the dark clouds, and there is no hardware firewall, cloud WAF or host-side protection that has not been bypassed, even if the latest announcement that the "Farewell to SQL Injection" Sqlchop is quickly being caught in a cloud-bypass loophole, I also agree with Sqlchop's idea of using data analysis to detect SQL injection to raise the level of protection, but even then it will not escape the fate of being bypassed. The products that such a professional security vendor designed are not going to be bypassed, and what about the SQL injection and XSS attack filtering capabilities that our own developers have developed and deployed on the server? The answer is yes. Therefore, the SQL injection vulnerability should be solved by parameterized query, XSS vulnerability should be used to encode the output of the way to solve, filtering method can only be used as a temporary solution to assist in-depth defense, and must not be alone as a security solution to attack.

Myth Six: Security is not listed as one of the design goals

Compared to the above misunderstanding, most of the design of the biggest misunderstanding is that security is not included in the design of one of the goals, this is the cause of all the above design security problems. There are two main reasons for this misunderstanding, first, architects or designers really do not feel that someone has the ability and patience to attack their products. In my communication with architects, one of the most common words I hear is "impossible!" "This is true for architects of the best Internet companies and architects of the best traditional companies. Architects or designers often use their knowledge to determine whether they can be attacked, but most architects and designers do not have a certain depth of security knowledge, so often make wrong judgments. Hackers are the most geek spirit of the group, in order to dig a loophole for 12 hours continuous debugging, continuous one weeks is not a strange thing, so in front of such a group, must not be bushel, listen to the security architect's advice will be more secure. Second, there is a security breach that does not necessarily happen immediately. Security is only a risk in most cases, it translates into security incidents for some time, and in many cases, even if a security incident, some weak security companies can not even detect and perceive, so the surface of a "harmony" gives our designers an illusion, do not need to do a safe design, Products to my needs are not finished, which has the time to "waste" human security design and development!

So a variety of residual security risks accumulated to a certain extent, or by a fuse incident caused by a large outbreak of security incidents, leading to the enterprise's operation suffered a heavy blow! Whether it is architects and other research and development personnel, or security personnel should not let enterprises go to this step, but should be at the beginning of product design to avoid serious design security problems, in order to ensure product safety level lay the foundation.

6 Common security pitfalls in architecture design