|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 4
Read the whole series on security contexts:
It is impossible to specifically list all the ways that bad design and poor programming can compromise an application's security. The example in the introduction is only one route. Instead, I will define and describe a handful of categories from which most Java application security vulnerabilities arise. These categories fall into two larger camps: implementation-related and design-related flaws.
Implementation-related flaws are introduced into an application during implementation. Caused by careless coding, insufficient understanding of requirements, or general lack of skill, implementation-related errors remain hidden because of inadequate testing and review. However, if the design is sound, you can usually fix the flaw without changing the design.
The most pernicious timing problem is the race condition. A race condition occurs when two threads accessing the same resource aren't properly synchronized. Flaws arise when two interacting threads either leave an object in an inconsistent or invalid state, or when malicious code takes advantage of improperly protected resources being used by another thread. Often the solution is as simple as adding proper synchronization.
Input supplied to a process must be validated before it is used. Although some input comes from trusted sources, for safety's sake, all input should be considered to have come from an untrusted, possibly compromised source. Failure to thoroughly validate input can lead to a number of serious security vulnerabilities.
Good cryptography requires a high-quality source of randomness. Many early Netscape Navigator vulnerabilities directly resulted from an insufficiently random source. Keys generated from this source had an effective key length much shorter than their advertised key length and were therefore easier to crack.
On a more mundane note, the predictability (lack of randomness) of many user-supplied passwords makes them easy to guess. Sometimes sound security consists of weeding out weak passwords.
Security vulnerabilities that arise from implementation flaws are bad enough, but even worse are vulnerabilities that surface from poor design decisions, lack of foresight, or insufficient understanding of the language or library features. These flaws often become so intertwined with the application logic that removing them without killing the patient is difficult. The InterBase flaw mentioned above provides an excellent design-flaw example.
The Java savvy know that the new operator isn't the only way to create new instances. Both deserialization and cloning create fully functional instances. You can use both mechanisms to subvert a class's carefully constructed security by introducing instances that don't play by the rules. It's wise to defeat both cloning and deserialization.