A presentation at Code Europe Cracow 2017 in in Kraków, Poland by Daniel Sawano
Cracking the Code to Secure Software @DanielDeogun @DanielSawano CodeEurope, Kraków, 2017
@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 2nd order XSS
<script>alert(“XSS”)</script>Logs Admin Alert Log Reader Trust Boundary Service
@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. ”
• Building block that’s native to your domain
• 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 is 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 Order as a Mutable Entity public final class Order {
private final OrderId id ; // entity id
new ArrayList<>();
public Order( final OrderId id) {
notNull (id); }
public void addItem( final OrderItem item) {
orderItems .add( notNull (item)); }
public List<OrderItem> orderItems() {
return orderItems ; }
public OrderId id() {
return id ; }
// ... }
@DanielDeogun @DanielSawano #SecureByDesign Order as an Entity Snapshot public final class Order {
private final OrderId id ; // entity id
private final List<OrderItem> orderItems ;
public Order( final OrderId id, final List<OrderItem> orderItems) {
noNullElements (orderItems);
notNull (id);
this . id = id;
unmodifiableList ( new ArrayList<>(orderItems)); }
public List<OrderItem> orderItems() {
return orderItems ; }
public OrderId id() {
return id ; }
// ... } Domain rules enforced in constructor
@DanielDeogun @DanielSawano #SecureByDesign Updating an Order final OrderId id = ... ; final OrderItem item = ... ; orderUpdateService .addItemToOrder(id, item); // Async update
@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
d etects accidental data leakage
@DanielDeogun @DanielSawano #SecureByDesign bit.ly/secure-by-design 40% Discount Code for Code Europe! ctwcodeeu17
@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? One challenge is that developers are busy delivering features, another is that security seems scary and complex. In this talk, we'll address this by combining tools and mindsets from Domain Driven Design along with a pinch of security. This way, we'll teach you how to create secure code while still focusing on delivering business features. We'll also present the basic principles of Secure by Design and show how security weaknesses can be addressed using good design principles and why you shouldn't fear security as a field. Finally, the ideas and patterns presented are directly applicable in your daily work regardless if you're working with legacy code or brand new state of the art software.
The following resources were mentioned during the presentation or are useful additional information.
for free. You
can too.