devObjective 2015 Day Two Notes
Notes taken from sessions attended at the devObjective 2015, day two (14th May 2015)
Rethink Async with RXJS
Presented by Ryan Anklam
Iterator: a pattern for accessing the elements of a collection without exposing its underlying representation
Observer: an object, the Subject, has one or many observers, that are notified of any state changes
Benefits over another Async approach:
Map - Transforms each element in a collection. The original collection is unchanged.
Filter - Narrows collections.
Reduce - turns an entire collection into a single value.
Zip - combines two collections.
- replace loops with map
- replace if statements with filters
- don't put too much into a single stream. Break up large streams into a number of smaller ones
Flattening patterns - managing concurrency
- merge - combines items in a collection as each item arrives
- concat - combines the collections in the order they arrived
- switchLatest - switches to latest collection as it arrives
Multiply like Rabbits with RabbitMQ
Presented by Luis Majano
Problems with RPC
- Blocks requests
- Asynchronous, partial solution, still 1 - 1 relationship
- Sender always knows about receiver
- Receiver knows about sender
How can we decouple knowledge and apply messaging patterns to our apps?
- doesn't care about consumers
- can be any system or language
- does not get a response
Messaging Bus - Broker
- Can be any system or language
Benefits of Messaging
- Producers lack knowledge - decoupled
- cross-platform technologies - flexibility
- event-driven programming - scalability
- queueing for later delivery
- load balancing
- Direct Messaging
- Work Queues
- Publish / Subscribe
- Topics / Routing
Advanced Messaging Queuing Protocol
Uses standard binary protocol
Has a number of implementations, but lets look into RabbitMQ
AMQP Messaging Broker with wrappers available in a number of different languages
Accepts and forwards messages
Think of it like the post box, post office AND postman rolled into one.
Rabbit Simulator - http://tryrabbitmq.com/
Who Owns Software Security? You Do.
Presented by Tim Buntel
Do you scan your apps for cybersecurity vulnerabilities before making them available? 40% of people said NO.
How much do you budget towards securing mobile apps built for customers? 50% of people said $0.
Time to market is an issue - under pressure to release new apps faster due to:
- customer demand
- competitive actions
- revenue shortfalls
- Endpoint profiling
- Endpoint forensics
- Network forensics
- "Secure" platforms
(RSA Conference 2015)
- Patterns, frameworks, and good design
- Do it early, do it often (and automate it)
- High quality people make high quality software
- It is everyone's responsibility
Doing it right is actually quicker in the end!
Good software is secure. Secure software is good software.
Four Step Plan
- https://www.bsimm.com - describes software security initiatives at 67 well-known companies
- study failures (not just successes)
- Know your tech stack
- Know your app and how it works
- store a password
- login a user
- upload a photo
- display user contributed content
- concatenate strings
- What is secret? What data is moving where?
Make it agile
Drive the culture
- even a little security is better than none. Don't wait for a big initiative.
- security should not be a "special event"
- get trained!
- have a plan for when something does go wrong
W3C Content Security Policy & HTTP headers for Security
Presented by David Epler
- protect against MIME type confusion attacks (IE9+, Chrome and Safari)
- configures user-agent's built-in reflective XSS protection (IE8+ and Chrome)
X-‐XSS-‐Protection: 1; mode=block
0 = disable XSS protection
1 = enable XSS protection
1; mode=block = enable XSS protection & block content
1; report=URL = report potential XSS to URL (Chrome/Webkit only)
- Indicates if browser should be allowed to render content in
DENY Prevents any domain from framing the content
SAMEORIGIN Only allows sites on same domain to frame the content
ALLOW-FROM URL Whitelist of URLs that are allowed to frame the content
Browser support varies on value.
HTTP Strict Transport Security (HSTS)
Instructs the browser to always use HTTPS protocol
- network attacks
- mixed content vulnerabilities
Does not allow a user to override the invalid certificate message.
// Require HTTPS for 60 seconds on domain Strict-‐Transport-‐Security: max-‐age=60 // Require HTTPS for 365 days on domain and all subdomains Strict-‐Transport-‐Security: max-‐age=31536000; includeSubDomains // Remove HSTS Policy (including subdomains) Strict-‐Transport-‐Security: max-‐age=0
- MIME-Handling Changes in Internet Explorer
- Controlling the XSS Filter
- OWASP: Clickjacking Defense Cheat Sheet
- OWASP: Cookie HTTPOnly
- OWASP: Cookie Secure
- Veracode: Guidelines for Security Headers
HTTP Strict Transport Security
- OWASP HTTP Strict Transport Security
- Mozilla Developer Network
- HSTS Preload
- IIS Module
Content Security Policy
- CSP 1.0 Candidate Recommendation
- CSP 1.1 Candidate Recommendation
- OWASP Content Security Policy
- An Introduction to Content Security Policy
- Content Security Policy Reference
- CSP Playground