We all know we have people like Anonymous, LulzSec, and NSA around. With this in mind, shouldn't we start thinking about the security of our systems? Well, of course. But, could you turn your knowledge of DDD into an advantage for understanding and counteracting security vulnerabilities? Yes, you could. This session is about exactly that. "Business" and "technical" attacks are two kinds of attacks, where the latter is the most famous, e.g. SQL Injection and Cross-Site Scripting. But this doesn't mean business attacks are less harmful. On the contrary, attacks on the business tend to be extremely sophisticated and powerful as they often leave the infrastructure intact and trigger no alarms. Domain Driven Security is the field that counteracts both types of attacks by using tools and mindsets from DDD in a clever way.

1. Arm yourself with Domain Driven Security.
It’s time to slay some security trolls…
@danbjson, @DanielDeogun
Omegapoint
DDD Europe
Brussels January 2016

2. About Us…
Umeå
Malmö
Göteborg
Falun
New York
Stockholm
Daniel Deogun
Security Paratrooper
Dan Bergh Johnsson
Secure Domain Philosopher
Omegapoint

3. Key Take Aways
• DDSec helps one to design secure software without actively thinking
about security
• Treat injection flaws as a modelling problem rather than a validation
problem
• Context mapping is essential to avoid XSS and other 2nd order
injection attacks
• Micro-services will be scary as hell, unless the world gets a grip on
context mapping

4. Domain Driven Security @
DDD Europe
• Presentation: Arm yourself with Domain Driven Security. It’s time to slay some
security trolls…
• Introduce field, get you curious
• Hands-on: OWASP application security vulnerabilities and what Domain-Driven
Security has to say about it
• Bring a laptop, touch some code
• OWASP, Injection Flaw, Cross-Site Scripting
• Hands-on: Your business is under attack - a conceptual tour of Domain Driven
Security state of the art
• Presentation on subtle insights
• In-depth discussions

5. Attacks From A DDD
Perspective
Complex Technical
Complex
Domain
Simple Domain
Simple
Technical

6. Purchasing
“Unencyclopedia”
[Encyclopedia]

7. Technical Approach
• OWASP “indata validation”
• if(value < 0) -> don’t accept
• Encourage separation of validation and data
• Problem whack-a-mole ahead!

8. Analysis á la DDD
• Observation
• Quantity is modelled as integer
• Quantity is an implicit concept
• Analysis
• Modelling is incomplete or missing

9. Analysis á la DDD
-1 : Integer
-1 : Quantity
OrderLine {ISBN, Quantity}

10. Quantity made explicit -
a good start
public final class Quantity {
public final int value;
public Quantity(final int value) {
isTrue(value > 0, "Quantity must be greater than zero. Got: %s", value);
this.value = value;
}
…

11. Ubiqutous Domain
Primitives
• Library of domain primitives
• Consolidates business rules
• Raises the floor
void buyBook(String, int) -> buyBook(ISBN, Quantity)

12. Another concept made explicit
public final class EmailAddress {
public final String value;
public EmailAddress(final String value) {
isTrue( ?????????, “Not valid email. Got: %s", value);
this.value = value;
}
…

13. Email according to spec
• RFC 5322 3.4 Address Specification (RFC 821, RFC 2821)
• Some OK examples
• root@127.0.0.1
• !#$%&'*+-/=?^_`{|}~@omegapoint.se
• ”Åsa Sjölander”@omegapoint.se
• Regexp : (?:(?:rn)?[ t])*(?:(?:(?:[^()<>@,;:".[] 000-031]+(?:(?:(?:rn)?[ t])+|Z|(?=[
["()<>@,;:".[]]))|"(?:[^"r]|.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:
[^()<>@,;:".[] 000-031]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:".[]]))|"(?:[^"r]|.|(?:(?:r
n)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:".[] 000-031]+(?:(?:(?:rn)?[ t])
+|Z|(?=[["()<>@,;:".[]]))|[([^[]r]|.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:
".[] 000-031]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:".[]]))|[([^[]r]|.)*](?:(?:rn)?
[ t])*))*|(?:[^()<>@,;:".[] 000-031]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:".[]]))|"(?:[^"r
]|.|(?:(?:rn)?[ t]))*"(?:(?:rn) /… 6424 chars

14. You define Your domain
• Bounded Context - bounded by what you need
• Is “root@127.0.0.1” sensible to you?
• Strength not by “how wide” but by “how specific”
• Start simple - limit to your core cases
• E.g. “daniel.deogun@omegapoint.se”
• Let the model grow

15. What is DDSec?
“Domain Driven Security is about taking ideas from
DDD and using them as tools to address security
concerns, even though the tools were not originally
designed specifically for security issues.”
- Dan Bergh Johnsson, Dr. John Wilander [2009]
http://dearjunior.blogspot.be/2009/09/introducing-domain-driven-security.html

16. Attacks From A DDD
Perspective
Complex Technical
Complex
Domain
Simple Domain
Simple
Technical

17. Injection Flaw
“Injection flaws, such as SQL, OS, and LDAP injection
occur when untrusted data is sent to an interpreter as
part of a command or query. The attacker’s hostile data
can trick the interpreter into executing unintended
commands or accessing data without proper
authorization.”
- OWASP top 10

18. The Classics -
Dynamic SQL String
SELECT … FROM Users
WHERE username = ’<?username>’
AND password = ’<?password>’
danbj catsarecute
SELECT … FROM Users
WHERE username = ’danbj’
AND password = ’catsarecute’
Warning! This is just an example. Do not store passwords in plain text.
Do not use relational databases for user management.

19. SQL Injection
SELECT … FROM Users
WHERE username = ’<?username>’
AND password = ’<?password>’
evilhaxxOr ’OR 1=1 --
SELECT … FROM Users
WHERE username = ’evilhaxxOr’
AND password = ’’OR 1=1 --’
SELECT … FROM Users
WHERE username = ’’OR 1=1 --’
AND password = ’doesnotmatteranymore’
Warning! This is just an example. Do not store passwords in plain text.
Do not use relational databases for user management.

20. Demo
SQL INJECTION

21. What’s the problem?
and solution?
• ‘OR 1=1 -- is not a valid username
• This is implicit in the code
• Needs to be made explicit
• Modelling required

22. Prepared Statements
AKA Parametrised Queries
• SQL Injection is solved by prepared
statements
• But what if the query structure is dynamic?
• Other Injection Flaws
• LDAP, Command, XPath, HTTP header …

23. HTTP Response with Cookie
[https://www.owasp.org/index.php/HTTP_Response_Splitting]
String author = … /* request, database, user setting … */
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
…
<html><head><title>The real content</title> ...

24. HTTP Injection
Hacked ‘author’ value into database/setting …
author : "Wiley HackerrnHTTP/1.1 200 OKrn..."
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
…
<html><head><title>Hacked content</title> …
...
<html><head><title>The real content</title> ...
[https://www.owasp.org/index.php/HTTP_Response_Splitting]

25. RFC 2616 HTTP/1.1
Ch 4 HTTP Message
HTTP-message = Request | Response ; HTTP/1.1 messages
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4

26. DDSec to the Rescue on
Injection Flaw
• DDD helps one to separate data from
code
• Validating with respect to the model is
crucial

27. A Quick Note On
Validation
• Validation order
• Origin
• Length
• (Lexeme, content text)
• Parsing, content structure
• Semantics
- Dr. John Wilander

28. Attacks From A DDD
Perspective
Complex Technical
Complex
Domain
Simple Domain
Simple
Technical

29. Cross Site Scripting (XSS)
“XSS flaws occur whenever an application takes untrusted
data and sends it to a web browser without proper
validation or escaping. XSS allows attackers to execute
scripts in the victim’s browser which can hijack user
sessions, deface web sites, or redirect the user to malicious
sites.”
- OWASP top 10

30. Demo
Cross Site Scripting (XSS)

31. Domain Perspective
Text
Comment
Text

32. Domain Perspective
Text
Text
Code
Comment

33. Fix the Broken Mapping
<script>
<script>
Text
Code
&lt;script&gt;

34. SQL Injection vs XSS

35. Code
SQL Injection vs XSS
Code

36. 2nd order injection
Web
Srv
DB
Log
Log
Adm

37. Preventing Data Leakage
read once object [Daniel Sawano]
public final class SensitiveValue implements Externalizable {
private final AtomicReference<String> value;
public SensitiveValue(final String value) {
this.value = new AtomicReference<>(validated(value));
}
public String value() {
return notNull(value.getAndSet(null), "Sensitive value has already been consumed");
}
@Override
public String toString() {
return "SensitiveValue value = *****";
}
@Override
public void read / writeExternal(final ObjectOutput out) throws IOException {
throw new UnsupportedOperationException("Not allowed on sensitive value");
}

38. How did DDSec Help Us?
• DDD gave deeper insight in nature of XSS
• Context mapping allows one to “detect” possible
broken maps
• Modeling confidentiality protects against accidental
disclosure of sensitive data

39. Attacks From A DDD
Perspective
Complex Technical
Complex
Domain
Simple Domain
Simple
Technical

40. Complex Domain Attack
Order
Finance Storage Shipping
-1
-1
-1

41. Micro-servicing the
Monolith
Payment
Policy

42. Payment
Micro-servicing the
Monolith
Payment
Policy
InsurancePurchase

43. Making a change with
surgical precision
Payment
Policy
Payment
Confirm
Reject
Giro Bounce
Giro Confirm
Purchase
Bank
Insurance

44. What we would have done
Payment
Policy
Cash Payment
Confirm
Reject
Giro Bounce
Giro Confirm
Purchase
Bank
Insurance
Giro Payment

45. Micro-Service Hell
• We’re moving towards more and more
micro-services
• Implemented by separate teams
• How do we guarantee correct context
mappings?

46. Key Take Aways
• DDSec helps one to design secure software without actively thinking
about security
• Treat injection flaws as a modelling problem rather than a validation
problem
• Context mapping is essential to avoid XSS and other 2nd order
injection attacks
• Micro-services will be scary as hell, unless the world gets a grip on
context mapping

47. Current State,
Future Direction
• Academic research on DDSec
• Two master’s thesis projects in cooperation with Royal Institute of Technology
(KTH)
• Cooperation with Linnaeus University, computer science dept
• Industry practice
• Practice every day
• more needed - especially regarding how to handle micro-services
• investigating DDSec as applicable to DDOS-attacks
• Writing
• Early stage of book by Dan Bergh Johnsson, Daniel Deogun and Daniel Sawano.

48. Q & A
[Questions]

49. Thanks
@danbjson, @DanielDeogun

50. Image References
• [Questions - https://flic.kr/p/9ksxQa] by Damián Navas under license https://creativecommons.org/licenses/by-nc-nd/2.0/
• [Encyclopedia - https://www.flickr.com/photos/stewart/461099066] by Stewart Butterfield under license https://creativecommons.org/licenses/by/2.0/