GeeCon Prague 2017 - Cracking the Code to Secure Software

Cracking the Code to
Secure Software
@DanielDeogun @DanielSawano
Prague, 19-20 October 2017

@DanielDeogun @DanielSawano #SecureByDesign
Daniel Deogun Daniel Sawano

What’s Cracking the Code… all about?
“A mindset and strategy for creating secure
software by focusing on good design”
- Secure by Design

What we’ll cover today
Solve a real security problem using good design
Immutable mutability
Detecting accidental leakage of sensitive data

Case 1: Cross Site Scripting (XSS)
Some website
Webform
Phone #
Input:
+46 8 545 106 90
or
<script>alert(“XSS”)</script>

Stored XSS
Alert

Reflective XSS
Reflective XSS
Alert
IllegalArgumentException(“<script>alert(“XSS”)</script>”)

Technical Analysis
“Phone number” isn’t escaped properly when rendered
on the website – hence, it gets interpreted as code!
Alert

Technical Solution
Escape phone number so it can be rendered as text

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
Total $39.49

Analysis
-1 : Integer
-1 : Integer
OrderLine {ISBN, -1}
Math Context
Webshop Context

But Quantity isn’t an integer…
Integers form an Abelian Group
• Closure: a + b = integer
• Associativity: a + (b + c) = (a + b) + c
• Commutativity: a + b = b + a
• Identity: a + 0 = a
• Inverse: a + (−a) = 0
Quantity
• a concept that’s well deﬁned
with strict boundaries
• not closed under addition
• cannot be negative

Domain Primitives
“A value object so precise in its deﬁnition that it, by its mere
existence, manifests its validity is called a Domain Primitive.”
- Secure by Design
• Building block that’s native to your domain
• Valid in the current context
• Immutable and resemble a value object in DDD

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...
}

Invalid quantities are rejected
-1 : Integer
Quantity: {1 - 99}
OrderLine {ISBN, Quantity}
Math Context
Webshop Context
Only valid quantities are
accepted
Rejected

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.

We want to prevent invalid
phone numbers…
Webform
Phone #
Input:
+46 8 545 106 90
or
Alert
public void register(final String phoneNumber) {
// Register phone number logic
}

But String Accepts Anything!
Input:
+46 8 545 106 90
or
public void register(final String phoneNumber) {
}
Could be anything!
Attackers look at this
Developers mostly look at this to
understand the intention

Use a Domain Primitive Instead
Input:
+46 8 545 106 90
or
public void register(final PhoneNumber phoneNumber) {
}
Can only be valid phone numbers
by deﬁnition!
ü

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.
<script>alert(“XSS”)</script> doesn’t meet the rules and
rejected by design.
But what about escaping – do we need it?

But…
[5
… what about performance?
[3
… it becomes a lot of classes!
… isn’t it overly complex?
[4

ü

CIA
Conﬁdentiality – data must only be disclosed to authorized users
Integrity – data modiﬁcation is only allowed in an authorized manner
Availability – data must be available when needed
[

Availability and Mutable State
Mutable state makes it difﬁcult 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?

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 identiﬁed by their attributes, but rather by
their identity and lifespan – for example, a customer or a court case.

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
Total $120.49

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!

Order as an Entity Snapshot
Entity Snapshot
Entity Snapshots
Change Entity
OrderUpdateServiceOrderReadService

But…
[5]
… what about performance? … isn’t it overly complex?
[4]

Entity Snapshots
- Removes many of the issues with mutable state such as
- Availability
- Consistency
- Gets all beneﬁts from Domain Primitives

ü
ü

Accidental Leakage
Typical causes:
• Logs
• Session persistence
• Evolving domain model

Evolving domain model
User
- name
- nickname
- age
User
- name
- nickname
- age
- SSN
Remodeling

Read-once Object
public final class SensitiveValue implements Externalizable {
private transient final AtomicReference<String> value;
public SensitiveValue(final String value) {
// Check domain-specific invariants
this.value = 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");
}
}

ü
ü
ü

Summary
Many security weaknesses can be avoided using Secure by Design
- Domain Primitives
- signiﬁcantly reduce the attack surface
- facilitate security in depth
- reduce the risk of injection attacks
- Read-once objects
- detects accidental data leakage
- Entity Snapshot
- immutable
- takes on similar properties of a domain primitive
- facilitate availability and scalability

bit.ly/secure-by-design
48% E-book Discount Code for GeeCon! sbdgc17

QA
[2]

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

GeeCon Prague 2017 - Cracking the Code to Secure Software

More Related Content

Similar to GeeCon Prague 2017 - Cracking the Code to Secure Software (20)

More from Daniel Sawano (12)

Recently uploaded (20)

GeeCon Prague 2017 - Cracking the Code to Secure Software