Five security test steps to protect an application

You don't have to find a hacker or decryption expert to test the security of your program, and you don't need to buy a lot of expensive hacking tools. However, you must have a process to identify potential problems. If you follow the five processing steps described in detail below, you can easily discover common development flaws. And once these flaws are discovered, they can be mitigated or eliminated.

　　Step One: Port scan

The first thing you need to do is to do a port scan on both the client and the server to find out which communication ports are open but not needed. The ports used by various services such as FTP, NetBIOS, Echo, GOTD, etc. are typical factors that cause security problems. For TCP and UDP ports, it is common practice to turn off any services or listeners that are not required to run any programs.

Port scanning is used to detect which TCP and UDP ports on the target system are listening, that is, waiting for a connection. Most computers open many of these ports by default, and hackers and crackers often spend a lot of time scanning their targets for port scans to locate listeners, a prelude to their attack. Once these ports are identified, it is not difficult to use them.

The Port Scan tool, commonly called a port scanner, is easily found on the Internet. Many of them are Linux -based. For example, Namp, Strobe, netcat are the better category. My favorite Linux-based port scanner is nump. There are also many Microsoft Windows -based port scanners, where my favorite is Ipswitch's WS-Ping ProPack. WS-Ping Propack is a low-overhead, multipurpose network problem-locating tool that wraps many features into an easy-to-use form.

Once you have the port scanner, complete a full check of all TCP and UDP ports to determine which ports are open. Close all unused ports by comparing the monitored open ports to the ports that the system is running on. Shutting down ports in the Microsoft operating system often requires reconfiguring the operating system 's services or modifying registry settings. UNIX and Linux systems are simple: Usually just comment out a line in the configuration file.

　　Step Two: Check the user account

Next, look at the operating system, any database , and the program itself, paying special attention to the Guest user account, the default account or the simple password account, and the unwanted user ID. This is done because most of the default settings leave a lot of vulnerabilities, creating redundant accounts that can be used to compromise the security of the system. This situation is particularly prominent when using database systems such as Oracle or Web servers such as Microsoft Internet Information Services (IIS).

I have logged into many routes, databases, and applications by using a user ID and password that should not exist or should be banned. For example, several years ago, when testing a simple Web application, I tried to log into the system with the Guest account ID and a blank password. To my surprise, the program is very refreshing to use guest as a legitimate user and allow me to log in. Then I tried several other accounts, such as entering the user ID and password as empty/empty or administrator/administrator, and the results were successful.

With this experience, I always look for the default account and password in each chapter of the software Installation manual. I've created a list of these default accounts and passwords to make sure that you can try everything you've ever found. I do the same for the program itself, create a test user account created by the programmer, and try them out.

Testing these things can help identify ways to compromise your system, and disabling and deleting unnecessary accounts is a way to eliminate the flaws that you find. There is also a similar approach to communication ports: Disable any user IDs that are not required for any system to run. If a user ID cannot be disabled, then at least change its default password so that it is not easily cracked.

You will ask, how to calculate a good password? It is at least six to eight characters in length and contains a special character. Passwords must be long enough to make them hard to crack, but they must be easy to remember-it's hard to do both. I like to use abbreviations or devices that are easy to remember. Never use any easy-to-guess words or idioms, which is a common password error. Similarly, do not use a single word in the dictionary. One of the deepest passwords I remember was rolltide, which I had in

Found on a discarded machine at the University of Alabama (the University sports team's nickname is Crimson Tide).

　　Step three: Check the directory license

After shutting down the unused ports and disabling the extra accounts, double-check the permissions settings for the database and server directories used by the program. Many attacks take advantage of misconfigured permissions, which are often used to attack Web servers.

For example, Web sites that use CGI scripts sometimes allow write access. Through it, a malicious provider can simply place a file in the CGI binary directory. Then he was able to invoke the script file, and the Web server would run it, typically under administrator privileges. Being able to write and execute scripts is very dangerous, and you should be very careful about opening these permissions.

Another example, a few years ago, I tested a very important system in a security lab. By configuring the wrong permissions, I can destroy the entire lab and all 17 machines that are considered safe in a very short period of time. After the port scan, I discovered that each server ran an FTP listener, and each allowed anonymous access so that I could access each server system.

The FTP listener gave me access to the actual password file on each machine, and it was a huge configuration error. Because the permission is set, I can not only download the file that holds the password, but also can make these users "poisoned" by modifying the password in the password file and then passing it to the server to overwrite the source file. Of course I gave myself root access, which gives the machine administrator privileges.

If directory permissions are set correctly, I cannot access anything other than the FTP directory that is assigned to anonymous users. Therefore, I could not get the file that really holds the password, let alone replace it. Of course, if they have ever done any of their own port scans, as I mentioned in step one, then I can't get anywhere in this way.

You don't have to find a hacker or decryption expert to test the security of your program, and you don't need to buy a lot of expensive hacking tools. However, you must have a process to identify potential problems. If you follow the five processing steps described in detail below, you can easily discover common development flaws. And once these flaws are discovered, they can be mitigated or eliminated.

　　Step One: Port scan

The first thing you need to do is to do a port scan on both the client and the server to find out which communication ports are open but not needed. The ports used by various services such as FTP, NetBIOS, Echo, GOTD, etc. are typical factors that cause security problems. For TCP and UDP ports, it is common practice to turn off any services or listeners that are not required to run any programs.

Port scanning is used to detect which TCP and UDP ports on the target system are listening, that is, waiting for a connection. Most computers open many of these ports by default, and hackers and crackers often spend a lot of time scanning their targets for port scans to locate listeners, a prelude to their attack. Once these ports are identified, it is not difficult to use them.

The Port Scan tool, commonly called a port scanner, is easily found on the Internet. Many of them are Linux -based. For example, Namp, Strobe, netcat are the better category. My favorite Linux-based port scanner is nump. There are also many Microsoft Windows -based port scanners, where my favorite is Ipswitch's WS-Ping ProPack. WS-Ping Propack is a low-overhead, multipurpose network problem-locating tool that wraps many features into an easy-to-use form.

Once you have the port scanner, complete a full check of all TCP and UDP ports to determine which ports are open. Close all unused ports by comparing the monitored open ports to the ports that the system is running on. Shutting down ports in the Microsoft operating system often requires reconfiguring the operating system 's services or modifying registry settings. UNIX and Linux systems are simple: Usually just comment out a line in the configuration file.

　　Step Two: Check the user account

Next, look at the operating system, any database , and the program itself, paying special attention to the Guest user account, the default account or the simple password account, and the unwanted user ID. This is done because most of the default settings leave a lot of vulnerabilities, creating redundant accounts that can be used to compromise the security of the system. This situation is particularly prominent when using database systems such as Oracle or Web servers such as Microsoft Internet Information Services (IIS).

I have logged into many routes, databases, and applications by using a user ID and password that should not exist or should be banned. For example, several years ago, when testing a simple Web application, I tried to log into the system with the Guest account ID and a blank password. To my surprise, the program is very refreshing to use guest as a legitimate user and allow me to log in. Then I tried several other accounts, such as entering the user ID and password as empty/empty or administrator/administrator, and the results were successful.

With this experience, I always look for the default account and password in each chapter of the software Installation manual. I've created a list of these default accounts and passwords to make sure that you can try everything you've ever found. I do the same for the program itself, create a test user account created by the programmer, and try them out.

Testing these things can help identify ways to compromise your system, and disabling and deleting unnecessary accounts is a way to eliminate the flaws that you find. There is also a similar approach to communication ports: Disable any user IDs that are not required for any system to run. If a user ID cannot be disabled, then at least change its default password so that it is not easily cracked.

You will ask, how to calculate a good password? It is at least six to eight characters in length and contains a special character. Passwords must be long enough to make them hard to crack, but they must be easy to remember-it's hard to do both. I like to use abbreviations or devices that are easy to remember. Never use any easy-to-guess words or idioms, which is a common password error. Similarly, do not use a single word in the dictionary. One of the deepest passwords I remember was rolltide, which I had in

Found on a discarded machine at the University of Alabama (the University sports team's nickname is Crimson Tide).

　　Step three: Check the directory license

After shutting down the unused ports and disabling the extra accounts, double-check the permissions settings for the database and server directories used by the program. Many attacks take advantage of misconfigured permissions, which are often used to attack Web servers.

For example, Web sites that use CGI scripts sometimes allow write access. Through it, a malicious provider can simply place a file in the CGI binary directory. Then he was able to invoke the script file, and the Web server would run it, typically under administrator privileges. Being able to write and execute scripts is very dangerous, and you should be very careful about opening these permissions.

Another example, a few years ago, I tested a very important system in a security lab. By configuring the wrong permissions, I can destroy the entire lab and all 17 machines that are considered safe in a very short period of time. After the port scan, I discovered that each server ran an FTP listener, and each allowed anonymous access so that I could access each server system.

The FTP listener gave me access to the actual password file on each machine, and it was a huge configuration error. Because the permission is set, I can not only download the file that holds the password, but also can make these users "poisoned" by modifying the password in the password file and then passing it to the server to overwrite the source file. Of course I gave myself root access, which gives the machine administrator privileges.

If directory permissions are set correctly, I cannot access anything other than the FTP directory that is assigned to anonymous users. Therefore, I could not get the file that really holds the password, let alone replace it. Of course, if they have ever done any of their own port scans, as I mentioned in step one, then I can't get anywhere in this way.

Five security test steps to protect the application (GO)