http security headers at app sec usa

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

November 2013
M T W T F S S
« Oct   Dec »
 123
45678910
11121314151617
18192021222324
252627282930  

Past Posts

Java/Java EE

JDBC

Other

http security headers at app sec usa

November 20th, 2013 by Jeanne Boyarsky

speaker: Kenneth Lee

Why care:

  • User security issue
  • Browser impacting change

HSTS (HTTP Strict Transport Security)

  • Use of SSL/TLS for site
  • When send his header, browsers wil guarantee to visit the url
  • User needs to visit the website a least once in order to receive the header.
  • Protect against man in the middle attack
  • But don’t want to make whole site HTTPS – capacity planning assumed less https. Wen ready to make whole site HTTS, this setting becomes deprecated
  • Need to prevent load balancer from always sending batck to http so doesn’t loop
  • He talked about the design Etsy used to implement this
  • Since multiple users can have accounts that use th same machine, set timeout to 0 so dont get other person’s preferences.
  • Browser handles via 302s transparently.
  • Need to make sure your CDN supports it. Similarly for 3rd party content providers. Can’t use off domain HTTP because browser dispays mixed content warnings. Firefox and Chrome block it by default.
  • IE and Safari mobile don’t support yet. Can’t use this header to solve routing problems.

X-Frame Options (XFO)

  • prevent clickjacking/framing website
  • used to have to use JavaScript to avoid being framed.
  • Can use JavaScript to log who framing you (if don’t know) so have list of sites that can frame you. Then you can create whitelist
  • Newer option allow from whitelist. Older browsers don’t support though
  • Warn users if taking away framing. Maybe someone is using it to frame a product. Give alternate way to show content they want to show.

CSP (content security policy)

  • If transfering header on each request, it can get large quickly
  • Doesn’t allow inline JavaScript on a website by defaut.
  • Can’t whitelist inline JavaScript in CSP 1.0. Problem because most apps do have – unless they are quite new
  • Can’t refactor everything right away
  • CSP 1.1 adds browser JavaScript API support.
  • CSP 1.1 adds puting in meta tag rather than a header. Will use as CSP from meta tag unless there already is a header.
  • CSP 1.1 also adds script-nonce (random value) and script-hash (hash of inline JavaScript in question) to allow inline JavaScript. CDN reuires hash because nonce won’t be random.
  • Can use reporting to log blocked element info
  • cspisawesome.com – good website to craft your own policy

X-XSS-Protection

  • Used to be IE specific
  • Now in Chrome too. Added a report URL mechanism
  • Looks for parameter arguments in response
  • This originally was used to break Clickjacking defensive JavaScript

X-Content-Type-Options

  • Defaults to nosniff
  • Older verisions of IE guesed content type even if specified
  • Took advantage of different content type than page author intended to make XSS attack

My take
The code example was really small. He said you could dowload the presentation to follow along but I didn’t have internet at all in this room. Plus a lot of people were taking note on paper without a device. There was was plenty of space on the slide. He could have split the line across and lines and use a decent font size.

The actual content had a lot that I didn’t know which was good. I knew about X-Frame options. The rest was new to me. I had heard about CSP 1.0 when it came out but “you can’t use it if you have any in-line JavaScript” made it a nonstarter.

[this wasn’t posted live due to lack of internet]

Write a comment