A presentation at GeeCON Prague 2017 in in Prague, Czechia by Daniel Sawano
Cracking the Code to Secure Software @DanielDeogun @DanielSawano Prague, 19-20 October 201 7
@DanielDeogun @DanielSawano #SecureByDesign Daniel Deogun Daniel Sawano
@DanielDeogun @DanielSawano #SecureByDesign What’s Cracking the Code … all about? “A mindset and strategy for creating secure software by focusing on good design”
@DanielDeogun @DanielSawano #SecureByDesign What we’ll cover today Solve a real security problem using good design Immutable mutability Detecting accidental leakage of sensitive data
@DanielDeogun @DanielSawano #SecureByDesign
Case 1: Cross Site Scripting (XSS)
Some website
Webform
Phone #
Input:
+46 8 545 106 90
or
<script>alert(“XSS”)</script>@DanielDeogun @DanielSawano #SecureByDesign Stored XSS
<script>alert(“XSS”)</script>Alert
@DanielDeogun @DanielSawano #SecureByDesign Reflective XSS
<script>alert(“XSS”)</script>Reflective XSS Alert IllegalArgumentException(“<script>alert(“XSS”)</script> ”)
@DanielDeogun @DanielSawano #SecureByDesign Technical Analysis “Phone number” isn’t escaped properly when rendered on the website – hence, it gets interpreted as code!
<script>alert(“XSS”)</script>Alert
<script>alert(“XSS”)</script>@DanielDeogun @DanielSawano #SecureByDesign Technical Solution Escape phone number so it can be rendered as text
<script>alert(“XSS”)</script><script>alert(“XSS”)</script>
<script>alert(“XSS”)</script>@DanielDeogun @DanielSawano #SecureByDesign
Case 2: Buying -1 books
[1]
1 Secure by Design
$49.99
-1 Hamlet
$40.50
1
Hitchhiker's Guide to the Galaxy
$30.00
Shopping Cart
To t a l $ 3 9 . 4 9
@DanielDeogun @DanielSawano #SecureByDesign Analysis -1 : Integer -1 : Integer OrderLine {ISBN, -1 } Math Context Webshop Context
@DanielDeogun @DanielSawano #SecureByDesign But Quantity isn’t an integer … Integers form an Abelian Group • Closure: a + b = integer • Associativity: a
c) = (a + b) + c
b + a
• Identity: a
• Inverse: a
@DanielDeogun @DanielSawano #SecureByDesign Domain Primitives “A value object so precise in its definition that it, by its mere existence, manifests its validity is called a Domain Primitive. ”
• Valid in the current context
• Immutable and resemble a value object in DDD
@DanielDeogun @DanielSawano #SecureByDesign Quantity as a Domain Primitive public final class Quantity {
private final int value ;
public Quantity( final int value) {
inclusiveBetween ( 1 , 99 , value);
this . value = value; }
//Domain specific quantity operations... }
@DanielDeogun @DanielSawano #SecureByDesign Invalid quantities are rejected -1 : Integer Quantity: {1 - 99} OrderLine {ISBN, Quantity } Math Context Webshop Context Only valid quantities are accepted Rejected
@DanielDeogun @DanielSawano #SecureByDesign
Domain Primitives
tighten your design
Domain Primitives tighten your design by
explicitly stating requirements and assumptions.
They also make it harder to inject data that
doesn’t meet the expectations.
Let’s see if this pattern allows us to address XSS
attacks implicitly.
@DanielDeogun @DanielSawano #SecureByDesign
We want to prevent invalid
phone numbers
…
Webform
Phone #
Input:
+46 8 545 106 90
or
<script>alert(“XSS”)</script>Alert public void register(final String phoneNumber) { // Register phone number logic }
@DanielDeogun @DanielSawano #SecureByDesign But String Accepts Anything! Input:
+46 8 545 106 90
or
<script>alert(“XSS”)</script>public void register(final String phoneNumber) { // Register phone number logic } Could be anything! Attackers look at this Developers mostly look at this to understand the intention
@DanielDeogun @DanielSawano #SecureByDesign Use a Domain Primitive Instead Input:
+46 8 545 106 90
or
<script>alert(“XSS”)</script>public void register(final PhoneNumber phoneNumber) { // Register phone number logic } Can only be valid phone numbers by definition! ü
@DanielDeogun @DanielSawano #SecureByDesign
Domain Primitives prevent XSS
The PhoneNumber domain primitive enforce domain rule validation at
creation time.
This reduces the attack vector to data that meets the rules in the
context where it’s used.
doesn’t meet the rules and rejected by design. But what about escaping – do we need it?
@DanielDeogun @DanielSawano #SecureByDesign But … [5 … what about performance? [3 … it becomes a lot of classes! … isn’t it overly complex? [4
@DanielDeogun @DanielSawano #SecureByDesign What we’ll cover today Solve a real security problem using good design Immutable mutability Detecting accidental leakage of sensitive data ü
@DanielDeogun @DanielSawano #SecureByDesign CIA Confidentiality – data must only be disclosed to authorized users Integrity – data modification is only allowed in an authorized manner Availability – data must be available when needed [
@DanielDeogun @DanielSawano #SecureByDesign Availability and Mutable State Mutable state makes it difficult to apply horizontal scaling of an application. Ensuring availability along with mutable state is hard. So, is there a design pattern that both facilitates availability and mutability?
@DanielDeogun @DanielSawano #SecureByDesign Design Stereotypes in DDD Value objects are immutable objects that don’t have a conceptual identity – we only care about its value, e.g. a business card or a $100 bill. We replace value objects with Domain Primitives to make them secure. Entities are objects that aren’t identified by their attributes, but rather by their identity and lifespan – for example, a customer or a court case.
@DanielDeogun @DanielSawano #SecureByDesign
How should we represent
an Order?
An order may change state
(open, closed, paid, etc).
Should it be an entity or
domain primitive?
How can we solve the
problems that comes with
mutability?
1 Secure by Design
$49.99
1 Hamlet
$40.50
1
Hitchhiker's Guide to the Galaxy
$30.00
Shopping Cart
To t a l $ 1 2 0 .
49
@DanielDeogun @DanielSawano #SecureByDesign Entity Snapshots Entities are often mutable by design, but we don’t need to implement it as a mutable object in code. If we separate mutating operations from read operations, the representation of an entity can be immutable. This makes the entity “look” like a Domain Primitive that facilitate availability and scalability!
@DanielDeogun @DanielSawano #SecureByDesign Order as an Entity Snapshot Entity Snapshot Entity Snapshots Change Entity OrderUpdateService OrderReadService
@DanielDeogun @DanielSawano #SecureByDesign But … [5] … what about performance? … isn’t it overly complex? [4]
Gets all benefits from Domain Primitives
@DanielDeogun @DanielSawano #SecureByDesign What we’ll cover today Solve a real security problem using good design Immutable mutability Detecting accidental leakage of sensitive data ü ü
@DanielDeogun @DanielSawano #SecureByDesign Accidental Leakage Typical causes: • Logs • Session persistence • Evolving domain model
SSN Remodeling
@DanielDeogun @DanielSawano #SecureByDesign Read-once Object public final class SensitiveValue implements Externalizable {
private transient final AtomicReference<String> value ;
public SensitiveValue( final String value) {
// Check domain-specific invariants
new AtomicReference<>(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 writeExternal( final ObjectOutput out) {
throw new UnsupportedOperationException( "Not allowed on sensitive value" ); }
@Override
public void readExternal( final ObjectInput in) {
throw new UnsupportedOperationException( "Not allowed on sensitive value" ); } }
@DanielDeogun @DanielSawano #SecureByDesign What we’ll cover today Solve a real security problem using good design Immutable mutability Detecting accidental leakage of sensitive data ü ü ü
facilitate availability and scalability
@DanielDeogun @DanielSawano #SecureByDesign bit.ly/secure-by-design 48% E-book Discount Code for GeeCon! sbdgc17
@DanielDeogun @DanielSawano #SecureByDesign QA [2]
@DanielDeogun @DanielSawano #SecureByDesign References • [1] https://www.flickr.com/photos/stewart/461099066 by Stewart Butterfield under license https://creativecommons.org/licenses/by/2.0/
• [2] https://flic.kr/p/9ksxQa
https://creativecommons.org/licenses/by-nc-nd/2.0/
• [3] https://flic.kr/p/2pvb2T https://creativecommons.org/licenses/by/2.0/
• [4] https://flic.kr/p/7Ro4HU https://creativecommons.org/licenses/by/2.0/
• [5] https://flic.kr/p/eGYhMw https://creativecommons.org/licenses/by/2.0/
• [6] CIA, https://goo.gl/images/DRzRcp
What is it that makes writing secure software so difficult? Why do we keep making the same mistakes over and over again? One challenge is that developers are busy delivering features and meeting deadlines – giving security requirements less priority. In this talk you’ll learn to use principles and mindsets from Domain Driven Design combined with a pinch of security awareness, to create secure code – while still focusing on your business features. You’ll learn the basic principles of Secure by Design and how to use concepts such as Domain Primitives and Entity Snapshots to harden your code. What a Domain DoS attack is, and how to incorporate security testing in your delivery pipeline. The ideas and tools presented are directly applicable in your daily work.
The following resources were mentioned during the presentation or are useful additional information.
for free. You
can too.