
ADsafe – Making JavaScript Safe for Advertising - nickpsecurity
http://www.adsafe.org/
======
Animats
How about browsers rejecting all off-site Javascript loads that don't have
subresource integrity hashes, unless they're in iframes? This would force ad
networks into using iframes. You could still load static assets such as JQuery
and fonts from central sites. Anything you needed to load would have to be
static. That makes it part of your page, just stored elsewhere. Assets would
need versioned URLs. Think of it as version locking for external code.

The requirement for subresource integrity would have to be recursive; if
something has an integrity hash, anything it loads must also have an integrity
hash. This prevents escaping via indirection.

This would break a lot of sites, of course. (HN would be fine; I just looked
at page source.) But it probably wouldn't be much worse than running with
Ghostery set to reject all known third party crap. It would definitely break a
lot of hostile code.

Not sure if you could enforce this from a browser add-on; those usually don't
get control early enough.

~~~
fooey
Forcing ads into iframes would would make responsive websites enough harder
that most people wouldn't bother. You'd end up moving all the ads to those
obnoxious full screen and intersitionals

~~~
Animats
The parent page sets the iframe size; the iframe has to make itself fit. See
[1] for a way to do this. If it's too small, the ad should refuse to load and
the site doesn't get paid.

Amusingly, Google has a canned answer for "iframe size": 200 pixels.

[1] [http://stackoverflow.com/questions/819416/adjust-width-
heigh...](http://stackoverflow.com/questions/819416/adjust-width-height-of-
iframe-to-fit-with-content-in-it)

------
dlss
How does this differ from
[https://developers.google.com/caja/](https://developers.google.com/caja/) ?

~~~
nickpsecurity
That was going to be my next submission. ;)

~~~
oso2k
This was Crockford's attempt at making JS secure in browsers before his seif
project. In theory, this would work well but requires developers to use the
adsafe plugin of jslint to ensure their web apps are safe.

Caja is Mark Miller's (supported by Google) attempt at making JS secure in
browsers. This was implemented in the static analyzers used by Google in their
Google Apps Script environment.

------
pdimitar
I applaud the honest and fair diplomacy effort by giving life to AdSafe. You
don't want to kill the advertisements, you want to coexist with them
peacefully. You deserve a lot of respect for this alone -- I know for a fact
that I wouldn't be that better man and I'd opt for much more drastic approach.

I am afraid the ad networks never wanted to play fair in the first place
however.

JS browser engines themselves have to start providing strongly jailed
sandboxes or the problem won't ever be solved (which is the goal, I'd argue;
almost nobody has an economical incentive to fix the current state of
affairs).

Sadly, having in mind how much Google loves its tracking, I don't think
they'll ever help wich such an effort in Chrome. Mobile Chrome for example
never got support for content blockers, unlike other mobile browsers like
Apple's Safari, Samsung's Internet (Android) and several, less popular,
others.

------
nickpsecurity
A technique from CompSci for reducing risk of malicious JavaScript. Worth
posting given many here claim they block ads due to malware risk. The
technique needs further review for its security and usability.

~~~
pdkl95
> from CompSci

Maybe I'm missing something, but I don't see much that I would consider CS.
This is an attempt at an engineering-style workaround.

> malware

They explicitly include support for spyware with the mouse{over,out} (etc)
events.

> "ADsafe makes it possible to quickly and reliably determine that script is
> safe"

That's incredibly hard. It's easy to hide arbitrary code even if all you have
is a lambda expression[1] ("function () {}" in JavaScript). There are so many
sharp corners and inconsistent gotchas in JavaScript - multiplied by the
variations between browsers - that identifying a "safe" subset of the language
is extremely difficult (or maybe undecidable).

Douglas Crockford has been warned[2] almost a decade ago about the insecurity
of mixing foreign JavaScript. The language simply wasn't designed with a
security model sufficient for running untrusted code.

[1] [https://codon.com/programming-with-
nothing](https://codon.com/programming-with-nothing)

[2]
[https://www.youtube.com/watch?v=qfBL2sc2zUU](https://www.youtube.com/watch?v=qfBL2sc2zUU)

~~~
nickpsecurity
"Maybe I'm missing something, but I don't see much that I would consider CS"

It came from CompSci people researching sandboxing of JavaScript. The papers
on the left show that. They later turned it into a more engineered solution
and convenient web site. Uncommon with CompSci projects. I give them extra
credit for that whether the method pans out or not.

"They explicitly include support for spyware with the mouse{over,out} (etc)
events."

Is that limited to the site it executes in or would it have visibility to all
sites? And anything you see that would lead to code injection outside
hardware-level attacks?

~~~
pdkl95
> It came from CompSci people researching sandboxing of JavaScript.

Ahh! That makes more sense.

> site it executes in

They seem to be allowing capture of UI events on any element that is
selectable through their (limited) query interface. This is probably to allow
interactive designs or ad-network "auction" tracking, but it's still spyware.

------
baybal2
I doubt that big ad networks will touch this. Bot detection relies on
intrusive/borderline malware code.

It was not unheard of ad companies probing, say, 0-day buffer overflows in
browsers just to uncover botters.

~~~
alkonaut
The point (I hope) is to get the big ad networks to change practices or drive
them out of business when e.g browsers have blockers on by default killing all
ads from networks that serve ads that aren't using safe subsets.

------
the8472
why not just put the ads in a srcdoc+sandbox iframe. that way it can be loaded
inline but runs on a null origin, preventing access to the page itself.

~~~
shakna
What about the risks if you serve something that breaks out of the sandbox?

~~~
the8472
then the origin security model of the browser is broken and you have much
bigger problems than just some ads.

~~~
Twirrim
Well, yeah, but ads are the most likely attack vector.

~~~
the8472
I would argue that relying on SOP isolation is more reliable than attempting
to patch over the ads running in the same page context in the first place.

The threat model changes quite a bit if we assume the attacker has a SOP
exploit.

------
mwexler
How is this different from
[https://github.com/douglascrockford/ADsafe](https://github.com/douglascrockford/ADsafe)?
And isn't this all from 2011 or so? I recall this concept popping up then as
well. I haven't seen much uptake from the ad industry which is focused on more
tracking and access, not less.

------
leeoniya
how much of this can already be mitigated by using `iframe[sandbox]`?

~~~
JoshTriplett
Just about all of it, especially with its default behavior of blocking script
execution. Ads have no business running JavaScript, especially in the context
of the site running the ads.

------
Kenji
Call me ignorant but why exactly does a plain, honest ad need JavaScript? Why
isn't a plain picture that links to the advertiser's site (maybe through a
counter redirect so you can see how many people followed the link) enough?

~~~
TeMPOraL
It doesn't.

The problem is stated backwards though. Ads don't _need_ JavaScript. But ad
vendors will use whatever tools they _can_ use, so if you let them use
JavaScript, it will get used - and not just for malicious, track-the-shit-out-
of-users purposes, but also as an enabler of general coding laziness (much
like a lot of things are moved to JS today, because hey, free frameworks!).

------
eridal
The minimum set of `+!()[]` chars are proven to be TC [0]

So good luck trying to define a non-TC js-subset that allows to use these
chars.

[0] [http://jsfuck.com/](http://jsfuck.com/)

~~~
DougBTX
The mitigation for this is:

 _[ ] subscript operator except when the subscript is a numeric literal or
string literal or an expression that must produce a number value. So
expressions like a[i] are disallowed because we cannot statically determine
that i is not one of the dangerous property names. But a[+i] is allowed,
because +i will always produce a number._

------
Osiris
I wonder if it would be possible to make a browser extension that rather than
block all ads, would simply run all third-party scripts through something like
this to disallow malicious behavior.

~~~
tscs37
Forget it. That would include solving the halting problem by proxy.

You can't know if a script or program is going to be malicious without
effectively executing it. It's almost impossible.

Just look at Anti-Virus, they've been trying forever and the best we have is
research papers on immune-system-based AVs or AI-solutions.

~~~
alkonaut
Wait, I thought this was intentionally made a small enough subset that it
should be not only possible but fast and simple to decide whether a chunk of
code conforms or not?

Is JavaScript so hard to parse and analyze that this is impossible?

~~~
tscs37
It's a generic problem in computing. Reducing the language set only changes
the difficulty and does not eliminate it simply by the Nature of Turing
machines.

~~~
roywiggins
Running a Turing-complete language in a jail is entirely possible. If you
don't give it access to, say, webcam APIs the you can be sure it won't turn
the webcam on unless there's a bug in the jail.

Of course, proving the jail is secure is awfully difficult but you can at
least analyze it at your leisure, and you only have to do it once. I don't
know if this is possible as a practical matter but the halting problem doesn't
exclude the possibility.

~~~
tscs37
I'm not aware of any perfect jail. Even then studies have shown that a simple
memory error can lead to breakout.

~~~
alkonaut
We already hope that the Turing Complete normal js doesn't access our files -
so hopefully what this aims to do is simpler

------
amluto
Do any ad networks permit running their scripts in ADsafe?

~~~
Animats
Google, in their terms, prohibits sites from running their ad code in iframes.
Probably because that makes ad-blocking so easy.

~~~
eriknstr
I think it's more likely that the no iframes rule is there to prevent click-
fraud.

See for example
[https://en.wikipedia.org/wiki/Browser_hijacking](https://en.wikipedia.org/wiki/Browser_hijacking)
for more on a kind of malware that injects ads into browsers.

