At the time of writing this I am sitting on the train home after attending the jDays 2016, a two-day conference packed with talks about Java and related technologies. Me and two of my fellow colleagues had a really nice time there and right now I feel quite stuffed with information that will need some time to sink in. One of the keynote speakers actually pointed out that sleeping and resting are important ingredients for accommodating what you are trying to learn, and fortunately those ingredients are perfectly in line with what my mind is signaling right now.
But prior to resting there is one thing that I need to put down in words right away. Being a fan of Domain-Driven Design (DDD) for quite some years now I am glad that I attended a talk about the concept of Domain-Driven Security (DDS) with the irresistible name "Arm yourself with Domain Driven Security. It's time to slay some security trolls..." by Daniel Deogun and Dan Bergh Johnsson. In the next couple of paragraphs I will attempt to pass on my understanding of the concept. If the notion of DDD is new to you then I warmly recommend you to read up on it. For me I found DDD to be an eye opener to say the least.
Now, the overall idea behind DDS is that we can use DDD as a way tackle various security challenges that we all have to deal with in some way or another, for example input validation, cross-site scripting or SQL injections. And the really nice part of this is that there is no technical wizardry or mysterious frameworks here - it all comes down to modeling the domain properly. Let me describe this with an injection attack example inspired from the talk I refereed to earlier. Here we go.
In a simple on-line registration page for a cat owner community there is an input field where you are asked to fill in the name of your favorite cat. Everything works fine and the community site is coming along nicely with an ever-growing user base, but then one day a terrible thing happened. Someone had injected JavaScript code in the cat name input field which made the browser redirect to a dog owner community page whenever the cat name was supposed to be displayed on the screen. Under the hood, the value in the cat name input field had been persisted as is, and when retrieved from the database to be displayed the JavaScript code executed, redirecting the browser.
The cat owner community was not pleased.
If the cat owner community instead had designed the application according to the DDS they would most probably not have ended up in this situation. A cat name is a domain concept in its own that clearly differ from a string in that it cannot contain weird characters such as "<" or ">". And if you think about it, does the concept of a "string" really have any meaning in the domain of cat owners? Probably not. Moreover, numbers are probably not be something that the should allow in a cat name. With such business rules in place, we can define a class - for instance CatName - within the domain model that enforces all of these rules in its constructor.
We now repeat the injection attack described above with our new domain model construct CatName in place. The attacker enters the terrible script into the input field and submits the form. The string containing the JavaScript code, including the "<" and ">" characters, are passed on down towards the domain model, eventually to be mapped to the domain model concept CatName. Depending on how the cat naming rule is enforced, an exception could be thrown or any characters that aren't letters are filtered away from the string. In any case, we can be sure that a CatName instance will never, ever contain malicious JavaScript code.
What I just tried to explain is just one example of security challenges that DDS aims to tackle. And the great thing is that much of DDS really comes for free if you just do DDD properly. Just think about the example above - the injection attack was avoided as a consequence of thorough domain modeling work a la DDD. The restrictions and rules enforced by the domain model saved the day for many cat owners.
For me, the talk about DDS was yet another piece of evidence that DDD is worth the extra modeling work up front. Through exploiting the ideas in DDD we can take a proactive stance to fight security challenges by simply doing our domain modeling work properly.
If you want to have a look at this particular talk it will be available on the jDays 2016 site in a couple of weeks. I strongly recommend watching it!
This blog post was authored by Martin Moberg.
Inga kommentarer:
Skicka en kommentar