8 simple rules for developing safer code

By Michael Howard
Source: msdn

I am very honored to have worked with thousands of outstanding developers over the past few years to learn how to write safer software. During this period, I also learned a lot from people who have done well in building security systems, which made me start to think about a problem. I wonder if "Security developers" have the same skills or habits. The answer is yes! This article introducesCodeA series of habits shared by developers.

At present, I am sure that you have read this articleArticlePeople will immediately find out what they do not have. This is very good. I know there are other good ideas. Here is just a list of what I have observed! Therefore, the following describes several typical habits that I have noticed over the years.

Habit 1: take responsibility

This is a long-standing shift in the "no silver bullet" viewpoint, which was proposed by Fred Brookes 25 years ago in his book "man-month myth. Whether or not your product can be sufficiently secure depends on you. Anyone else or any outstanding tool orProgramming LanguageAll security risks cannot be solved. Don't misunderstand what I mean, I like itSource codeAnalysis tools, but they cannot magically fix all your security vulnerabilities. Only you can do this yourself.

Only developers who create security design and write security code can build security products. Finally, write the code by yourself. Tools cannot be used by individuals to complete this task. Therefore, the security of your products is your responsibility! The Blaster and CodeRed worms use personal code (see figure 1 ).

Figure 1 The weak code is written by a person. Remember to carefully check all the code, and all the code may be attacked. It doesn't matter. It's okay to be attacked. The key is, will your code be damaged? Only you can decide the final result. Therefore, your code must satisfy you. You must be confident in the quality of your code, so you can rest assured at night, because you know that if you are under attack, you are fully prepared to prevent code from being damaged.

If possible, ask a security expert to perform a professional review of your code. Do not let people who do not know anything about security check your code, and do not expect them to be able to identify security errors and vulnerabilities. Leave plenty of time for people who really know security to check your code.

Don't be at your own risk. You should seek help when you need help. As I mentioned earlier, you should not rely solely on tools, but use all available resources. Run all available source code analysis tools for your code, and do so frequently. Use all the defensive language structures and library skills available. For example, in C #, package network-oriented code that executes array access. The Array Index comes from network requests and uses the checked operator to detect possible integers.AlgorithmError.

Habit 2: Never trust Data

I have already said this for countless times, but I want to repeat it again: All input is untrusted until it is proved. Looking at the most frustrating security vulnerabilities, you will find that the most common feature of them is that developers trust the input data. The problem is that your Code assumes that the data is reliable. What if your assumptions are incorrect? Your applicationProgramIt is likely to crash. In severe cases, attackers may insert malicious code in your process and disrupt your process.

A security system is defined as a system that executes only the required tasks and does not execute other tasks. This must be a bit odd. When the input data has a trust issue, you will often have the system execute other tasks. According to a rough Analysis of Common Vulnerabilities and disclosure (CVE) data (cve.mitre.org), from 2001 to 2004, 47% of all security vulnerabilities tracked by CVE are input trust issues. The most notable problems are buffer overflow, integer algorithm errors, cross-site scripting, and SQL insertion errors. We began to see new variants of this vulnerability, such as the XPath insertion vulnerability and the Lightweight Directory Access Protocol (LDAP) insertion vulnerability.

You can correct the input trust according to several simple rules. First, do not look at the errors you know. This assumes that you know all the errors and can predict all future errors. An error can be found, but the condition is that this is not your only defense method. A better policy is to keep the input within the correct range you know. For advanced languages such as C # And Perl, I like to use regular expressions to ensure this.

Second, discard the known errors. For example, if someone remotely requests a file through your code and the file name contains uncertain characters (such as: Or \), reject the request. Do not tell the attacker the cause; just say "the file cannot be found.

Finally, data purification is not applicable in all cases. For example, on a Web server, you must encode the output of input that may be untrusted in HTML.

Habit 3: Simulate threats to your code

You should have a threat model, right? With the threat model, you can understand the risks that your software may face and ensure that you have the appropriate measures to reduce risks. However, the benefits of Threat modeling are not limited to security design. Threat models can also help you ensure code quality. The threat model can tell you the source of data. Is the data remote or local? Are data from anonymous users, trusted (verified) users, and administrators?

With this information, you can determine whether your defense measures are in place. For example, the code that can be accessed by anonymous users and remote users is preferably very secure. This does not mean that the code that only the local administrator can access should be insecure. I mean remote code that can be accessed (especially the code that runs by default) it must be extremely secure, which means providing more defense measures, reviewing code in more detail, and paying more attention to code details. In addition, the threat model can also tell you the characteristics of protected data. For example, high-value business data and personally identifiable information should be strictly protected. Are your defense measures in place?

Make sure that your threat model is accurate and up-to-date, then determine all the entry points of your code, and follow the principle of accessibility (remote or local, high or low permissions (or no permissions) users. First, you need to perform the most in-depth review of the code that can be accessed by the most people. Finally, all code is reviewed along the anonymous data path. In other words, data is tracked along the path starting from each anonymous accessible entry point to check the code accuracy.

Habit 4: Always advance

The security environment is constantly changing. It seems that a new variant of security issues will occur every week. This means that you must constantly evolve and understand new threats and defense measures, otherwise you will have to bear the consequences.

A few simple strategies to stay ahead of the curve are frequently read excellent books on software security. At the same time, it is better to learn from your past mistakes and from others' mistakes. To do this, you can read BugTraq-go to securityfocus.com and agree to receive BugTraq published content through your inbox. However, be sure to follow the following advice: Create an inbox rule to transfer published content to a specific folder for processing. This is very important.

Habit 5: Fuzzy!

Fuzzy processing is a testing technique designed to identify reliability errors. It has been confirmed that 1% of reliability errors are security vulnerabilities and are likely to be exploited! Of course, buffer overflow may cause the application to crash, but assuming there is a well-designed malicious load, the application may not crash, and attackers may run the Code as they wish. In this regard, our motto is "Today's denial of service is tomorrow's code execution ".

Accidental luck or fuzzy processing can identify almost all file parsing errors/vulnerabilities. Microsoft parses multiple file formats such as xls, PPT, Doc, and BMP, and discovers multiple security vulnerabilities. Most vendors have similar vulnerabilities, because parsing complex data structures is a very complicated task, and complicated code may have errors, some of which may expose security vulnerabilities.

You must blur all the code for parsing files and network traffic. What is the significance of the file format in Microsoft Security development lifecycle (SDL. You must use a file fuzzy processing program to perform fuzzy processing on all the parsers by 100,000 iterations of incorrect files. Currently, there are some good fuzzy processing programs in my book "secure development lifecycle" (microsoft.com/mspress/books/8753.asp), co-authored by Steve lipner, we provide a file fuzzy processing program and C ++ source code.

Pay attention to the obfuscation process. If a crash occurs, do not think it is just a crash. A large part of these so-called crashes are asking someone to write vulnerabilities. Therefore, do not simply regard a crash as "just a crash ".

Habit 6: Do not write Insecure code

In Microsoft, we use the quality control concept to help reduce the possibility that developers can inject vulnerable code into the product. Quality control is to run a set of source code analysis tools on the code, and then register them to mark all problems. All detected problems must be fixed before registration. You can also execute strict code rules, such as blocking the use of Disabled functions. For example, you cannot call strcpy or strncat, and useless encryption is not allowed. (Microsoft has disabled more than 100 C runtime functions for new code !) For example, in terms of encryption algorithms, we do not allow the use of DES (the key length is too short), md4 or MD5 in the new Code (they have been cracked ), unless specified in industry standards.

Do not re-invent features. If you have the code to parse a specific file format, you do not need two or three sets of parsing code. You only need one set of parsing code, make it powerful enough and bind it to a form that can be used between multiple projects.

Finally, remember that tools cannot replace people to learn how to write security code. This is why security and privacy education are so important. You need to have a thorough understanding of these concepts and make judgments on the calls and insights that your tools cannot perform.

Habit 7: Asymmetrical identification strategies

This is my favorite habit. Remember, as a software developer, security risks will be detrimental to you. I like to call it "attacker's advantage and defender's embarrassment". You need to ensure that the code and design are 100% accurate within 100% of the time, which is impossible. What's worse, you must achieve this unattainable goal within a fixed budget, in addition, the requirements for support, compatibility, accessibility, and other "capabilities" must be taken into account. Attackers can find out the error for a long enough time, and then announce to the world that your application is insecure.

In Habit 6, I once mentioned that you should stop writing new Insecure code. For Habit 7, you should pay attention to all the code, because attackers will attack all the code, no matter what time period the code is. Take some time to view the old Code, identify security vulnerabilities, and seriously consider the deprecated old uneasiness feature. If you are using a flexible development method, you should consider sending one or more professionals to fix the old code so that the quality is equal to that of the new Code.

Habit 8: Use the best tool as much as possible

Finally, try to use the best tool. I like source code analysis tools, and I like all technologies that help me write safer code. As I mentioned, tools are not omnipotent, but they will be helpful. It will be of great help! The tool can also help to measure the problems caused by source code analysis. Tools can quickly scan a large amount of code, much faster than manual. In addition, this can also make you feel how bad some code is ".

One of my favorite skills is to compile code with the highest possible warning level, for example, when using Visual C ++? Use the/W4 warning level, or use the-Wall warning level when using gcc. If you find a large number of warnings in the code, there may be other errors not found in the code compilation program or other tools. For this type of code, you should perform a more detailed security check before providing the code (see Habit 3 ).

I found that my dear Microsoft internal and external developers have these eight good habits. These habits will not make you a top-notch security developer, but they will certainly help you!

URL: http://dev.yesky.com/267/2656767.shtml