Time flies..it is amazing to know, yesterday marked the 15th anniversary of Design Patterns: Elements of Reusable Object-Oriented Software by Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides), a seminal work in object-oriented software design and development that changed the way how we think and solve software implementation problems. In simpler terms., Design patterns is all about adopting to proven solutions evolved from prior experiences and the known bestpractices/pitfalls without ending up reinvent the wheel ! In my experience, using design patterns helped understanding the architecture and design the software right at the first attempt and resulting reusable code artifacts – easier to reuse with subsequent design and development process.
When Chris and I started our security patterns work… unthinkably..the GoF patterns and its core principles has always been our primary source of guidance for evolving the Security Patterns catalog. With 14+ years passed by, the Design patterns book has never gone out off my sight and always remained in my reaching distance… when so many other books collecting dust in my shelf ! Now, my shameless promotion… about celebrating the 15th anniversary of Design Patterns - Prentice Hall/Addison Wesley is bringing out a series of interviews (featuring GoF and others), articles and takes this opportuntity to further influencing the relevance of Design patterns books with 30% off on the cover price.. Here you go:
One thing I noticed lately…is lot of interest about understanding the usage of ‘Obfuscated Transfer Object (OTO) ‘ from Core Security Patterns. I got multiple emails about its code and implementation .. understandably there is a growing security concern about using Transfer Object (aka Value Object) that passes security-sensitive data elements between Java EE tiers (especially between Presentation/Business/Persistence), when the application components does’nt run in a co-existing environment and risks associated with getting captured in console messages, log files and by rogue administrators. Think about “User Profile” or “Credit Card” or any other sensitive data in transit, it becomes quite critical to ensure privy of the data with appropriate data protection in place. When we wrote Core Security Patterns, Chris and I discussed more about this pattern and its implementation than anything else….agreed, this has its own implementation complexities . The worst you could see is, if you screw up the implementation it masks all the Java EE components from consuming the data elements of the passed OTO…. from a security perspective, it is a good thing as it fails safely.
Let’s dig into the finer details of why and how you would choose to implement an Obfuscated Transfer Object:
In simpler terms, Obfuscated Transfer Object allows to define data elements within it that are to be protected using mechanisms to prevent purposeful or inadvertent unauthorized access to its data. The means of protection can vary between applications or implementations depending on your target business requirements. The OTO provides the producers and consumers of the data can agree upon the sensitive data
elements that need to be protected and on their means of access. OTO will then take the responsibility of protecting that data from any intervening components that it is passed to on its way between producer and consumer. For example, Credit card and other sensitive information can be protected from being accidentally dumped to a log file or audit trail, or worse, such as being captured and stored for malicious purposes.
Although there are several ways to implement OTO, the two easier ways we found to implement OTO are Masked List Strategy and Sealed Object/Encryption Strategy.
In this strategy, the client sets data as name-value (NV) pairs in the Obfuscated Transfer Object. Internally, the Obfuscated Transfer Object maintains two maps, one for holding NV pairs that should be obfuscated and another for NV pairs that do not require obfuscation. In addition to the two maps, the Obfuscated Transfer Object contains a list of NV pair names that should be protected. Data passed in with names corresponding to names in the masked list, are placed in the map for the obfuscated data. This map is then protected. In the sequence above, when the Component logs the ObfuscatedTransferObject, the data in the obfuscated map is not logged, and thus it is protected.
With encryption Strategy for Obfuscated Transfer Object provides the highest level of protection for the data elements protected within. The data elements are stored in a Data Map, and then the Data Map as a whole is encrypted using a symmetric key. To retrieve the Data Map and the elements within it, the consumer must supply a symmetric key identical to the one used by the producer to seal the Data Map.
private SealedObject sealedMap;
// Seal object
HashMap map = sealedMap.getObject(cipher);
// Unseal object
sealedMap = new SealedObject(map, cipher);
As shown above, we can implement this using Java Sealed Object class that allows to easily encrypt objects by passing in a serialized object and a Cipher object in the constructor. The serialized object can then be retrieved by either passing in an identical Cipher or a Key object that can be used to recreate the Cipher. This encapsulates all of the underlying work associated with encrypting and decrypting objects. The only issue remaining is the management of symmetric keys within the application. This poses a significant challenge because it requires the producers and consumers to share symmetric keys without providing any intermediary components with access to those keys. This may be simple or overwhelmingly complex depending on the architecture of the application and the structure of the component trust model. Use this strategy with caution, because the key-management issues may be harder to overcome than architecting the application again to eliminate the need for the Sealed Object .
Hope this helped my two EU friends…who keep pestering me last two days via email. Due to my contractual obligations with Prentice Hall, I cannot dump the contents and source code in my blog…so I leave the rest to your way and you know where to look for . Also don’t ask how it is being implemented in Microsoft .NET – that’s not my forte.
Few weeks ago, US Dept. of Homeland security (National Cyber Security Division) in collaboration with SANS Institute/MITRE teams worked together and released a list of 25 dangerous programming errors as common security flaws, which opens doors for easy exploitation. My first look at this list, I thought it is a old wine in a new bottle as the document sounded a bit more high-level without applied countermeasures and reality checks. The list did go extra mile highlighting the mitigation strategies and countermeasures. For those follow OWASP Top 10 (Most compelling), the CWE Top 25 list is a bit more augmented to include the weakest links of security in target resource and client/server environment. At the outset, the Top 25 list certainly helps our budding developers on understanding the potential weaknesses and vulnerabilities arise due to poor coding practices.
Here is the list of SANS/MITRE’s Top 25 Most Dangerous Programming Errors, in no particular order…
1. Improper Input Validation
2. Improper Encoding or Escaping of Output
3. Failure to Preserve SQL Query Structure (SQL Injection)
4. Failure to Preserve Web Page Structure (Cross-site Scripting)
5. Failure to Preserve OS Command Structure (OS Command Injection)
6. Cleartext Transmission of Sensitive Information
7. Cross-Site Request Forgery (CSRF)
8. Race Condition
9. Error Message Information Leak
10. Failure to Constrain Operations within the Bounds of a Memory Buffer
11. External Control of Critical State Data
12. External Control of File Name or Path
13. Untrusted Search Path
14. Failure to Control Generation of Code (Code Injection)
15. Download of Code Without Integrity Check
16. Improper Resource Shutdown or Release
17. Improper Initialization
18. Incorrect Calculation
19. Improper Access Control (Authorization)
20. Use of a Broken or Risky Cryptographic Algorithm
21. Hard-Coded Password
22. Insecure Permission Assignment for Critical Resource
23. Use of Insufficiently Random Values
24. Execution with Unnecessary Privileges
25. Client-Side Enforcement of Server-Side Security
It is an impressive list…that leaves me with some hard questions, when it comes to how to implement the required safeguards and countermeasures – Yes, the Devil is always in the Implementation details as there is No Magic Silver Bullet and it becomes critical to the developer to choose, adopt and practice the appropriate “Security Design and Best Practices” that identifies the safeguard and helps proactively defend against those known errors. As a developer – in the first place you must understand – how to bake-in security in your application choosing the relevant “Security patterns, Best practices, Pitfalls and Reality checks”…for your target application development and deployment environment.
This gives me another opportunity for my shameless book promotion (is here), especially for those who is interested in knowing the security patterns and require implementation guidance for securing Java/J2EE/Web Services environments.
After long time, last week Chris and I joined together at Newyork for presenting a session on “Security By Default” at “Information Security Conference – 2006″. The overall attendance in the conference was’nt great…. but we did have some participation in our session. Chris and I did’nt forget to have fun especially the good food and drinks at couple of upscale restaurants at NY city. Here is our presentation for your reading pleasure – Security By Default – Patterns-driven Security Design.
This week, Chris and I will be participating in JavaRanch online discussion forum to share our Core Security Patterns work and answer questions from the JavaRanch developer community particularly those with SECURITY focus. The discussion will start Tuesday, January 10th 2006 and end on Friday January 13th 2006.
As a surprise, We’ll be selecting four random posters in this forum to win a free copy of Core Security Patterns book provided by Prentice Hall PTR.
This morning, a friend of mine forwarded a note by Jimmy Nilsson (a Microsoft Patterns Guru) about “Core Security Patterns”, at http://msdn.microsoft.com/architecture/. It is truly a pleasant surprise…
Jimmy Nilsson, Microsoft solution Architect writes…
I have been asked a couple of times about a book about security patterns when I have given my patterns course. I’m afraid I really can’t say that security is my field at all, but from the little I do know I didn’t think that there was such a book. Anyway, the other day “Core Security Patterns” dropped down on my desk. Perhaps it’s just the book they were looking for.
Here is the link to Mr.Nilsson’s blog – http://jimmynilsson.com/blog/
Thank you, Mr.Nilsson and MSDN. We appreciate those nice words.