Improve your skills with the help of hacker

 

As enterprises use e-commerce, security is no longer a trivial matter, and it has begun to become an important issue. However, most computer users do not know much about security. Most books devoted to computer security only involve some basic technical issues, such as what is firewall, when to use the DES encryption algorithm or which anti-virus product is the best. Other books are concentrated on current "Hot Topics", such as BackOffice 2000 errors or the "mirsa" virus. Although these topics are very important to users, Our column will focus on the security issues faced by developers.

There are already many good security-related news and overview references. We will not discuss topics that everyone else is discussing or has already discussed. Instead, we focus on developing secure applications. For example, many popular publishing articles discuss what it is, and where, when, and how it is used. In this column, you will learn when, why, and how to integrate cryptographic techniques from the developer's perspective into your applications.

As a developer, you may be primarily responsible for ensuring the security of your system. Especially in today's world, most applications are either connected to the Internet or must coexist with those connected to the Internet. You must pay close attention to the security throughout the development process. Many developers are aware of security during design, but few know how to do it. It is difficult to find good references on How to Write secure applications. It seems that people spread their skills through conversations, but few developers can fully understand them. Most developers who have talked with us acknowledge that they do not know much about security. Almost all developers want to know enough security knowledge to have confidence in the security of their programs.

Our goal is to allow you, developers, to learn the practical knowledge needed to create a security system. Indeed, developers engaged in security products (such as firewalls, intrusion detection systems, and secure Web servers) will find this column useful. However, more than just these developers, any software developer will benefit from this article. You do not have to write security software for the software that requires security. Most of today's software is designed to interact on the network in some way, and as long as the network is involved, security is particularly prominent.

We also intend to use this column to help developers become amateur security analysts. It may not be surprising that many things developers need to understand when creating security code are also related to security analysts. Security is always not that easy. When you create a system that is critical to security, a pair of extra eyes will often help, especially when these eyes are very vigilant against actual security risks.

Various features

Is security a feature that can be added to an existing system? Is it a static software feature that is consistent regardless of the Code environment? The answer to these questions is very clear: no.

Unlike many vendors who use shrinking films to package user products, effective security cannot be screwed into the system like a screw after the system is completed. Security is a feature of the software system in the system. Therefore, security should be taken into account from the very beginning of software design.

Security is like insurance, dependency, reliability, or any other software feature. Just as it is impossible to add a "reliability" module to an unreliable system and then obtain the software without errors, adding security to an application just like another feature is impossible.

Security is the behavior of a complete system in a specific environment. In fact, security is so dependent on the environment that it is entirely possible that a fully secure system can be implemented on a dedicated network and put on the Internet, but it ends in a disaster that is very vulnerable to security. (You must have seen this happen .)

The "insert patch" method is not a good one.

Many well-known software vendors do not seem to understand that security is not a function that can be added. They continue to design and produce products at an astonishing rate (mostly due to Internet time), with little attention to security. They are concerned about security only when their products are exposed (and often sudden) to harm. Then they rushed to create a patch, instead of realizing that security was a better way to consider from the very beginning.

This method does not work in e-commerce applications. Problems include:

Developers can only fix issues they know. Attackers may find issues they will never report to developers.

System Administrators usually do not apply patches because they do not want to change "valid" systems. Sometimes administrators do not even realize that an important patch should be applied to the system.

Suppliers usually rush out of the patch program due to market pressure, so new problems are often introduced in the patch program.

Patches are just symptoms of fixing a problem, and they cannot solve the root cause.

 

Our goal is to help you avoid the desperate situation of trying to fix a problem that has been severely attacked by attackers. The cost of finding and removing errors before releasing a software system is much lower and more effective than the cost of trying to fix the system after the release. By designing a security system, carefully implementing the system, and then fully testing the system before release, you can eliminate these problems and develop a truly secure system that does not rely on patches.

 

Root causes of all security issues

Simply put, software is the root cause of all common computer security problems. If your software is not running properly, you may face reliability, availability, insurance, and security issues. The reason for the complexity of security problems may be that a bad guy is always trying to make your software run abnormally.

Cracker or bad guys who attack security vulnerabilities do not create vulnerabilities. They only attack vulnerabilities and often distribute their attack code extensively in the form of scripts. (By the way, the difference between the hacker and the hacker is that the hacker destroys the hacker, while the hacker writes excellent code. Refer to the "fragment world of hackers and hackers" after this article ".)

Aside from hackers and hackers, security vulnerabilities and vulnerabilities are the result of poor software design and implementation. To avoid writing such poor software, read this column to get information about common errors and good ideas that can help you write safer code.

Back to Top

Content of future columns

We will cover four aspects:

Security Assurance

Write Security Code

Security Testing Technology

Common application security technologies

 

Security Assurance

In the next column, we will introduce the risk analysis methodology, which is much more effective than the insert patching method. In future columns, we will discuss the following topics: How to conduct risk analysis, the importance of security testing, the differences between it and Traditional functional testing, and how to think like a bad guy.

Write Security Code

Most security errors are caused by a few root causes. In future columns, We will warn you about major root causes (such as buffer overflow and contention) so that you can avoid these traps. We will also discuss rare attacks (such as man-in-the-middle) so that you can avoid them through protective programming.

We will also discuss important programming language issues that affect code security, including why the type system works and why Java is better than C, and what is language-based encapsulation. We will also discuss distributed systems and their impact on security, including the security issues of CORBA, COM, and EJB.

Security Testing Technology

Security testing is a good idea-especially because bad guys tend to do this-but there are very few good free or commercial tools available. We will help you make full use of the available tools, and we will also show you how to apply Testing Technology without tools. One technique is static analysis. instead of actually running code, it simply looks at the code to find potential vulnerabilities. Another technique is dynamic analysis. It tests the code by running the code. These two testing technologies are available in the developer toolbox. We will help you determine when to use the technology.

Common security technologies of applications

A common misunderstanding among many system architects is that the approach to system security is ultimately firewall and cryptography. In future columns, we will explain why security is not a password, why it is not as easy as it is, and why firewall and proxy servers are useless.

Mobile Code causes a large number of security issues. We will explain why mobile code security is very important and what will happen in the future. We will also explain how the sandbox (Common Code encapsulation methods) works and why it is not that easy to say. We will involve code signatures. Code signatures have developed very fast recently, especially in the Java 2 world.

Finally, we will explain how to create an automatic anti-theft alarm in your own applications and how modern methods of intrusion detection may help you.

-------------------------------------------------

The fragment world of hackers and hackers

We acknowledge that we are hackers. But please do not prepare to use handcuffs; we do not break into others' machines, read others' emails and erase hard disks. In fact, we (at least when it comes to computers) strictly abide by the law.

The term "hacker" has a positive meaning at first. It originated from MIT's computer science culture in the late 1960s s, where it was used as an honor sign to refer to those who are very good at solving tricky problems through clever programming. For most people in the UNIX development community, this term is a good programmer. Hackers often like to research and play with something and work out how they work.

However, software engineers have some negative opinions on this title. They regard hackers as the equivalent of McGyver on television in the programming world-a person who can solve difficult programming problems as long as they give a fishing wire, a cart match, and two pieces of gum. The idea of software engineers is not to say that hackers are unfriendly, but that hackers write solutions that are barely acceptable and only effective for specific problems. Software engineers think carefully about software design before coding. They believe that hackers are developers who are eager to seek success without adopting reasonable engineering principles.

Ordinary people (including the press) tend to have the opposite idea; hackers are malicious attempts to attack software. According to this definition, a hacker breaks into your machine. Needless to say, many hackers hate this. Is it because the locksmith wants to break into our room and he will be a Night Thief? Of course not. However, we acknowledge that some hackers are unfriendly. They break into others' machines and erase others' disk drives. Fortunately, these people only represent a very small number of expert programmers who think they are hackers.

In the middle of 1980s, hackers did not like the negative meaning of the word to create the word "hacker. Hackers attack software for sinister purposes. Unfortunately, this word is not popular outside the hacker circle. The press does not use it, and it does not prevent a recent film about malicious programmers from being named "hackers" rather than "hackers.

So who is a hacker? We have hinted that some hackers are hackers. In fact, hackers who attack software protection mechanisms to easily distribute pirated copies can also be called hackers. Aside from this protection mechanism, it requires considerable skill. However, most hackers are not hackers-they are just children trying to break into other people's machines.

Some hackers who are interested in security and sexy may obtain a software and attempt to attack it for purely curious purposes. If they do attack it, they will not do anything malicious; instead, they will notify the author of the software so that the problem can be fixed. If they do not notify the author in a reasonable way, they can indeed be called a hacker. Fortunately, most people who find serious security defects do not use their findings to do bad things.

Now, you may want to know What skills hackers have. Do attack software require no important skills? In fact, discovering a new weakness requires skill, but only attacking a known weakness requires no skill. Generally, hackers' programming capabilities are limited to downloading, building, and running programs compiled by others. (Hackers often call this type of hacker a "Beginner script user ".) Hackers access hacking sites, download programs that can be used to break into other machines, and run the programs. This (except for a few enter keys) does not require much skill. Based on our experience, these are generally teenage boys in the anti-rebellion period. Although these people are relatively less skilled, they are still very dangerous.

You may also want to know who wrote the script for the program that the novice user used to attack the software. Is it a hacker? If so, Shouldn't these hackers be called hackers? Yes, Hackers often write most of these programs. Some of these hackers have even turned into hackers for evil purposes. However, many such programs are made public by hackers who believe in the principle of "completely open. The basic idea of this principle is that if all security weaknesses of the software are disclosed, everyone will be encouraged to write safer software.

In the eyes of completely open enthusiasts, developers who see other people's security problems can potentially avoid such problems in their own code. It is often not enough to help developers simply try to explain the key points of security issues. Without examples of what attackers may do, developers cannot fully understand the problem. This is a good reason to be completely open. It is completely public and allows the notified administrator to resolve software issues before the software supplier starts releasing the patch.

Of course, there are also a lot of ideas against the full public. For example, if we use Java to attack the applet, we have successfully responded to the problem (and fixed them quickly) without releasing an attack applet ). Even so, no malicious people do regularly publish actionable attack code, even if they know that their code may be abused. These people generally believe that the benefits of full openness exceed the risks. That's why we don't automatically refer to these people as hackers.

Bytes ------------------------------------------------------------------------------------------------------------------------

 

References

 

• For more information, see the original article on the developerWorks global site.
   
• Securing Java. In particular, read chapter 7th, which provides some guidelines for writing safer Java code.
   
• Internet Gambling error (Internet Gambling Flaw ). The Software security team at Reliable Software Technologies recently made the discovery of security errors headlines for online poker games. This story reflects what the author prefers to do.
   
• The Building Secure Software book updates and expands Gary and John's developerWorks columns, which also includes a large number of new materials. Please purchase one today-your users will thank you

 

Bytes ----------------------------------------------------------------------------------------------------

Author Profile

 

Gary McGraw is vice president of corporate technology at Reliable Software Technologies, based in Dulles, Virginia ). He is engaged in consulting services and research and helps determine the direction of technical research and development. McGraw started from a research scientist at Reliable Software Technologies and focused on Software engineering and computer security. He has a dual-Doctorate Degree in cognitive and computer science from Indiana University and a bachelor's degree in philosophy from the University of Virginia. He has written more than 40 peer-reviewed articles for technical publications and served as a consultant for major e-trade suppliers, including Visa and Federal Reserve, he also served as the Chief Researcher under the sponsorship of the Air Force Research Laboratory, DARPA, the National Science Foundation, and NIST advanced technology projects.

 

 

McGraw is a well-known authority in mobile code Security. In partnership with Princeton Professor Ed Felten, McGraw wrote "Java Security: Hostile Applets, Holes, & Antidotes" (Wiley, 1996) and "Securing Java: Getting down to business with mobile code" (Wiley, 1999 ). McGraw and Dr. Jeffrey Voas, one of the founders of RST, wrote "Software Fault Injection: Inoculating Programs Against Errors" (Wiley, 1998 ). McGraw regularly writes for some popular commercial publications, and its articles are often cited in national publications.

John viable is a senior associate researcher, co-founder of the Software Security Group, and Senior Advisor to Reliable Software Technologies. He is the principal investigator for developing standard programming language security extensions sponsored by DARPA. John has written more than 30 technical articles on software security and testing. He is responsible for finding some well-known security vulnerabilities in major networking and e-commerce products, including recent vulnerabilities in Netscape security. He is also an important member of the open source software community, I have written Mailman, GNU Mailing List Manager, and recently released ITS4 (a tool for finding security vulnerabilities in C and C ++ code ). Visung has a master's degree in computer science from the University of Virginia.