This document discusses secure software development. It covers validating all inputs to prevent XSS and SQL injection attacks, failing securely when errors occur, sanitizing output to remove dangerous characters, avoiding direct object references, and using prepared statements for databases. It also recommends separating behaviors into classes, wrapping primitives, defining domains and boundaries, adding tests for security rules, and designing with default deny and least privilege in mind. The overall message is that security requires quality code, clear concepts, and enforcing rules rather than relying on obscurity.

1. Crafting
Secure
Software

2. WhoamI?
Craftsman at Arolla
Session by : Yvan Phélizot (yvan.phelizot@arolla.fr)
@cotonne / cotonne.github.io
BBL : http://www.brownbaglunch.fr/baggers.html#yvan-phelizot

4. Download
https://goo.gl/ryc8NB

5. Who are you?

8. A promising business!
The VHS is back!!
Netflipster
Registration
DB
Booking

9. Basic functionalities
Registration ----
Name:
tom
Password:
pouce
Connection ---
Name:
tom
Password:
pouce
You are connected as tom
Films:
1) Harry Potter and the
Philosopher's Stone
...
Selection:
1
Quantity:
1
Your command of 1 VHS ( Harry
Potter and the Philosopher's
Stone ) will be sent soon

10. Errors (example)
Registration ----
Name:
tom
Utilisateur existant
Connection ---
Name:
tom
Password:
pouce
Mot de passe invalide
Films:
1) Harry Potter and the
Philosopher's Stone
...
Selection:
10
Le VHS 10 a été trouvé 0 fois

11. Time to deploy
Netflipster!

12. Hey! Wait a
minute...

13. We need you!

14. What if....
I used tom^1B[41m as a login?

15. XSS

16. Rule #1...
Almost...

17. Rule #1 : Validate all inputs
// read username
if(!username.matches("<un format>")) {
throw new Error();
}
// do something with username
// read username
// do something with username

18. Never happens before

19. What if....
I used 1’ or ‘1’=’1 as a password?

20. Sensitive
Data
Exposure

21. Rule #2 : Fail securely
// read password
try {
// use password in SQL query
} catch (e) {
// Sorry, smth went wrong!
}
// read password
// use password in SQL
query

22. What if....
I used 1’ or ‘1’=’1 as a password?

23. SQL
injection

24. Rule #3 : Sanitize output
// read password
String password = "";
password = password.replaceAll("'", "");
// use sanitized password in SQL query
// read password
// use password in SQL query

25. An easy one...

26. Let’s fix Netflipster

27. Let’s fix security holes
1) login = tom^1B[41m ⇒ Validate all inputs (only letters)
2) password: ‘ or ‘1‘=‘1 ⇒ Fail Securely (no exception)
3) password: ‘ or ‘1‘=‘1 ⇒ Sanitize data (remove quote)

28. This is secure coding

29. Hey ...
- Why not testing that we correctly enforce those
requirements?
- Why not trying to reduce our code to the minimum?
- Why not keeping track of those exchanges?
Any idea?

30. Secure TDD
Test-Driven Security

31. Recommended
reading

32. Is it secure?

33. What if....
I used
1||char(39)||or||char(39)1char(39)=ch
ar(39)1 as a password?

34. Don’t build your own tool!
Use best practices!
For SQL : Prepared Statement
Others : Sanitize functions

35. Is it secure?

36. What if....
I used -1 as a quantity ?

37. Fix it!
We are losing money!

38. What if....
I used 2147483647 as a quantity ?

39. Why ?

40. We lost business rules

41. Hey, wait!
Who is absolutely sure
that the code always complies with those
rules?

42. Step 1 : make implicit concept explicit
class User {
final String username;
}
String username

43. Step 2 : ensure compliance with rules… ALWAYS
class User {
final Username username;
final Password password;
}
class Username {
// Validation control here!
// Immutability ⇒ checking
state at creation/modification
}

44. Step 2 : Let’s continue with...
1) Extract behaviors into separate classes
2) Wrap primitives into meaningful classes
3) Combine them into entities
4) Ensure
a) Immutability
b) Consistency
5) Define domains and trusted boundaries

45. Let’s reinforce
Netflipster
Define
QUANTITY
Add
ADVERSARIAL
UNIT TESTS

46. Recommended
reading

47. Boundaries
BANK BILLING
PAYMENT
CONFIRM
PAYMENT

48. DDD
+
Security
Explicit elements of
the domain
Enforcing business
rules
Clear definition of
boundaries

49. Is it secure?

50. Is this normal?
Booking(string userId, int quantity,
string vhsId)
Booking(string vhsId, int quantity, string
userId)

51. Invalid<String> ⇒ Valid<String> ⇒
Valid<Result>

52. bug zero kata

53. Is it secure?

54. What if....
I enter 0 as a VHS ID?

55. Insecure
Direct Object
References

56. Rule #4 : Fail fast
// read id
if(!identifiers.contains(vhsId)){
return;
}
// book a VHS
// read id
// book a VHS

57. Complete Mediation

58. Hidden != Secure
Security by Obscurity

59. Can we design
our application in
a secure way?

60. 10 rules of Secure by Design
1) Trust with caution/Check
everything
2) Protect others
3) KISS
4) Default Deny
5) Learn to learn
6) Fail Securely/Fast
7) Least privilege
8) Separation of duties
9) Fix security holes
10) Practices defense in
depth

61. Levels to security
● Level -1: Nope
● Level 0: Craft
● Level 1: Security guidelines
● Level 2: Secure Coding
● Level 3: Crafting Secure Software (TDS, Strongly Typed)
● Level 4: Secure by (DD-)Design
● Level 5: Secure by Design

62. You can’t have
SECURITY
without
QUALITY

63. Clean Code Secure Code

64. Remember, even the most secure
design is rendered by a low-quality and
insecure implementation, regardless of
the number of security features the
product employs

65. Crafting software
…
helps security

66. Merci!
Questions?
Session by : Yvan Phélizot
(yvan.phelizot@arolla.fr)
@yoda044 / cotonne.github.io
BBL :
http://www.brownbaglunch.fr/baggers.html#
yvan-phelizot