Month: January 2016

Convention Over Configuration: Queueing is Easy

Presenter Matthew Groves

• Queuing is intimidating
• Quick review of queueing
  • processing that isn’t web or db can be pushed to another server and not impact ui or db server or make users wait for processing finish(async)
  • Introduce a queue instead of managing async communication on our won
  • We take request from user, tell them we will get back to them stick request on queue
    • can scale processors taking work off the queue when needed
• RabbitMQ on .NET demo
  • reviewed basic of running rabbitmq on .net
  • rabbit messages are byte arrasy so have to serialize payload to byte array
  • have to acknowledge receipt, basicAck, or message will stay in queue.
• Queuing patterns with EasyNetQ
  • .net tool only
  • Tool that sits on top of rabbitMQ
  • provides common queuing patters right out of box eliminating need to do deep configuration and serialization and deserialization of messages.
    • can think of messages as objects now, no need to get to byte array on your own
    • best of .net on both client and receiver
  • common patterns
    • Send and Receive
      • send message to a receiver, duh.
    • Publish and subscribe model
      • publisher puts message on queue doesn’t care who is listening
      • subscribers listen to what interests them
    • Request and Response
      • put request on request queue
      • put response on response queue

ASP.NET 5: How to Get Your Cheese Back

Presenter Tugberk Ugurlu

Surprised by how much has been changed in ASP.net 5.  I think the changes are good, but concerned about lack of backward compatibility.  MVC is now free of system.web so can be deployed sans IIS.

• ASP.net 5 is entire rewrite
• All files are part of project have to exclude what don’t want
• Unified dependencies
  • can set dependency by framework
• Project file is not .json
• Configure method in startup, similar to owin and katana
• New concepts
  • Command line tools
    • dnvm: dot net version manager
      • manages the versions of .net on your machine
      • Can assign different framework version to different processes running at same time
    • dnx: dot net execution environment
      • dnx run will run your application
    • dnu: dot net utility
  • Command-line first development ?
• Modular, Composable HTTP Pipelie
  • pipeline is entirely empty to start have to add everything
    • good since don’t have to pay the price for things you don’t use.
    • in startup configure method you add to the pipepline what you want
• Dependency injection all the way down
  • built in container get swap out with your favorite
  • ConfigureServices method in stratup used to config DI
  • ConfigureOptions<T>, syntax for configuring, like identity
• Config
  • in startup you tell app where and what kind of config files exist
  • configurationmanager is all gone, where it was used you need to change
• Unified mvc and webapi
  •  removed mvc dependency on system.web
• Code editor agnostic
• Cross platform now
  • can run windows,linux, osX
  • kestrel web server is supported
  • Can be dockerized now

Data Synchronization Patterns

Presenter Eric Maxwell

Good walk through of how to select an appropriate data transfer protocol for data services.  Focused mostly on rest and security.

• Data transfer protocol
  • depends on environment
    • do you need service discovery, delivery requirement ? (soap)
    • do you need transaction management?  (soap)
    • How much does bandwidth cost you? (rest)
    • are your clients and servers speaking same language? (soap if so)
• Focusing on rest
  • always use compression can get 80% gain
  • different way to turn on for each platform
  • Sync Tokens are bookmarks for new fetches
    • token is just a string
    • server doesn’t keep state regarding who got a token but knows a certain token maps to a time
• Security
  • Privacy
  • Integrity and Trust
  • Always use https
    • Mutual ssl
      • when server wants to know talking to a valid client
        • client sends it’s public  key server decides if it likes it
        • we actually do this, we put a client cert on mobile device and use that to establish client is legtimate
  • Authentication
    • basic auth
      • credentials in header needs ssl
    • certificate based
  • Authorization
  • OAUTH 2.0
    • Authorization Server
    • Identification Service
    • Resource Owner
    • Client
    • Server with Resourcce
    • Process
      • client registers with authorization server get clientid and shared secret
      • resource owner makes request on client to get access to resource
      • client authenticates user
      • client sends user to authorization server to get permission gets access token
      • access token and clientid and shared secret needed for client to then get resource

Abstract Art Getting Abstraction Right

Presenter Jeremy Clark

I agreed with much of what was presented.  Abstraction has its upsides and downsides, there is an appropriate middle ground.  I agree that following good practice (DRY, YAGNI, SOC, KISS and DDIY) will help you get there.

 

• Why abstraction is awesome
  • maintain
  • extend
  • testablility
• Why abstraction is awful
  • adds complexity
  • confusion
  • debugging difficulty
• Over Abstractor
  • we’ll find a use for this in the futrue
  • overly complex
• Under Abstractor
  • Let’s keep things simple
  • Ridgid
• Priniciples to apply to push to right middle ground
  • DRY – Don’t Repeat Yourself
  • Soc – Separation Of Concerns
  • YAGNI – You’re not going to need it
  • KISS – Keep it simply stupid
  • DDIY – Don’t do it yourself
• Use the principles so you don’t end up with rigid, hard to maintain untestable code
• If you are an under-abstractor and you can find an over-abstractor you can become a good team since can find balance, or vice/versa

Secure Web Coding 2 day presentation

Jim Manico presenter

I attended this two day presentation for the Codemash compiler.  I had planned on attending only part and catching some other classes, but found this material so useful and well presented that attended the entire two day presentation.  Very informative and well done.  Learned much that will be applicable to my day to day.  My notes are below.

 

• No difference between a web application and service from a security standpoint
• http is stateless
• http verbs get has no body
• http headers
  • referer has the url where you came from, if sensitive data in url goes to next link
• any aspect of request can be modified by an attacker
• don’t use get request for things that have data.
  • nullipotent, get a resource not adding or changing things
• millionman botnet
• hold state in database, session can be dropped.  yepper.
• should always use https for any sensitive data.
  • was a performance issue years ago but no longer
  • istlsfastyet.com
• finally a good point, should use https between application servers.  no reason not to.
• we should create default certs in our deployments so everything is https even if certs are weak since between boxes we can make each end accept certificate
• server response header should be turned off if can be, but not a big deal since it is easy for anyone to figure out what server you are using
• reviewed how cookies work
  • if you add secure flag to cookie it will stop a cookie from being sent unless the protocol is https.
  • httponly flag tell cookie you cannot be changed by the client or even be read by the client
    • blocks cross site scripting by not allowing other javascript to see your cookie
• turn off client side caching
  • cache-control/pragma response header
  • jsonp is crap
    • access-control-allow-origin
  • Content Security Policy tells browser what it can and cannot do to you on the server
    • it’s wicked complex he says
• x-frame options limits who can put you in a frame to stop click jacking
• x-xss-protection
  • stops any javascript in url from being executed
• x-content-type-options: nosniff
  • shut down browser trying to guess  your mime type
• security should be in application requirements
  • use ASVS standards as requirements so devs know security is expected.
  • ASVS 3.0
• LetsEncrypt free https
• Authenticity is another reason for https
• isps are injecting code into pages served on their networks
• cryptography is bypassed not attacked
  • old https implementations
    • ssl was original, it is dead
    • tls is what is used now
• https 2 is just coming out now
• TLS 1.o is just SSL 3.1 due to copyright issue
• Important things
  • Confidentiality
    • can’t read
  • Integrity
    • cannot change
  • Authenticity
    • know it came from who it says it came from
• Turn off ssl 3.0 entirely.  attack pretends tls is broken to forces ssl and then break it so turn off ssl 3.o
• Trustwave was selling private keys to help man in the middle attacks.
  • can’t trust your ca then you are hosed
• Certificate pinning
• strict transport security forces client to use https even if it tries not to
  • browser has to support this, most modern browsers do
  • hsts preload list
    • even a redirect to https is not as good as preload list since that first request can still be comprimised
    • include subdomains
• problem is that if any ca goes bad you have an issue hence certificate pinning
  • apriori pinning
  • we do that with our mobile app
  • tofu pinning
    • trust on first use, don’t accept if key changes
    • public key pinning extension
      • create pinning headers that can block or report
  • local authorities ignore all pinning, on purpose to support data inspection
    • users can be tricked into installing a local authority
• Passwords and hashing, oh boy
  • most passwords easily hacked
  • password hash should be slow so take long time to break, bcrypt, scrypt
  • ban common passwords
  • length makes passwords more secure
• Role based access – Access Control
  • likes to be waterfall in access control
  • Principle of least privilege
    • Jerome Saltzer and Dr Schroeder white papers forefathers of modern authorization
      • Don’t trust the infrastructure
  • General Access Control Model
    • prinicipal -> action -> guard -> protected features
  • Doesn’t like role based access
  • Attacks
    • privilege escalation
  • Bad design
    • avoid hard coded role checks
    • decentralized access control
      • need to be able to answer, what is your access control policy?
      • database map of role to feature is good
    • Untrusted data driving access control decisions
    • manual change necessary to add security to each endpoint
    • access control that is sticky in session, can’t change logged in users permissions
  • Good design
    • every request goes through centralized access control layer
    • Use filter to determine if attributes about the user allow access
    • be able to change user roles/permissions in real time
    • build grouping(roles) to make admin easier
    • lock out users if they try and make calls they aren’t allowed to make as likely an attack
  • Horizontal access control
    • make sure owner is part of query
  • Data Contextual Access Design
• tinyurl.com/codemash2016
• Cross Site Scripting(XSS)
  • httpolny on cookie stops javascript from reading cookies
  • pineapple wifi devices
    • looks like actual wifi reads traffic
    • Beef project allows injection of javascript into all calls
  • Reflected XSS
    • attacker sends a link to the victim
  • Persistent Stored XSS
    • attacker puts payload into persistence mechanism, usually db.  run later on other clients machine sends attacker data
  • Defense
    • poor defense
      • limit some character set
    • good defense
      • encoding output where it is displayed with appropriate encoding
      • httponly cookies
      • sandbox 3rd party javascript
  • Proper Encoding of all output to the screen will block almost all xss attacks.
  • InnerHtml — real big arse issue here
    • parses any script in the argument if malicious js is in argument it will be processed, this is a real attack vector
  • Validation does not imply security
  • protecting untrusted links in your code
    • validate url is a proper format
    • allow only http or https
      • javascript: is a scheme that is legal url that allows malicious javascript execution
    • check url for malware – api’s for checking if url is pointing at malware
      • check on daily output to make sure url has not be repointed to malware
    • encode url in the context of display
    • EVERY VARIABLE SHOULD BE ENCODED IN THE PROPER CONTEXT
  • HTML sanitization
    • different from encoding
    • tinyMCE
      • sometimes want to execute code that was inputted
      • need to sanitize so allows some but not all functionality
      • use formal 3rd party sanitizer, writing your own will be painful
  • Sandboxing
    • iframe with sandbox attribute blocks it off
      • ad agency pays less if iframe add since they get less user data
  • x-xss-protection header
  • xss protection with no encoding
    • deliver html with static/safe data only in the html
  • Cross Site Request Forgery
    • cookie for a domain go to domain regardless of where initiation is done
    • go to evil website if you are logged into target evil site can execute against target via javascript or src on images
    • Defense
      • side effects should be done through a post, then only need to defend posts for x-site scripting
      • check for definitely invalid http referers
        • empty referers are normal, but bad referers can be identified
      • force reauthentication for significant events
      • move session ids out of cookies so don’t ride along on attack post
    • Synchronizer token pattern
      • create unique token per session per user
        • put this value in hidden field and check it on every submission make sure it matches
      • supported by most frameworks, just need to enable and configure it
    • new header for CORS
      • origin header
      • tells you origin of the request – white list
      • need to have header sent in order to use
        • referrer can be used as a backup
          • it isn’t always there but usually is
          • can drop empty requests or let it go through, very small percentage have no origin or referrer
  • Life Cycle Thoughts
    • provide actionable security requirements before starting coding
  • Threat Modeling
    • lightweight and ad-hoc and informal unless you are a bank
    • discussing a non functional requirement can lead to some ad-hoc threat modeling
  • Provide developers Secure Coding Libraries
    • provide tools so they same tools are used across the entity using same tools
      • one so we  know the choosen tools work
      • two so we know the devs are using tools that work
  • Fork ASVS 3.o and alter it to be your standard
  • Checklists help professionals make sound choices in stressful circumstances:  example pilots use them even though they know how to fly a plane.
  • Scans and reviews
    • Dynamic Scans are quick and cheap but man false positives
    • Manual pen testing expensive and lengthy but gives good results
    • Manual code review code buy time consuming
    • Automatic code scans many false positives but quick and cheap