1
00:00:00,042 --> 00:00:02,709
KENNETH LEE: Yeah, so just letting you

2
00:00:02,709 --> 00:00:05,999
all know I posted a copy of the slides on my Twitter,

3
00:00:05,999 --> 00:00:08,083
which is @Kennysan.

4
00:00:08,250 --> 00:00:11,125
So if you want to follow along, you can just download a copy

5
00:00:11,125 --> 00:00:13,876
the speaker deck from there.

6
00:00:14,999 --> 00:00:16,542
Let's begin.

7
00:00:16,542 --> 00:00:17,792
Hi, DEF CON.

8
00:00:17,999 --> 00:00:20,250
(Applause.)    KENNETH LEE: So this is my talk, How

9
00:00:20,250 --> 00:00:24,709
to Use Content Security Policy to Stop Crosssite Scripting.

10
00:00:24,834 --> 00:00:27,709
First a little bit of detail about myself.

11
00:00:27,709 --> 00:00:28,999
My name is Ken Lee.

12
00:00:28,999 --> 00:00:31,751
I'm a product security engineer at Etsy.com.

13
00:00:31,999 --> 00:00:36,501
In a previous life, I worked at a financial software company.

14
00:00:36,542 --> 00:00:41,167
As I just told you literally 30 seconds ago, my Twitter handle is @Kennysan.

15
00:00:41,626 --> 00:00:44,626
If you have any questions, you can feel free to e mail me

16
00:00:44,626 --> 00:00:46,876
or send me a Tweet.

17
00:00:47,167 --> 00:00:48,999
So let's talk about content security policy

18
00:00:48,999 --> 00:00:52,792
because I assume that's the reason you're all sitting here today.

19
00:00:53,083 --> 00:00:55,918
The best way I've heard content security described,

20
00:00:55,918 --> 00:00:58,999
it's essentially depth for the web.

21
00:00:59,125 --> 00:01:03,667
By that I mean, it is a way to tell for a server to tell your browser,

22
00:01:03,667 --> 00:01:06,167
you're allowed to execute certain things,

23
00:01:06,167 --> 00:01:10,250
and only these things that I tell you to execute.

24
00:01:10,417 --> 00:01:12,999
By doing that, it provides for a mechanism

25
00:01:12,999 --> 00:01:16,751
to stop crosssite scripting from happening.

26
00:01:16,959 --> 00:01:18,999
Just by a show of hands, how many people

27
00:01:18,999 --> 00:01:22,209
in this room know what crosssite scripting is?

28
00:01:22,209 --> 00:01:23,209
Okay.

29
00:01:23,209 --> 00:01:24,209
All right.

30
00:01:24,209 --> 00:01:26,876
Then this slide is going to go extremely quickly.

31
00:01:27,751 --> 00:01:30,999
So, for example, I take a page to HTML and I throw

32
00:01:30,999 --> 00:01:34,876
a simple crosssite scripting inside of it.

33
00:01:34,876 --> 00:01:36,999
This page has content security policy on it.

34
00:01:36,999 --> 00:01:41,292
If you look at the bottom of the page, the actual execution of the script

35
00:01:41,292 --> 00:01:45,999
is blocked by the presence of a content security policy.

36
00:01:46,250 --> 00:01:49,792
That's sort of basically how it works.

37
00:01:49,792 --> 00:01:52,999
Now, for more detail, the way that it works is that

38
00:01:52,999 --> 00:01:58,292
a browser that is following a content security policy only follows

39
00:01:58,292 --> 00:02:03,167
specific directives specified by the content security policy

40
00:02:03,167 --> 00:02:09,375
as elements that it's allowed to render or execute on the page.

41
00:02:09,626 --> 00:02:12,584
In particular, the two important things to note

42
00:02:12,584 --> 00:02:15,125
about this is that content security policy

43
00:02:15,125 --> 00:02:19,292
by default disallows the use of inline JavaScript on a page, which

44
00:02:19,292 --> 00:02:22,792
is a big thing that I'll get to later.

45
00:02:22,792 --> 00:02:27,083
And in addition, it prevents the use of the eval style family

46
00:02:27,083 --> 00:02:30,167
of functions in JavaScript.

47
00:02:31,250 --> 00:02:34,083
So I'm just kind of throwing this up there.

48
00:02:34,083 --> 00:02:37,083
This is an example content security policy header.

49
00:02:37,083 --> 00:02:39,834
You know, you're not expected to understand this.

50
00:02:39,834 --> 00:02:41,501
There will be no quiz later on this.

51
00:02:41,501 --> 00:02:44,959
This is to demonstrate what a content security policy looks like.

52
00:02:44,959 --> 00:02:49,709
It's basically specified as a set of directives with a set of URIs

53
00:02:49,709 --> 00:02:54,459
and keywords that tells the browser what you are allowed

54
00:02:54,459 --> 00:02:59,375
to execute JavaScript and other elements from.

55
00:02:59,876 --> 00:03:02,417
So content security policy, as I've said before, is broken

56
00:03:02,417 --> 00:03:04,959
up into a series of directives.

57
00:03:04,999 --> 00:03:07,626
The most common ones that you will probably end

58
00:03:07,626 --> 00:03:11,626
up using are directives such as script source, which controls

59
00:03:11,626 --> 00:03:15,959
the use of JavaScript on a page; style source, which controls use

60
00:03:15,959 --> 00:03:19,083
of CSS and other styling on a page.

61
00:03:19,083 --> 00:03:21,626
And as you can see here, there's a directive

62
00:03:21,626 --> 00:03:25,292
for pretty much most types of things that you can embed

63
00:03:25,292 --> 00:03:27,250
on a web page.

64
00:03:27,626 --> 00:03:30,709
In addition to that, there are also special keywords that

65
00:03:30,709 --> 00:03:33,542
you can use in combination with the directives

66
00:03:33,542 --> 00:03:36,999
to modify your content security policy.

67
00:03:36,999 --> 00:03:38,999
So, for example, specifying a keyword of "none"

68
00:03:38,999 --> 00:03:43,417
for script source directive tells the browser don't accept any sources,

69
00:03:43,417 --> 00:03:46,999
don't allow any JavaScript from any source.

70
00:03:47,083 --> 00:03:50,167
The self directive is pretty self explanatory.

71
00:03:50,167 --> 00:03:53,584
It basically says for only allow content

72
00:03:53,584 --> 00:03:58,292
from the same subdomain and scheme.

73
00:03:58,999 --> 00:04:02,999
And the "unsafe inline" and "unsafe eval" are special keywords

74
00:04:02,999 --> 00:04:06,250
that actually override the default functionality that

75
00:04:06,250 --> 00:04:10,501
I mentioned before with regards to content security policy blocking

76
00:04:10,501 --> 00:04:13,125
inline JavaScript and eval.

77
00:04:14,584 --> 00:04:17,876
So, an important aspect of content security policy that I'm going

78
00:04:17,876 --> 00:04:20,999
to go into is the use of "Report Only Mode" .

79
00:04:20,999 --> 00:04:23,792
Report Only Mode, basically it's appended to the end

80
00:04:23,792 --> 00:04:29,375
of your content security policy header or content security policy meta tag.

81
00:04:29,375 --> 00:04:35,083
What this allows you to do is it tells the browser, I want you

82
00:04:35,083 --> 00:04:40,209
to not actually block elements that are disallowed

83
00:04:40,209 --> 00:04:44,417
by the content security policy.

84
00:04:44,417 --> 00:04:46,667
So it's essentially a dry run.

85
00:04:46,667 --> 00:04:50,083
And what makes this functionality even more powerful is the use

86
00:04:50,083 --> 00:04:52,167
of a report URI.

87
00:04:52,250 --> 00:04:55,083
So at the end of your content security policy you can

88
00:04:55,083 --> 00:04:58,250
actually specify a reporting end point which tells

89
00:04:58,250 --> 00:05:00,999
the browser, hey, you've seen some bad shit

90
00:05:00,999 --> 00:05:06,459
with content security policy violations, send those violations my way.

91
00:05:06,459 --> 00:05:09,083
And this basically provides a mechanism for the server

92
00:05:09,083 --> 00:05:12,542
to learn what kind of content security policy violations

93
00:05:12,542 --> 00:05:14,918
the server is seeing.

94
00:05:15,083 --> 00:05:16,417
And again, to emphasize, what's important

95
00:05:16,417 --> 00:05:19,999
about report only mode is that it doesn't actually block.

96
00:05:19,999 --> 00:05:22,292
So you can deploy this without actually affecting content that

97
00:05:22,292 --> 00:05:24,417
the client is seeing.

98
00:05:26,083 --> 00:05:30,125
So an important aspect to note is that content security policy

99
00:05:30,125 --> 00:05:33,250
as a standard is still evolving.

100
00:05:33,250 --> 00:05:35,083
This little snippet of a screenshot was taken

101
00:05:35,083 --> 00:05:38,626
from a version of Firefox not too long ago.

102
00:05:38,876 --> 00:05:40,459
It's hard to read the text.

103
00:05:40,459 --> 00:05:44,125
What it basically says is, CSP 1 failed to parse, unrecognized,

104
00:05:44,125 --> 00:05:46,999
directive unsafe inline.

105
00:05:47,125 --> 00:05:49,584
Firefox at the time that the screenshot was taken had

106
00:05:49,584 --> 00:05:52,167
a bug where it didn't recognize the unsafe inline

107
00:05:52,167 --> 00:05:54,626
or unsafe eval directive.

108
00:05:54,959 --> 00:05:59,959
And I think the latest version of Firefox, Firefox 23, actually still has

109
00:05:59,959 --> 00:06:03,999
a bug where it doesn't allow you to white list unsafe style

110
00:06:03,999 --> 00:06:05,999
source elements.

111
00:06:06,459 --> 00:06:08,999
So like I said, browsers these days are mostly

112
00:06:08,999 --> 00:06:11,999
up to spec with regards to CSP 1.0 compliance,

113
00:06:11,999 --> 00:06:15,792
but if you happen to notice in the process of your testing

114
00:06:15,792 --> 00:06:20,459
for content security policy that you're seeing unexpected behavior, there

115
00:06:20,459 --> 00:06:25,083
is a strong possibility it may not necessarily be your content security

116
00:06:25,083 --> 00:06:28,083
policy, it could be the client's browser acting

117
00:06:28,083 --> 00:06:30,626
like a smelly lobster.

118
00:06:31,999 --> 00:06:36,250
So let's talk a little bit more in detail about the inline JavaScript bit

119
00:06:36,250 --> 00:06:38,959
that I alluded to earlier.

120
00:06:38,959 --> 00:06:41,083
So as I mentioned, content security policy 1.0 disallows

121
00:06:41,083 --> 00:06:44,999
by default the use of inline JavaScript on a page.

122
00:06:44,999 --> 00:06:47,959
This is kind of a big deal.

123
00:06:47,999 --> 00:06:51,999
The way that is recommended to sort of deal with inline JavaScript

124
00:06:51,999 --> 00:06:57,334
is to create external scripts out of all your inline JavaScript.

125
00:06:57,876 --> 00:06:59,999
This has kind of a number of implications,

126
00:06:59,999 --> 00:07:03,083
the biggest one being that you're essentially turning

127
00:07:03,083 --> 00:07:06,999
all these inline bits of JavaScript into synchronous calls that

128
00:07:06,999 --> 00:07:10,999
the browser has to retrieve the JavaScript from.

129
00:07:11,250 --> 00:07:12,999
Alternatively, if you want to get around this,

130
00:07:12,999 --> 00:07:15,209
you can always specify the, as I mentioned before,

131
00:07:15,209 --> 00:07:17,584
the unsafe inline directive.

132
00:07:17,584 --> 00:07:20,999
But this has implications for defeating, basically weakening the strength

133
00:07:20,999 --> 00:07:23,834
of you content security policy.

134
00:07:24,083 --> 00:07:28,999
And in addition, if you use any kind of asynchronous job script loading

135
00:07:28,999 --> 00:07:34,417
library, such as RequireJS, this also has implications as well.

136
00:07:34,417 --> 00:07:36,626
Because RequireJS and other asynchronous job script

137
00:07:36,626 --> 00:07:41,209
loading libraries, what they like to do is they essentially like to say, hey,

138
00:07:41,209 --> 00:07:44,584
I want to load this bit of JavaScript, so at some point

139
00:07:44,584 --> 00:07:47,083
during the rendering of the page I'm going

140
00:07:47,083 --> 00:07:50,584
to basically call appendChild to the head of the document

141
00:07:50,584 --> 00:07:53,792
with the contents of the JavaScript.

142
00:07:53,834 --> 00:07:56,083
And because this is all done asynchronously,

143
00:07:56,083 --> 00:07:58,083
it's very fast.

144
00:07:58,083 --> 00:08:00,083
There's no additional HTTP call, but the problem is that's going

145
00:08:00,083 --> 00:08:03,459
to cause issues with content security policy 1.0.

146
00:08:04,876 --> 00:08:07,999
So as a result, there are potential performance

147
00:08:07,999 --> 00:08:12,125
implications to deploying CSP 1.0 by turning all of your scripts

148
00:08:12,125 --> 00:08:15,709
into externalized bits of JavaScript.

149
00:08:15,959 --> 00:08:21,709
Hopefully, content security policy 1.1 will fix that.

150
00:08:21,709 --> 00:08:24,918
As of right now they're sort of working out the final bits of the spec,

151
00:08:24,918 --> 00:08:29,083
but there will essentially be a way to safely white list inline JavaScript

152
00:08:29,083 --> 00:08:30,876
on the page.

153
00:08:32,209 --> 00:08:35,083
So, let me talk about some real world implications

154
00:08:35,083 --> 00:08:37,584
about deploying a content security policy

155
00:08:37,584 --> 00:08:40,083
to your production website.

156
00:08:45,999 --> 00:08:48,459
So oh my God, this is terrible.

157
00:08:50,334 --> 00:08:53,083
So, there's a couple questions that a lot of you probably have

158
00:08:53,083 --> 00:08:55,167
if you want to if you're thinking about rolling

159
00:08:55,167 --> 00:08:58,250
out a content security policy to your website.

160
00:08:58,250 --> 00:09:01,626
For example, how should you go about it?

161
00:09:02,626 --> 00:09:06,584
How should you test the validity of your content security policy?

162
00:09:06,876 --> 00:09:10,999
And what bits should you throw the content security policy onto?

163
00:09:11,417 --> 00:09:15,292
A number of websites; Twitter, for example, have chosen to focus

164
00:09:15,292 --> 00:09:20,999
the content security policy on specific segments of their website.

165
00:09:20,999 --> 00:09:22,792
And this actually makes a lot of sense

166
00:09:22,792 --> 00:09:25,667
from a metric standpoint because it gives you

167
00:09:25,667 --> 00:09:28,584
a very focused approach to applying and fixing

168
00:09:28,584 --> 00:09:32,999
the issues that your content security policy detects.

169
00:09:33,751 --> 00:09:37,999
So these are two just graphs of Splunk, showing a hit count

170
00:09:37,999 --> 00:09:42,167
of content security policy violations that have been sent

171
00:09:42,167 --> 00:09:45,999
from client browsers using the report only directive

172
00:09:45,999 --> 00:09:49,792
to an end point that I've specified.

173
00:09:49,792 --> 00:09:53,834
And in addition, this the bottom graph shows a list

174
00:09:53,834 --> 00:09:56,667
of top blocked URIs.

175
00:09:56,999 --> 00:09:59,999
So what's really powerful about content security policy

176
00:09:59,999 --> 00:10:05,167
is if you specify a report only end point, you can use this to essentially learn

177
00:10:05,167 --> 00:10:08,501
all the things about about content security policy

178
00:10:08,501 --> 00:10:11,834
violations that clients are seeing.

179
00:10:11,999 --> 00:10:15,375
And this potentially has some really interesting implications.

180
00:10:15,375 --> 00:10:18,375
In the process of looking into content security policy

181
00:10:18,375 --> 00:10:23,626
during the evolution of the spec, one of the things I noticed was

182
00:10:23,626 --> 00:10:30,209
the fact that you end up seeing a lot of mixed content on your website.

183
00:10:30,209 --> 00:10:32,709
And the nice thing about content security policy

184
00:10:32,709 --> 00:10:36,999
is that it's actually really effective at helping you root out and stamp

185
00:10:36,999 --> 00:10:41,459
out all those instances of mixed content on your website.

186
00:10:41,667 --> 00:10:44,167
So essentially the technique that one can use

187
00:10:44,167 --> 00:10:47,542
for detecting this mixed content on your website

188
00:10:47,542 --> 00:10:52,918
is if you specify content security policy and you have a reporting end point,

189
00:10:52,918 --> 00:10:57,292
if you see the reporting end point, the browser essentially sends

190
00:10:57,292 --> 00:11:00,751
a JSON blog to the reporting end point containing

191
00:11:00,751 --> 00:11:05,125
information such as document URI, the URI of the blocked element,

192
00:11:05,125 --> 00:11:09,999
what have you, and so basically if you just parse this blog and detect

193
00:11:09,999 --> 00:11:13,083
if the scheme of the document scheme that was

194
00:11:13,083 --> 00:11:16,584
retrieved was HTTPS, and the blocked URI was HTTP,

195
00:11:16,584 --> 00:11:21,667
then you have an instance of mixed content on your website.

196
00:11:22,584 --> 00:11:26,584
Certain headers such as the HTTP strict transport security

197
00:11:26,584 --> 00:11:31,834
can actually be an effective approach in essentially removing mixed content

198
00:11:31,834 --> 00:11:34,626
from your website because this will force

199
00:11:34,626 --> 00:11:37,626
all your subdomains to HTTPS.

200
00:11:37,626 --> 00:11:40,501
But from an implementation standpoint, from experience,

201
00:11:40,501 --> 00:11:43,667
I've discovered that most of the issues you'll run

202
00:11:43,667 --> 00:11:46,999
into with mixed content on your website when rolling

203
00:11:46,999 --> 00:11:51,501
out a content security policy won't be from your own subdomain, surprise,

204
00:11:51,501 --> 00:11:55,334
surprise, it will actually be coming from, in most instances,

205
00:11:55,334 --> 00:12:01,083
third party vendors who simply don't have HTTPS end point for their website.

206
00:12:03,626 --> 00:12:05,999
So a couple thoughts, additional thoughts

207
00:12:05,999 --> 00:12:08,792
about content security policy.

208
00:12:08,792 --> 00:12:11,083
As I mentioned before, unsafe inline and unsafe eval

209
00:12:11,083 --> 00:12:15,876
essentially severely nerf their protective abilities that content security policy

210
00:12:15,876 --> 00:12:17,584
gives to you.

211
00:12:17,999 --> 00:12:21,209
So it's important when deploying a content security policy

212
00:12:21,209 --> 00:12:23,834
to consider whether or not you should include

213
00:12:23,834 --> 00:12:26,584
these directives in your policy.

214
00:12:26,626 --> 00:12:30,792
In addition, content security policy can, if you choose to implement it

215
00:12:30,792 --> 00:12:34,083
as a header, you can potentially be including a very,

216
00:12:34,083 --> 00:12:36,999
very large number of sources in your policy,

217
00:12:36,999 --> 00:12:41,792
and that can cause your header sizes to grow, which can potentially have

218
00:12:41,792 --> 00:12:44,292
an impact on performance.

219
00:12:44,584 --> 00:12:47,167
And the final last point, you should always make an effort

220
00:12:47,167 --> 00:12:52,083
to test your content security policy before you roll out to production.

221
00:12:53,083 --> 00:12:58,083
So let me get to the final, the good bits, before talking about the tool I created.

222
00:12:58,459 --> 00:13:01,959
So if you want to test content security policy right

223
00:13:01,959 --> 00:13:07,751
now, live, it's a thing that exists in Firefox 23 and Chrome 25.

224
00:13:07,751 --> 00:13:12,584
Previous versions of this browser used, I believe, the X content security policy

225
00:13:12,584 --> 00:13:15,250
header for older versions of Firefox and

226
00:13:15,250 --> 00:13:18,751
the X WebKit CSP Header for Chrome.

227
00:13:18,876 --> 00:13:22,999
And if you want, you can test this out, you can apply

228
00:13:22,999 --> 00:13:27,292
the "report only" header or as a meta tag to simply have

229
00:13:27,292 --> 00:13:32,167
the browser attempt to attempt to basically not block instances

230
00:13:32,167 --> 00:13:36,999
of bad JavaScript or style elements that it sees.

231
00:13:37,125 --> 00:13:39,626
In addition, the report URI is tremendously powerful

232
00:13:39,626 --> 00:13:43,626
from a metrics perspective just because of the fact that it can give you

233
00:13:43,626 --> 00:13:46,999
so much information on what clients are actually potentially

234
00:13:46,999 --> 00:13:49,999
seeing in terms of blocked content.

235
00:13:50,083 --> 00:13:54,125
And with the ability to monitor all of this blocked content via either

236
00:13:54,125 --> 00:13:58,918
Splunk, or Status V, or Graphite, or some other logging metrics tool you

237
00:13:58,918 --> 00:14:03,999
use, it gives you the ability to look into and fix all of your inline JavaScript

238
00:14:03,999 --> 00:14:08,999
issues that are caused by deploying a content security policy.

239
00:14:09,959 --> 00:14:11,459
All right.

240
00:14:11,459 --> 00:14:12,083
So let me talk a little bit more indepth

241
00:14:12,083 --> 00:14:14,167
about the tool I'm releasing.

242
00:14:14,667 --> 00:14:17,125
So one problem that I initially ran into when deploying

243
00:14:17,125 --> 00:14:20,999
a content security policy was that it was actually really annoying

244
00:14:20,999 --> 00:14:24,417
to test my content security policy in a development environment

245
00:14:24,417 --> 00:14:27,667
and then push it to production because of the very nature

246
00:14:27,667 --> 00:14:31,334
of the fact that in production, I would have to specify prod hosts,

247
00:14:31,334 --> 00:14:34,709
and in dev I would have to use dev hosts.

248
00:14:34,709 --> 00:14:36,417
It was annoying to the point I didn't want to have

249
00:14:36,417 --> 00:14:40,542
to constantly poison my host file to have to handle this.

250
00:14:40,626 --> 00:14:42,584
So I decided, F it, I'm going to make some tools

251
00:14:42,584 --> 00:14:44,999
to help me fix this problem.

252
00:14:46,375 --> 00:14:51,876
So CSP Tools is essentially a set of three python based tools that do

253
00:14:51,876 --> 00:14:55,209
the following: The proxy tool is essentially

254
00:14:55,209 --> 00:15:00,542
a python proxy written using live in proxy that intercepts all HTTP

255
00:15:00,542 --> 00:15:02,999
and HTTPS traffic.

256
00:15:03,125 --> 00:15:06,083
What you will do if you connect to this proxy, it will insert,

257
00:15:06,083 --> 00:15:09,167
dynamically insert a content security policy report only

258
00:15:09,167 --> 00:15:12,209
header with the policy you specified.

259
00:15:12,667 --> 00:15:15,876
In addition, the proxy will capture any content security policy

260
00:15:15,876 --> 00:15:20,083
violations the browser sends back to the proxy end point.

261
00:15:20,459 --> 00:15:22,083
The browser tool is basically

262
00:15:22,083 --> 00:15:25,167
a selenium powered instance of FireFox, what that does

263
00:15:25,167 --> 00:15:29,542
is allows you to create uni tests for content security policies that you've

264
00:15:29,542 --> 00:15:32,999
deployed to specific pages on your website.

265
00:15:33,167 --> 00:15:35,542
And finally, the parsement tool, which is fairly self explanatory,

266
00:15:35,542 --> 00:15:38,250
what that does    AUDIENCE: Excuse me, hi.

267
00:15:40,834 --> 00:15:43,709
So have you attended any Cons?

268
00:15:43,751 --> 00:15:47,083
KENNETH LEE: In past DEF CONS, yes.

269
00:15:47,083 --> 00:15:48,083
AUDIENCE: Okay.

270
00:15:48,083 --> 00:15:49,999
So we're here to actually help you out.

271
00:15:49,999 --> 00:15:52,083
This is your first time speaking; right?

272
00:15:52,083 --> 00:15:53,125
KENNETH LEE: Yeah.

273
00:15:53,125 --> 00:15:54,667
AUDIENCE: How's he doing?

274
00:15:54,667 --> 00:15:57,751
(Applause.) THE AUDIENCE: As many of you know, we have a little tradition,

275
00:15:57,751 --> 00:16:04,792
as our speaker does not seem to know, where all the first time speakers must

276
00:16:04,792 --> 00:16:06,584
do shots.

277
00:16:06,584 --> 00:16:10,125
We also have some other first time attendees to DEF CON.

278
00:16:16,292 --> 00:16:18,999
(Applause.)    AUDIENCE: There you are.

279
00:16:18,999 --> 00:16:20,584
KENNETH LEE: Thank you, sir.

280
00:16:20,584 --> 00:16:22,125
AUDIENCE: Congratulations.

281
00:16:24,709 --> 00:16:25,999
Cheers.

282
00:16:28,792 --> 00:16:31,876
KENNETH LEE: Oh, my God.

283
00:16:31,876 --> 00:16:35,125
AUDIENCE: Now, where's Heather?

284
00:16:35,250 --> 00:16:36,792
Heather, raise your hand.

285
00:16:36,792 --> 00:16:39,083
Yep, it's Heather's first time at DEF CON, too.

286
00:16:39,083 --> 00:16:41,501
Give it up for Heather.

287
00:16:41,501 --> 00:16:44,959
(Applause.)    KENNETH LEE: All good.

288
00:16:44,959 --> 00:16:46,999
AUDIENCE: And now back to our regularly scheduled oh, shit,

289
00:16:46,999 --> 00:16:48,792
your time's up.

290
00:16:48,792 --> 00:16:51,918
KENNETH LEE: Sorry folks, no demo.

291
00:16:51,918 --> 00:16:52,959
Just kidding.

292
00:16:53,167 --> 00:16:57,334
So here's a little demo of the CSP proxy at work.

293
00:16:57,334 --> 00:17:00,125
I'm browsing through this site, www.etsy.com, you may have heard

294
00:17:00,125 --> 00:17:01,999
of it before.

295
00:17:02,209 --> 00:17:05,083
Wow, that really hit me hard.

296
00:17:05,083 --> 00:17:08,167
So I'm going to the console to demonstrate.

297
00:17:08,167 --> 00:17:10,417
There's no tricks up my sleeve.

298
00:17:10,417 --> 00:17:12,292
No content security policy here.

299
00:17:12,292 --> 00:17:13,959
Going to the network tab to showing you

300
00:17:13,959 --> 00:17:17,083
the Get request does not have content security policy specified

301
00:17:17,083 --> 00:17:18,999
in the response.

302
00:17:19,083 --> 00:17:23,626
So scrolling back down, you can see, no tricks here.

303
00:17:23,999 --> 00:17:27,083
So I'm going in a second, when this really slow video demo

304
00:17:27,083 --> 00:17:29,999
finishes, I'm going to change my proxy settings

305
00:17:29,999 --> 00:17:33,459
for Chrome to specify using a proxy 8080.

306
00:17:35,417 --> 00:17:39,292
If I'm talking a little slower, it's because I just had a lot of alcohol.

307
00:17:40,626 --> 00:17:42,876
And now more alcohol.

308
00:17:43,250 --> 00:17:47,999
(Applause.)    KENNETH LEE: Yeah.

309
00:17:47,999 --> 00:17:50,999
So I'm starting up a proxy on and I'm specifying a host

310
00:17:50,999 --> 00:17:55,167
of www.etsy.com, and then I'm going to reload the page now that

311
00:17:55,167 --> 00:17:58,459
the browser is using this proxy.

312
00:17:58,501 --> 00:18:00,876
And you can see here from loading the page,

313
00:18:00,876 --> 00:18:04,584
it's seeing some content security policy violations.

314
00:18:04,999 --> 00:18:07,876
If you look at the initial "Get" request we can see that

315
00:18:07,876 --> 00:18:11,834
a content security policy report only header is in the first response

316
00:18:11,834 --> 00:18:13,751
from the server.

317
00:18:13,959 --> 00:18:15,250
And if we and we can see here

318
00:18:15,250 --> 00:18:19,584
a content security policy violation being sent back to the proxy.

319
00:18:19,709 --> 00:18:22,501
And in addition, we have a number of content security violations being

320
00:18:22,501 --> 00:18:24,584
logged on the console.

321
00:18:24,584 --> 00:18:27,709
So that's essentially how the proxy tool works.

322
00:18:27,999 --> 00:18:30,876
If you actually look into the log file that's generated

323
00:18:30,876 --> 00:18:35,834
by the proxy, all it is, like I said before, no lies, I wouldn't do that to you guys,

324
00:18:35,834 --> 00:18:39,792
it's just simply JSON logs of the content security policy violations

325
00:18:39,792 --> 00:18:42,792
that the proxy has logged to disk.

326
00:18:43,792 --> 00:18:45,250
All right.

327
00:18:45,250 --> 00:18:49,375
So now this next video is demoing the parser and browser tool.

328
00:18:49,375 --> 00:18:53,083
I'm going to load up the proxy again, this time on port 8090, and I'm going

329
00:18:53,083 --> 00:18:56,999
to fire off the selenium powered browser tool.

330
00:18:57,083 --> 00:19:01,459
And I've specified a number of URIs, specifically five, and a number

331
00:19:01,459 --> 00:19:05,667
of HTTP and HTTPS links for the browser to log to.

332
00:19:05,667 --> 00:19:09,501
And since I've specified my proxy on port 8090 for the browser to use,

333
00:19:09,501 --> 00:19:12,999
it's going to connect directly to the proxy and send,

334
00:19:12,999 --> 00:19:17,751
as you can see in the background, send content security policy violations

335
00:19:17,751 --> 00:19:20,083
directly to the proxy.

336
00:19:20,125 --> 00:19:22,999
So you can see here, I'm browsing a couple of URIs, first

337
00:19:22,999 --> 00:19:25,709
the front page of Etsy, now some HTTPS links,

338
00:19:25,709 --> 00:19:28,751
which it loads just fine, and you can tell the proxy

339
00:19:28,751 --> 00:19:31,999
is chugging away happily because it basically just logs

340
00:19:31,999 --> 00:19:36,209
all content security policy violations right off the bat.

341
00:19:38,999 --> 00:19:41,459
And I'm going to jump ahead.

342
00:19:41,459 --> 00:19:45,999
So I implemented this using basically selenium.

343
00:19:45,999 --> 00:19:47,999
If you really wanted to, you could modify this to make

344
00:19:47,999 --> 00:19:52,501
the whole thing run headless so you don't have to see the browser running.

345
00:19:52,542 --> 00:19:57,209
So now we close down the proxy after the browser is done running.

346
00:19:57,209 --> 00:19:59,876
We're going to look at our CSP violations.

347
00:19:59,876 --> 00:20:01,417
You can see we have a ton of them and they've hit

348
00:20:01,417 --> 00:20:04,999
the URIs that we specified, which is excellent.

349
00:20:04,999 --> 00:20:06,999
So now we can go about the process of making

350
00:20:06,999 --> 00:20:10,792
a content security policy using the parsing tool and, damn,

351
00:20:10,792 --> 00:20:13,250
we just created a content security policy

352
00:20:13,250 --> 00:20:15,250
for our website.

353
00:20:22,999 --> 00:20:26,999
(Applause.)    KENNETH LEE: So, yeah, if you want to get CSP Tools,

354
00:20:26,999 --> 00:20:30,709
it's available on GitHub at the following URL.

355
00:20:30,999 --> 00:20:33,501
Feel free to issue pool requests if you find bugs

356
00:20:33,501 --> 00:20:35,667
with my implementation.

357
00:20:36,000 --> 00:20:38,999
If you have questions, hit me up afterwards in the QA lounge or

358
00:20:38,999 --> 00:20:42,584
on Twitter, which is, again, Kennysan if you would like to view a copy

359
00:20:42,584 --> 00:20:44,375
of these slides.

360
00:20:44,375 --> 00:20:46,250
I'd also like to give a huge shout out to Kai San

361
00:20:46,250 --> 00:20:49,876
for helping me tremendously with the initial implementation of CSP,

362
00:20:49,876 --> 00:20:52,918
and also just a general shout out to the Etsy security team

363
00:20:52,918 --> 00:20:55,167
of being tremendously supportive of my efforts

364
00:20:55,167 --> 00:20:58,250
in implementing content security policy.

365
00:20:58,501 --> 00:21:01,918
(Applause.)    AUDIENCE: Drink.

366
00:21:01,999 --> 00:21:06,876
KENNETH LEE: Oh, my God.

367
00:21:06,999 --> 00:21:08,125
Okay.

368
00:21:08,375 --> 00:21:09,459
Oh, my God.

369
00:21:15,501 --> 00:21:18,125
You guys are the worst I mean the best.

370
00:21:22,542 --> 00:21:25,334
So again, if you want to ask questions, the QA lounge

371
00:21:25,334 --> 00:21:28,626
outside is the appropriate place to be asking them, at least

372
00:21:28,626 --> 00:21:30,999
from what I've been told.

373
00:21:30,999 --> 00:21:31,999
So thank you.