Enforcing Security in Networked Applications

There have been many publicized events where a lack of security resulted in exposure of private data, such as social security numbers and other identifying information.  

Important aspects of developing networked applications bear focused attention:

• Any server-side code has ultimate responsibility for validating everything that enters the system, in particular, security credentials. 
• Even for systems that exist entirely within a corporate network, or where a thin or thick client is created in concert with an application’s server-side components, it’s still safest to assume that a client may be malicious.
• Often attacks come from within an organization’s network.  

Think of the server side as the gatekeeper that stands between the network and your data.

Take the Worst-Case Scenario

As you architect and build a system that takes requests over a network connection, consider the worst case and plan for that. Approach it this way:

• Is there a role that your client-side code plays in protecting your data where your data would be compromised if the client’s code were bypassed? 
  • It might be something as simple as JavaScript that validates the range of a number. 
• If the server-side does not also validate the data, it is possible for a malicious client to corrupt your data by bypassing the client code. That is what you want to avoid. 
  • The resulting damage might be minimal, but it could be quite dangerous when the data is part of a security implementation or allows SQL injection.

Consider Security Implications Beyond the Project at Hand

In practice, the risk of corrupted data or a compromised system is often balanced with other considerations, such as the cost of security or the potential for damage. 

Making a system more secure almost always results in trade-offs, including

• Reduced performance
• Additional development effort
• Reduced usability

Perhaps you’re just building a system for fellow employees to sign up for pager rotation, and you secure it with a simple user ID and password.  In this case:

• You decide security is not a concern, since at worst, a breach means the pager rotation schedule is lost and must be recreated, but the potential risk is broader than just the system you are building. 
  • Most people use one or a small number of passwords, and re-use them from system to system. 
  • The result is that the password that some people use for the pager rotation will be the same password that they use for their online trading account or banking account. 

There is risk to your system, but there is additional risk to the users of your system.

The Password Problem

Despite the risks, application developers often do not take the time to encrypt stored passwords.  The best approach is to use existing software for password storage that was built by someone who understands the potential modes of attack.  Issues not apparent to you at first blush are already known and solved. 

To Recap

Hoping for the best is not viable for enforcing the security of networks. Plan for the worst, look beyond the current project, and consider best practices for passwords.