Cracking the Code to Secure Software

A presentation at Code Europe Cracow 2017 in December 2017 in Kraków, Poland by Daniel Sawano

Slide 1

Slide 1

Cracking the Code to Secure Software @DanielDeogun @DanielSawano CodeEurope, Kraków, 2017

Slide 2

Slide 2

@DanielDeogun @DanielSawano #SecureByDesign Daniel Deogun Daniel Sawano

Slide 3

Slide 3

@DanielDeogun @DanielSawano #SecureByDesign What’s Cracking the Code… all about? “A mindset and strategy for creating secure software by focusing on good design”

  • Secure by Design

Slide 4

Slide 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

Slide 5

Slide 5

@DanielDeogun @DanielSawano #SecureByDesign Case 1: Cross Site Scripting (XSS) Some website Webform Phone # Input:
+46 8 545 106 90

or

<script>alert(“XSS”)</script>

Slide 6

Slide 6

@DanielDeogun @DanielSawano #SecureByDesign Stored XSS

<script>alert(“XSS”)</script>

Alert

Slide 7

Slide 7

@DanielDeogun @DanielSawano #SecureByDesign Reflective XSS

<script>alert(“XSS”)</script>

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

Slide 8

Slide 8

@DanielDeogun @DanielSawano #SecureByDesign 2nd order XSS

<script>alert(“XSS”)</script>

Logs Admin Alert Log Reader Trust Boundary Service

Slide 9

Slide 9

@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>

Slide 10

Slide 10

@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>

Slide 11

Slide 11

@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

Slide 12

Slide 12

@DanielDeogun @DanielSawano #SecureByDesign Analysis -1 : Integer -1 : Integer OrderLine {ISBN, -1 } Math Context Webshop Context

Slide 13

Slide 13

@DanielDeogun @DanielSawano #SecureByDesign 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 defined with strict boundaries • not closed under addition • cannot be negative

Slide 14

Slide 14

@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. ”

  • Secure by Design • Can only exist if its value is valid

• Building block that’s native to your domain

• Valid in the current context

• Immutable and resemble a value object in DDD

Slide 15

Slide 15

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

Slide 16

Slide 16

@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

Slide 17

Slide 17

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

Slide 18

Slide 18

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

Slide 19

Slide 19

@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

Slide 20

Slide 20

@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! !

Slide 21

Slide 21

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

<script>alert(“XSS”)</script>

doesn’t meet the rules and is rejected by design . But what about escaping – do we need it?

Slide 22

Slide 22

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

Slide 23

Slide 23

@DanielDeogun @DanielSawano #SecureByDesign What we’ll cover today Solve a real security problem using good design Immutable mutability Detecting accidental leakage of sensitive data !

Slide 24

Slide 24

@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 [

Slide 25

Slide 25

@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?

Slide 26

Slide 26

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

Slide 27

Slide 27

@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

Slide 28

Slide 28

@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!

Slide 29

Slide 29

@DanielDeogun @DanielSawano #SecureByDesign Order as an Entity Snapshot Entity Snapshot Entity Snapshots Change Entity OrderUpdateService OrderReadService

Slide 30

Slide 30

@DanielDeogun @DanielSawano #SecureByDesign Order as a Mutable Entity public final class Order {

private final OrderId id ; // entity id

private final List<OrderItem> orderItems

new ArrayList<>();

public Order( final OrderId id) {

this . id

notNull (id); }

public void addItem( final OrderItem item) {

orderItems .add( notNull (item)); }

public List<OrderItem> orderItems() {

return orderItems ; }

public OrderId id() {

return id ; }

// ... }

Slide 31

Slide 31

@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;

this . orderItems

unmodifiableList ( new ArrayList<>(orderItems)); }

public List<OrderItem> orderItems() {

return orderItems ; }

public OrderId id() {

return id ; }

// ... } Domain rules enforced in constructor

Slide 32

Slide 32

@DanielDeogun @DanielSawano #SecureByDesign Updating an Order final OrderId id = ... ; final OrderItem item = ... ; orderUpdateService .addItemToOrder(id, item); // Async update

Slide 33

Slide 33

@DanielDeogun @DanielSawano #SecureByDesign But… [5] … what about performance? … isn’t it overly complex? [4]

Slide 34

Slide 34

@DanielDeogun @DanielSawano #SecureByDesign Entity Snapshots

Removes many of the issues with mutable state such as

Availability

Consistency

Gets all benefits from Domain Primitives

Slide 35

Slide 35

@DanielDeogun @DanielSawano #SecureByDesign What we’ll cover today Solve a real security problem using good design Immutable mutability Detecting accidental leakage of sensitive data ! !

Slide 36

Slide 36

@DanielDeogun @DanielSawano #SecureByDesign Accidental Leakage Typical causes: • Logs • Session persistence • Evolving domain model

Slide 37

Slide 37

@DanielDeogun @DanielSawano #SecureByDesign Evolving domain model User

name

nickname

age User

name

nickname

age

SSN Remodeling

Slide 38

Slide 38

@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

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" ); } }

Slide 39

Slide 39

@DanielDeogun @DanielSawano #SecureByDesign What we’ll cover today Solve a real security problem using good design Immutable mutability Detecting accidental leakage of sensitive data ! ! !

Slide 40

Slide 40

@DanielDeogun @DanielSawano #SecureByDesign Summary Many security weaknesses can be avoided using Secure by Design

Domain Primitives

significantly reduce the attack surface

facilitate security in depth

reduce the risk of injection attacks

Entity Snapshot

immutable

takes on similar properties of a domain primitive

facilitate availability and scalability

Read-once objects

d etects accidental data leakage

Slide 41

Slide 41

@DanielDeogun @DanielSawano #SecureByDesign bit.ly/secure-by-design 40% Discount Code for Code Europe! ctwcodeeu17

Slide 42

Slide 42

@DanielDeogun @DanielSawano #SecureByDesign QA [2]

Slide 43

Slide 43

@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