Dan Kaminsky discusses the challenges of web security, particularly focusing on the limitations of the same origin policy and malvertising. He introduces various concepts such as 'nice.js' for monitoring browser performance and 'ironframe' for enhancing security against clickjacking. His insights underscore the need for a balance between user experience and security measures in web architectures.

1. I WANT THESE * BUGS
OFF MY * INTERNET
Dan Kaminsky
Chief Scientist
White Ops

2. So, Defcon, Again
• Been coming here for ~15 years
• No, really, I do talk about a lot more things than just DNS
• Heh, thanks for coming despite a particular lack of details 
• Why am I here?

3. I Like Hacking
• The primary thing hackers break are assumptions
• We’re the people who manipulate how systems really work, not
(merely) how they’re supposed to work
• That doesn’t always mean we know how they work, though that helps
• Not knowing how things work tends to cause them to fail…we just redefined
failure as a success condition…
• There is an advantage to actually knowing how things work
• We can fix things nobody else cares to
• If we care to

4. I Like The Web
• HTML was the first complex document format that wasn’t accidentally
fuzzable
• Whatever you put into it, it was going to render something
• No user ever wants a crash
• Not like if you’re slightly off hammering a nail, it will turn into a fish…
• Great learning curve!
• “Surfing the web”
• Ever consider how weird a phrase that is? You don’t surf spider webs!
• Just being able to go places and do things and not sit around waiting for installations
was so completely compelling – and still is
• Always up to date
• Barely cached, generally updated, possible because the format is relatively small
• Download one program (the browser), visit all the sites

5. That Is Not How Mobile Works
• Not to say Mobile is “bad”
• It’s optimized for using a much smaller set of services
• Must accept installation
• Must wait for download
• Must have on “Home Screen”
• Mobile has a lot of friction
• Apps get stale – old binaries, too big to redownload on demand
• Apps either require centralized permission (Apple) or probably should
require centralized permission (Android) :/
• Binary powers are mighty

6. An Amazing Security Model (Really)
• The Browser represents a “Neutral Broker” that implements 2 ideas
• 1) Same Origin Policy
• One user, one program, accessing both CNN and Gmail – CNN can’t read the user’s Gmail
• Concept is that there are mutually distrusting entities that may be presenting
information to the user – in different tabs, or even in the same page – and they don’t get
to “intersect” except within the user’s experience
• “Iframes” – you could embed a piece of Paypal, in your page, and Paypal couldn’t read
your page and you couldn’t click “send all the money” inside the Paypal Frame
• There have been other issues…
• 2) It’s Safe To Surf Anywhere
• Corollary of the Same Origin Policy
• The web requires users to download and execute unaudited code and execute it blindly
• Users thus require the web to make sure anything executed is heavily constrained
• Been forced to drop arbitrary plugins (ActiveX, NPAPI), Java, possibly someday Flash to meet
this constraint

7. The “Malvertising” Trap
• “Everybody should run ad blockers, because advertisements might
contain dangerous content”
• This is true. Not just exclusively.
• Question: Do you think ad networks are more secure than your average
clickbait/listicle site?
• Who makes more money?
• Who can have a larger security budget?
• If it’s actually not safe to surf the web because of malvertising, really what we
need is a whitelist of a few hopefully secured sites, with everywhere else
deemed too dangerous
• Is that still the web? No.

8. THAT BEING SAID
• “Everybody should run ad blockers, because advertisements are
annoying and make the web slow”
• Totally different story.
• Disclosure: I started a company (White Ops) trying to clean up the ad space
• Why are some ads causing performance problems?

9. The Same Origin Policy can be a problem
• This is a surprising finding, even to me
• Goal: Protect the user’s interests
• We want mutually distrusting entities to be unable to harm one another
• But what if a “child” entity is abusing the user, but SOP is preventing the
parent from noticing?
• Concept: This shouldn’t be possible, since the parent can control how much of the
child is visible (even if it can’t see what the child is doing in that space)
• Reality: The child could be doing a ton of things that are making the entire web
browser slow (or consuming piles of bandwidth)
• You can’t manage what you can’t measure
• Same Origin Policy means the parent SHOULD NOT be able to measure cross domain
iframes

10. Yeah, we’re hackers, this is a web page CPU
monitor, and that’s an IETF SHOULD NOT

11. By comparison…

12. How it works
• nice.js (simplified)
• setInterval(
function(){
var now = Date.now();
console.log(now-window.prev-250);
window.prev=now;
}, 250
)
• “Try to do something every 250ms. Then tell me how much we miss that mark.”
• [0,1,1,0] == Idle
• [20,30,20,20] == Somewhat busy
[1000,2000,1000,5000] == Oh dear
• (Can also implement with setTimeout, requestAnimationFrame, and setImmediate,
yielding slightly different results)

13. How useful is nice.js?
• A slow web is a dead web
• I like the web
• Nice.js lets scripts easily delay their execution until the browser is idle
• Have a timing attack against subframes that yields some cross domain
visibility
• Easily shows that something somewhere on the page is causing poor user
experience (this benefits the user)
• Has a small chance of showing that something somewhere on the page is
doing a particular thing on a child page, that the user would not want the
parent page to know (this could harm the user)

14. Could nice.js be “fixed”?
• Difficult to fix
• The stuff that’s being blocked here is fundamentally single threaded
• Chrome is eventually making iframes run in their own processes, but
something competing on the same CPU ultimately causes visible delays (lots
of timing attacks against shared-system crypto)
• Not necessarily desirable to fix
• Slow processes, even in an iframe, still burn battery life, harm user experience
• Possible to let parents profile children (at least know “this frame is
making the browser slow” at low frequency) yielding both more
actionable data (this subresource needs to be cut) and safer data
(“this frame caused this much jank” rather than 60hz updates)

15. Let’s step back for a second
• What did I just calculate?
• “Given this hack, what should browser developers do?”
• Turns out, that’s a complicated question to answer, even if you constrain it
to, “What’s best for the user?”
• Measuring harms against one another (a theoretical risk of cross-domain inspection
vs. an active crisis of embedded content overwhelming the user experience)
• How difficult is the fix? (Would we have to completely redesign the entire browser?)
• How useful would a proper implementation be? (Maybe we double down on the
functionality, and mitigate theoretical harms while we’re at it)
• “Making things better” requires judgment calls, that even extend outside
of security.

16. Another thing SOP-Induced blindness has
allowed…
• 1) Buy ad space on a popular site
• 2) ???
• 3) Profit
• Anyone here know what step two is?

17. Ad Stuffing Gnomes
• 1) Buy ad space on a popular site
• 2) Put ten other ads inside/underneath your ad
• Top Frame: Some site you’ve heard of
• Mid Frame: Stuffer
• Subframe 1-10: Stuff Stuff Stuff Stuff…
• 3) Profit
• No limit to how much they can stuff, no limit to how much they can
degrade the user experience
• “It’s invisible!”

18. So, Viewability
• Same Origin Policy means nobody can tell stuffing is happening
• Ads can’t tell they’re invisible
• Publisher can’t tell there’s invisible ads
• Middleman makes out like a bandit
• We can sort of see this happening with nice.js (CPU impact)
• There’s a body of hacks that try to see if the stuffed ads are actually
visible via the browser
• They…sometimes work, and they’re sometimes efficient
• Should this be a hack at all?

19. “Viewability” is just Clickjacking w/o the Click
• Attacks against viewability occur when
just the loading of content is enough
to cause harm
• But content is not just displayed to
users – it’s also presented for
interaction
• Dialog on the left controls Camera and
Microphone in Flash (on IE/FF)
• Click==Spy
• If the content is not fully viewable, the
interaction cannot be trusted
• We call these Clickjacking attacks.
We defend against them by making
the web suck.

20. Off-site navigation is a terrible design
(But Paypal can only guarantee no malice on eBay)
“In Context” on eBay – just hit Pay
Have to navigate offsite, hope the user
comes back

21. Popups are terrible design.
(But Twitter is afraid of clickjacked retweets)

22. Some bugs need to be judged by the crap
they create in their wake
• We tend to “fix” clickjacking by making it impossible to embed content
• X-Frame-Options disables/controls iframes
• But content embedding is actually one of the unique values of the web
• Single Sign On could really use this working too
• People are using other approaches to compensate, and they’re awful
• Nav to a safe domain
• Popups
• Script Includes – “Good” JS and “Bad” JS fighting without a security boundary
between them?!?! We abandoned SOP because of SOP?
• None of these options are available to Adobe, who really needs “in-
context” security (for IE/FF when not in Chrome Sandbox)
• But they get native code execution…

23. Adobe destroyed Clickjacking
(For Camera and Microphone)
(+ means can click, - means cannot click)

24. Works through Iframes just fine
(Same filters, but on outer iframe vs plain inside)

25. Moving objects (that are, say, following the
mouse) must stay in place for a few seconds in
view of user for input to be accepted

26. they make photoshop they can tell by the pixels
(Adobe is semi-fuzzily comparing expected vs.
actual rendered output to the user)

27. So…
• I guess Flash can do what HTML5 can’t…again?
• Uh, no
• You never want to read pixels back from the GPU
• GPU == 10 lane freeway with 9 lanes going out and 1 lane coming in
• You also never want to parse video
• In this one context, when the security requirement is absolutely
overwhelming, and the use is precisely fixed to an inflexible and temporary
dialog, pixel scraping’s perf impact is trumped

28. We Too Can Fix Things
• It’s not like we can’t patch browsers like Adobe can patch Flash
• HTML5 has been working on fixing viewability/clickjacking, via W3C’s
UI Security Group
• Good spec
• Recommends pixel scraping as a generic implementation strategy
• That can’t happen. Can something happen?

29. I’m becoming an W3C invited expert,
because…
I WANT THESE * CLICKJACKING BUGS
OFF MY * WEB
Ask me how

30. Layers of Abstraction
• Browsers can’t efficiently know what pixels are being presented to the
user (because the GPU is figuring all that out)
• It’s not like the browser isn’t controlling what’s being sent to the GPU
• Web pages are composed of layers – it’s like we’re looking down on a
stack of transparencies, with objects on top obscuring and altering
whatever happens to be beneath

31. What you see

32. What your computer sees (Firefox 3D view)

33. Maybe your computer could see something
else
• Pixel Scraping is an attempt at auditing
• So many ways to draw pixels in HTML5 – HTML/JS/CSS/WebGL/SVG/Canvas
• Let’s just see if the final pixels resemble the correct pixels
• IronFrame is an attempt at correctness by design
• We just take the layer on the bottom, and we put it on the top
• It’s like Jenga
• Hopefully without the falling over
• We make sure we don’t put too much on the top – iframes are like keyholes, we just
respect those sizes and positions
• The only thing that could be rendered, is the thing that should be rendered
• First, just let me show you IronFrame working (under Chrome/Blink)….

34. Then let me explain why you never
use the word “just” when it comes to
browsers, or anything that might be
hard.
Browsers
amirite

35. Here’s a tweet (inside a bunch of hidden iframes
being nasty). If you click it, it fires a popup.

36. That tweet, with a stock browser, in various
possibly unfriendly environments

37. Same Tweet, Under IronFrame (screen not
recently scrolled). Red=Not 100% Visible

38. Now, we scroll the top window.
Yellow==“My size or position changed recently”
Red or Yellow == Interaction is blocked

39. The iframe follows the mouse? No problem!
Yellow (and input blocking) in motion
Clear (and interactive) once settled in

40. Handling Changing States:
Events, not Fixed Policies
• That’s the other half of IronFrame
• Instead of applying fixed policy, we send events to the promoted
frame
• Where the viewport is
• Where your content is on that viewport
• How much of your content is on that viewport
• When this was all true, whenever these values change
• With this input, JS can decide policy (allow Paypal/Retweet/Like/Impression)

41. We have a God layer
What if there are two Gods?
• What if two layers both try to promote into the same space?
• No problem, one of them wins, don’t care which. As long as the loser
(partial or complete) finds out it lost
• “RequestVisibility” is my present API name. It’s not “DemandVisibility”
• Might also allow frames to block RequestVisibility, at the cost that children
will know they’re being blocked
• This does alter designs, I’ll be talking about that later

42. Just to show off a bit…
Opacity tricks? No problem.

43. Drop shadows from a faraway Element?
CSS filter blur? Done and done.

44. Complex clip paths? Nope
Zoom? Catch that too

45. RotateY(90deg?) Sure, nope.

46. Scale3D literally flipping it and reversing it and
NOPE NOPE NOPE

47. Visibility Hidden?
Visibility Restored.

48. Securitay by design is a thing
Not saying perfect. But all those
were fixed without special cases.
No popups necessary

49. Let’s talk gory details. Starting with what
does it actually mean to “move a layer”.
• We’re going to focus on Blink here, but as with nice.js, this stuff is
basically very similar across the browsers
• Former head of IE: “This is the anti-hack – you’re working with the graphical
subsystem to build a security policy”
• Yup

50. What do we have to do
• Satisfy three requirements
• 1) Promote content to the top layer
• 2) Shrink that content so it’s no bigger than it should be
• 3) Report back how much you promoted

51. What do we have to work with…
• Node
• Element
• Document
• DOMWindow
• LocalDOMWindow
• Page
• ChromeClient
• FrameTree
• FrameView
• LayoutView
• LayoutFrame
• LayoutTreeBuilder
• LayoutObject
• LayoutPart
• LayoutBlock
• LayoutBox
• LayoutBoxModelObject
• DeprecatedPaintLayer
• DeprecatedPaintLayerPainter
• DeprecatedPaintLayerCompositor
• GraphicsLayer
• GraphicsLayerTreeBuilder
• WebLayer
• WebLayerClient

52. OK, we can simplify
• Three layers contain almost all of what we need
• Document
• LayoutTree of LayoutObjects
• LayerTree of DeprecatedPaintLayers or GraphicsLayers
• Don’t see this as a final feature implementation
• I’m working towards viability, not perfection

53. Document: Just the DOM
• It’s the Document Object Model,
what did you expect?
• You can of course access it from
C++
• Anything you change here, will
be visible to an attacker
• Moving Elements here is not
recommended, especially not
cross domain!
• But everything “convenient” for
the JS dev, is available to you in
C++ (and then some)

54. LayoutObject: A fast OM that still knows what
sort of elements it contains
internals.elementLayoutTreeAsText(
imgdoc.documentElement)
• layer at (0,0) size 784x762
• LayoutBlockFlow {HTML} at
(0,0) size 784x762
• LayoutBlockFlow {BODY} at
(8,8) size 768x746
• LayoutImage {IMG} at (0,0)
size 0x0
internals.elementLayoutTreeAsText(
iframedoc.documentElement)
• layer at (0,0) size 784x762
• LayoutBlockFlow {HTML} at (0,0) size 784x762
• LayoutBlockFlow {BODY} at (8,8) size 768x746
• layer at (8,8) size 304x154
• LayoutIFrame {IFRAME} at (0,0) size
304x154 [border: (2px inset
#EEEEEE)]
• layer at (0,0) size 300x150
• LayoutView at (0,0) size 300x150
• layer at (0,0) size 300x150
• LayoutBlockFlow {HTML} at (0,0) size 300x150
• LayoutBlockFlow {BODY} at (8,8) size 284x134

55. Anyone here pixel scrape for web regression
tests? Because LayoutTree dumping is better.

56. DeprecatedPaintLayer / GraphicsLayer:
An OM that only knows surfaces to
paint/clip/scroll
internals.layerTreeAsText(document)
• {
• "bounds": [784, 762],
• "children": [
• {
• "bounds": [784, 762],
• "contentsOpaque": true,
• "drawsContent": true
• }
• ]
• }
Some notes
• Many LayoutObjects can
share the same
GraphicsLayer
• An object in the DOM can be
configured to ultimately
require a dedicated
GraphicsLayer
• document.documentElement.s
tyle.transform =
“translatez(0)”
• Well known optimization that
sometimes does good things

57. Layer Tree After style.transform =
“translatez(0)”
Looks like a lot…
• Most of these surfaces don’t
have drawsContent set
• They’re just surface modifiers,
handling scrolling and clipping
• There are more layers on the
way to the GPU, that (I believe)
turn these surfaces into draw
commands instead of bitmaps

58. What I’ve found
• Everything in IronFrame could be implemented at Document,
LayoutObject, or GraphicsLayer
• For various degrees of security, difficulty, and stability
• It’s sort of a fight between absorbing the browser’s existing knowledge of
corner cases and suffering the browser’s implicit assumptions
• Actually migrating content to a top layer works really well at
GraphicsLayer
• Figuring out what to migrate should use GraphicsLayer, but it’s tricky
• For now, Document Elements have a method boundsInViewportSpace(), that
works quite well

59. IronFrame in English: Find Your
DocumentElement
• 1) Start with the documentElement inside an iframe’s Document
object
• Why inside an iframe? Because otherwise you can have all the clever
graphical security you want and an attacker can just turn it off with a bit of
clever JavaScript
• Same Origin Policy does have its uses!
• Why the documentElement? Because there’s lots and lots of weird stuff in
HTML and I want to limit the number of things that can go wrong
• If the documentElement doesn’t already have its own layer, add translatez(0)
to it (or find the magic bit to flip)

60. IronFrame in English: Raise your
GraphicsLayer
• 2) Find the GraphicsLayers for both the content to be promoted, and
the root graphics layer
• GraphicsLayer *iframeGraphicsLayer = document->documentElement()-
>layoutObject()->enclosingLayer()->graphicsLayerBacking();
• GraphicsLayer* rootGraphicsLayer = this->domWindow()->top()-
>document()->body()->layoutObject()->enclosingLayer()->root()-
>graphicsLayerBacking();
• Iframes create false roots – need to get the root relative specifically to the top
document’s enclosingLayer!
• 3) Make the iframeGraphicsLayer the last child of the
rootGraphicsLayer (meaning it trumps)
• rootGraphicsLayer->addChild(iframeGraphicsLayer)

61. IronFrame in English: Your GraphicsLayer is
too big! Measure how bad it is.
• 4) Figure out how big that documentElement is, and where it might be on
the top viewport
• IntRect bounds = document->documentElement()->boundsInViewportSpace()
• Say that’s a 1000x1000 rectangle at a position of (400,400)
• 5) Figure out how much your parent iframe(s) clip you
• We have to implement clipping, because we’re escaping natural clipping so we can
escape all the other stuff things on top of us can do
• Just because your content is 1000x1000 doesn’t mean that survives all the way up
• IntRect frameBounds = document->domWindow()->frameElement()-
>boundsInViewportSpace() // could be a tiny 200x200 keyhole at 100x100
• bounds.intersect(framebounds)
• Repeat until there aren’t any more iframes that could clip you (keep running
document->domWindow->parent() and checking for frameElement()

62. IronFrame in English: Don’t forget the
Viewport!
• 6) Figure how much the viewport clips you
• Just because we’re somewhere on the top frame, doesn’t mean we’re scrolled
into view. Maybe we’re 4000 pixels down and the page isn’t looking at us!
• LayoutRect viewport = this->page()->deprecatedLocalMainFrame()->view()-
>layoutView()->viewRect(); // Probably a better way to do this
• Convert the LayoutRect to an IntRect and intersect bounds with this

63. IronFrame in English: Shrink your
GraphicsLayer
• 7) Apply Bounds
• boundsInViewportSpace() takes all scrolling into account except scrolling on the
topWindow, so add that back
iframeGraphicsLayer->setPosition(FloatPoint(bounds.x()+topWindow->scrollX(),
bounds.y()+topWindow->scrollY()));
iframeGraphicsLayer->setSize(FloatSize(bounds.size().width(),
bounds.size().height()));
iframeGraphicsLayer->setMasksToBounds(true);
• 8) Correct for intermediate scrolling
• It’s not just the top frame that can scroll – so can subframes. Handle that by
measuring how much the iframes changed x and y, and applying that to the layer.
• IntSize offset = IntSize(bounds.x()-origBounds.x(),bounds.y()-origBounds.y());
• iframeGraphicsLayer->setOffsetFromLayoutObject(offset,
GraphicsLayer::ShouldSetNeedsDisplay::SetNeedsDisplay);

64. IronFrame in English: Report back!
• 9) Report back the Viewport and Visible Portion
• I happen to send this back over an onError, to be picked up as text in e-
>message
• This also needs scrollX() and scrollY() added to the bounds

65. It’s so easy!
That’s why you never say “just”.
I said just
You can’t spell just without js

66. Some Issues
• Need to actually get this into the compositing pipeline
• Presently a JS call (requestVisibility) rather than an attribute or CSS property
• Other things can cause a layout event to occur
• Those things reset our manipulated tree
• There’s a polling wrapper right now, making Tim Berners-Lee cry
• Need to actually be stable in the compositing pipeline
• Blink wants certain things to happen at certain times
• Makes it interesting to schedule those things to occur
• “Do this soon”
• Enums that literally refer to solving chicken and egg problems
• Right now, we just abort if either the source iframe or the destination top frame isn’t
completely outside of compositing (lifecycle state 14)
• Some mouse issues (hit testing gets weird)

67. Biggest Issue: Do we really want to be forcing
things to be drawn on top?
• Fail Closed
• Whatever we report, that’s actually what is being presented to the user
• Alternative is Fail Open
• We try to read the tea leaves across the various layers, and report our best
guess
• As you can imagine I’m not a fan of that approach
• The browser guys think they can do this (Minimum Unmodified Rectangle, as
Mozilla called it). I just want a security boundary that requires fixing.
• My original thinking was that position and size was good enough, and
there’s no legitimate reason for other people to be drawing on top of
your frame

68. Well, drop shadows are a thing
(thanks, Jesse Ruderman)

69. Could I just promote the part of the layer I
think that’s on top?
• Even if I deeply analyze
GraphicsLayer to separate the area
with the Drop Shadow overhang vs
the area that’s clean, I can’t
promote just the clean area
• Layers can’t be “split” AFAIK
• Would probably use HitTest on layers
• Blink does have ReplicaLayers –
might be able to “clone” just the
part I want
• Painting twice is OK, it’s using that 10
lane freeway on outbound instead of
inbound
• Probably need compositor support

70. One more thing
• Thus far, somebody can still draw a fake Twitter
• They’re just pixels
• Who cares, their fake doesn’t have your credentials
• But what if we wanted to use IronFrame for Single Sign On
• This is the dialog that gets your credentials…

71. A New Freedom
• Iframes have always had input exclusivity
• Keyboard and mouse to a frame, only goes to that frame
• Iframes are now getting output exclusivity
• However much they’re visible, they know they’re visible
• Well, if we have input, and we have output…

72. We can update the address bar when the user is
interacting with a secured frame.
(That’s not photoshopped.)

73. So
• We can kill clickjacking without breaking what makes the web special
• We can do crazy things as hackers – it’s not just about making things
fail. We can defend the vision of the open web.
• We can realize when we try these hard things, it’s not going to work
perfectly the first or second or tenth time, and we’re going to be OK
with that
• We can tell the ad stuffers that are making the web slow, to go stuff
themselves

74. Couple final tips (if there’s time)
• 1) Even (especially) if you’re a White Hat, you don’t need to play all
secretive when fixing longstanding public bugs
• Just join the forums
• Everybody knows clickjacking exists
• Parisa Tabriz told me to do this and it would have saved me so much time
• 2) Use decent tools
• You want to be able to quickly jump around a codebase – I use Source Insight which
is not free, but you know, neither is IDA Pro
• Source Insight designed to search codebases it doesn’t know how to build
• Getting Chrome to compile is hard enough, getting it to compile in Eclipse is…
• Apparently the only good way to debug Chrome is WinDBG, “the only reasonable
multithreaded debugger on the planet”

75. Look for the debugging tools
• You’re not the only one who’s tried to change something here
• Internals.cpp is as close as you’ll find to “stuff other people wrote to
make this work”
• Compile content_shell and use --enable-internals-for-testing
• Hundreds of useful methods to both execute (from JS) and copy for your own
uses
• nodesFromRect, boundsInViewportSpace, layerTreeAsText, elementLayoutTreeAsText,
viewportAsText, absoluteCaratBounds, treeScopeRootNode…
• Those aren’t methods for people building web pages, those are methods for
people fixing web browsers
• 