A developer's primary responsibility is to ship working code, and by the way, it's also expected to be secure code. The definition of "working" may be quite clear, but the definition of "secure" is often surprisingly hard to pin down. This session will explore a few ways to help you define what application security means in your own context, how to build security testing and resilience into your development processes, and how to have more productive conversations about security topics with product and business owners.

1. NO SUCH THING AS A
SECURE APPLICATION!
@mullican

2. @mullican
ASHEVILLE, NC • RAILS SINCE 2006
@mullican

3. CONVERSATIONS WITH
MANAGEMENT !
"IS THIS APP SECURE?"
"HOW SECURE IS THIS APP?"
@mullican

4. RISK !
@mullican

5. MORE USEFUL QUESTIONS
WHAT CAN GO WRONG? • HOW LIKELY IS IT TO GO WRONG?
HOW CAN WE STOP IT GOING WRONG?
WHAT HAPPENS IF IT GOES WRONG ANYWAY?
@mullican

6. MORE USEFUL QUESTIONS
WHAT CAN GO WRONG? • HOW LIKELY IS IT TO GO WRONG?
HOW CAN WE STOP IT GOING WRONG?
WHAT HAPPENS IF IT GOES WRONG ANYWAY?
@mullican

7. MORE USEFUL QUESTIONS
WHAT CAN GO WRONG? • HOW LIKELY IS IT TO GO WRONG?
HOW CAN WE STOP IT GOING WRONG?
WHAT HAPPENS IF IT GOES WRONG ANYWAY?
@mullican

8. MORE USEFUL QUESTIONS
WHAT CAN GO WRONG? • HOW LIKELY IS IT TO GO WRONG?
HOW CAN WE STOP IT GOING WRONG?
WHAT HAPPENS IF IT GOES WRONG ANYWAY?
@mullican

9. RESIDUAL RISK
@mullican

10. WHAT CAN GO WRONG?
( AND HOW LIKELY IS IT? ) !
@mullican

11. THREAT MODELING !
@mullican

12. More LIKELY
Less DAMAGING
More DAMAGING
Less LIKELY
@mullican

13. More LIKELY
Less DAMAGING
More DAMAGING
Less LIKELY
• SQL injection
• Vulnerable
dependencies
• Malware upload
• Phished admin
credentials
• Malicious
insider
• DDOS
• Side-channel
attacks on auth
process
• Open redirectabuse
• Abuse of
password
reset process
@mullican

14. HOW DO WE STOP IT
FROM GOING WRONG?!
@mullican

15. CORRECT
IMPLEMENTATION
IS THE HARD PART
@mullican

16. TEST ALL THE THINGS⛔ ✅
@mullican

17. EXPLICIT TESTS
Scenario: Attempting direct access to an order I don't own
Given order "1234" belongs to "client@example.com"
And I have logged in as "bad.actor@example.com"
When I navigate directly to order "1234"
Then I should see "Access Denied"
And the Slack channel "#security" should be notified
@mullican

18. EXPLICIT TESTS ARE MOST USEFUL FOR:
DOCUMENTING EXPECTED BEHAVIOR
CATCHING REGRESSIONS
@mullican

19. STATIC ANALYSIS
== Warnings ==
Confidence: High
Category: SQL Injection
Check: SQL
Message: Possible SQL injection
Code: Person.order(params[:sort_by])
File: app/controllers/people_controller.rb
Line: 3
@mullican

20. STATIC ANALYSIS IS MOST USEFUL FOR:
FINDING CONFIGURATION PROBLEMS
CATCHING UNSAFE USE OF USER INPUT
@mullican

21. DYNAMIC ANALYSIS
---------------------------------------------------------------------------
+ Target IP: 127.0.0.1
+ Target Hostname: localhost
+ Target Port: 3000
+ Start Time: 2019-04-01 12:00:00 (GMT-4)
---------------------------------------------------------------------------
+ Server: No banner retrieved
+ Uncommon header 'x-runtime' found, with contents: 0.012730
+ Uncommon header 'x-request-id' found, with contents: 986c90ad-cd80-402b-9e9c-18218a279d4f
+ Uncommon header 'x-web-console-session-id' found, with contents: 9c9b9e420b09ad9f0ca20db64aebaf33
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ ///etc/passwd: The server install allows reading of any system file by adding an extra '/' to the URL.
@mullican

22. DYNAMIC ANALYSIS IS MOST USEFUL FOR:
GENERATING LOTS OF UNEXPECTED INPUT
TESTING THE FULL REQUEST STACK
CHECKING KNOWN VULNERABILITY PATTERNS
SIMULATING AN AUTOMATED ATTACK
@mullican

23. MANUAL TESTING
@mullican

24. MANUAL TESTING IS MOST USEFUL FOR:
INFERRING LESS OBVIOUS VULNERABILITIES
SIMULATING A TARGETED ATTACK
@mullican

25. DEFENSE IN DEPTH
@mullican

26. WHAT HAPPENS IF IT
GOES WRONG ANYWAY?!
@mullican

27. EXPLOITS TAKE TIME !
@mullican

28. IN-APP ALERTING
# config/routes.rb
Rails.application.routes.draw do
get 'admin', to: 'tripwire#alert'
end
@mullican

29. IN-APP ALERTING
# app/controllers/tripwire_controller.rb
class TripwireController < ApplicationController
def alert
notify_support_team if current_user.present?
head :not_found
end
private
def notify_support_team
# Danger, Will Robinson!
end
end
@mullican

30. AUTOMATED RESPONSE
# config/routes.rb
Rails.application.routes.draw do
get 'wp-admin', to: 'tripwire#block'
end
@mullican

31. # app/controllers/tripwire_controller.rb
class TripwireController < ApplicationController
BLOCK_DURATION = 6.hours
def block
block_request_source
head :not_found
end
private
def block_request_source
Rails.logger.warn("Blocking client #{request.remote_ip}")
Rails.cache.write(cache_key_for_block, true, expires_in: BLOCK_DURATION)
end
def cache_key_for_block
['blocked-ip', request.remote_ip]
end
end
@mullican

32. AUTOMATED RESPONSE
# config/initializers/rack_attack.rb
Rails.application.config.middleware.use Rack::Attack
Rack::Attack.blocklist('tripwires') do |request|
Rails.cache.read(['blocked-ip', request.ip])
end
@mullican

33. PLAN AHEAD
@mullican

34. RESILIENCE!
@mullican

35. CULTURAL RESILIENCE
@mullican

36. SECURITY IMPOSTOR
SYNDROME !
@mullican

37. SECURITY IMPOSTOR
SYNDROME !
@mullican

38. CONVERSATIONAL TOOLS
AGREED THREAT MODEL • WRITTEN CODE EXPECTATIONS
PUBLIC TEST OUTPUT • RESPONSE PLANS AND POSTMORTEMS
@mullican

39. Tools Further Reading
Brakeman
brakemanscanner.org
Rails Security Guide
OWASP Secure Coding Practices
OWASP Top Ten
US-CERT
Gems:
rubysec/bundler-audit
kickstarter/rack-attack
@mullican