JohnM said:
When I sell my desktop .net application on a CD, and it gets installed on a PC, can that same CD get installed on a server and then used by many different PC's? If that's true is it also true If I sold that application to a classroom teacher all the teacher would need is to buy one from me, put it on a server and let hundreds of students use it. I would miss alot of sales. If this is true, how does someone make a profit from his hard work? Thanks for your time.
John M
there are ways you can protect your application from malicious users. Here are a few techniques that can make your applications immune to the most common types of attacks.
Don't leave it out unnecessarily
One key security consideration is not leaving your information unnecessarily exposed. This means not transmitting or storing information that you don't need to. In other words, nothing is foolproof. If you don't need to send a value across the Internet or store it in a configuration file—even encrypted—then don't. If you give hackers the opportunity, they will find some flaw in your approach; so, don't give them the opportunity. For example, you shouldn't send the users' GUID for the system or their username and password. Select their unique identifier, and don't bother sending across the username and password, which might be stolen.
Keep it unintelligible
Security by obscurity (not letting someone know about a flaw) is not a valid answer. However, making it easy for someone to find points at which to attack is not the answer either. When you must place a crucial piece of information on the client, consider how best to identify the information. Using meaningful names may make sense; however, they may make attacking your application easier. For instance, in a Web application, if you need to pass the user's internal ID to the client, you may want to avoid calling the variable,
UserID. Of course, you should never send the user's ID unencrypted to the client; but, even when you send the encrypted value, you shouldn't make it clear to the client what its purpose is.
Obviously, using some sort of cryptographically sound method of converting the information into unintelligible information is important. Encryption brings with it tamper resistance as well as the ability to obscure the information's meaning. Both are important components of securing your application. However, encryption alone won't prevent every problem from occurring.
Watch for tampering
Being tamper resistant is not the same as being tamper proof. Logging attempts to break through tamper resistance is an important part of an application's defense plan. When designing applications, it is important to create logs of situations when tampering is detected so that system administrators who run your applications can take appropriate responses to tampering attempts.
Logging can be done within the application event log, a database table, or a flat file. The key to logging these types of events is working with system administrators to learn how they will watch for errors. Typically, you'll want to select a way of logging that they are already monitoring—perhaps even using automated tools. Monitoring log files is often one of the most overlooked activities by systems administrators; so, you want to make the process as easy as possible.
Remember that, given enough time unmonitored, the barbarians will crush the gate. They will pour through your defenses and overcome your application's defenses.
Code reviews
One of the best ways to ensure that code is resistant to attack is to have it reviewed by other trusted individuals. An unfortunate fact of software development is that there is still a substantial amount of code that is written by one person and never reviewed or even read by anyone else. As a result, any oversight made by the developer and not caught by testing creates an opportunity for a security problem.
Code reviews allow other developers—with fresh perspectives—to look at the code. When properly focused, code reviews can identify flaws in the code, as well as design flaws, which may allow unintended access to the application. While code reviews are an essential part of good development practice, they are also essential to securing applications.
When performing a code review of someone else's code (or while doing your own coding), you should consider the following:
- Validating Input: What would happen if the value contained in the string wasn't what was expected? What if it had special characters? Could someone cause bad behavior simply by typing something bad into an input field?
- Underflow: What will happen if there aren't enough values? Will the system log an error, or will it accidentally use some random piece of memory? Is it necessary to test how many values are arriving?
- Overflow: What happens when there are more values, or a greater value, than the code is expecting? Does the problem raise an error when detected, or does it randomly fail?
- Looping: A close cousin to overflow is creating situations in which excessive numbers of loops are executed. An intruder might use this to slow down the site so that counter measures can't run, administrators can't be notified, etc.
Explained in One Word - keep your application/s dependable of yourself through installation and registration (web ... ) as much as possible.
But remeber this: there are always people ready to crack your app ... Cheers
