ADsafe – Making JavaScript Safe for Advertising | Hacker News Reader

ADsafe – Making JavaScript Safe for Advertising

adsafe.org

33 pointsnickpsecurity58 comments

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.

One thing I've always found mind-boggling: "HTTPS"

When I see HTTPS on a bank's backend/login page, i have the full expectation that what i am entering into the page cannot be seen, screen-scraped or intercepted by any third party. i want full encryption ONLY between me and the domain i see in the address bar.

The truth of the matter is, 100 third party scripts (cdns, analytics) can be [and usually are] injected from completely unrelated HTTPS domains, and the average user has absolutely no idea because there is never an indication of this from browser UIs. It is such a blatant violation of trust, and it's the norm!

I have no explanation except that advertisers insist on having direct access to the user-agent for tracking/click-through accountability.

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

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...

How does this differ from https://developers.google.com/caja/ ?

That was going to be my next submission. ;)

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.

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.

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.

> 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

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

Then just make ADSense2 be a DSL that is translated to js on the client, but which is itself not js?

The important thing is to get the major browsers on board so that ad nets have to use it in order not to be blocked by default.

(Assuming that browsers have the browser users interests in mind, and not advertisers, this is sketchy at best in the case of Goog)

"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?

> 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.

The claim of blocking ads because of malware is likely just a case of people picking the low-hanging fruit to get on with their busy day. If a user actually went to the trouble of searching out and installing an ad-blocker, you can bet there are a plethora of higher-level pains that add-on relieves for them. Properly addressing the malware risk might force them to articulate those higher level reasons (ads eat batteries, delay streaming content, bark sounds, block content, intrude on content, aren't content) but is near 0% likely to convince them to uninstall the blocker.

If ads weren't the primary source of malware I'd at least be willing/able to turn the ad blocker off on sites I like and want to support that have non-intrusive ads.

Ok. So you keep the blocker on, but you allow ads on the subset of sites that fit the following criteria:

1. You like and trust the site 2. You want to support the site 3. You trust that the ads displayed on the site are non-intrusive (and if they cease to be that you start blocking ads again)

Does anyone know if such a model would generate enough revenue for the web as it exists today to stay in business? Because even if ads become less risky and less intrusive, there's no going back to allowing arbitrary ads from arbitrary sites. Your model seems about as promiscious as a responsible user could be going forward.

Is this sustainable and comprehensive?

Parts like disallowing '_' at the start or end of a method because some browsers have dangerous methods don't fill me with confidence that this is a fool proof solution.

It seems like a compiler or iframe would be not only more comprehensive but also wouldn't butcher the language in ways that would make most code need to be adapted.

>full proof

*fool proof

Thanks! I fixed it.

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.

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.

This reminds me of the reasons I heard many years ago why popups would never go away and later why Flash would never die.

Even a short time ago I saw something on here about a bank complaining Perfect Forward Secrecy would break their security.

Too bad. The world won't end, life goes on and they'll find a way to manage without. The ad networks will play ball if not doing so means they can't play at all.

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.

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

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

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

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.

How is this different from 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.

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

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.

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?

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!).

I self-host my advertising and do this so it is possible, and my advertisers seem to be happy enough to keep advertising year after year.

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/

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.

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.

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.

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?

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.

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.

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

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

Just because a language is turing complete doesnt't mean it can do anything. It might still have a limited api or run in a sandbox without access to the data we wish to protect.

JS is already turing complete but we are pretty sure websites don't upload our local files to strangers) short of using vulnerabilities). I don't understand how it would be hard to invent a subset of JS small enough to be possible to validate.

Because even if the language was perfectly validated and the jail in which it runs is perfectly sound, you can still execute malicious code by breaking out of the jail via memory errors.

Yes. But we assume (and hope) that sandboxes and limited API surfaces actually work. That's how browser js or the AppStore works. If Apple decided that apps shouldn't see gps data tomorrow, they could just remove it from the data available to apps, and that would in fact work. The same should work for a subset of js if one is careful.

>that sandboxes and limited API surfaces actually work

While this is not a bad start, assuming they work is a bad option from a security standpoint.

You should be pessimistic and always assume the sandbox will be broken and the API abused. Then you plan for that.

Assuming nobody will ever hack your product because it's perfect is harmful for any security product. Period.

Sure. But we are talking about a system that already is in a sandbox, and that already has a limited API surface.

If that doesn't work then we are all screwed anyway. I don't see it as a reason for not pursuing the idea of further shrinking the sandbox. A smaller language and smaller sandbox should theoretically be easier to validate than large langage running in a large sandbox.

The halting problem only applies if you want to be always right. If it is ok to sometimes reject scripts that are not malicious, the problem might still be hard, but it is not impossible.

Heuristic is nice but I'm not aware of an AV that has no false-negatives, no matter how good the Heuristic is.

If you ever think about "could we just block bad stuff?" then look at AVs and see if they can do it.

AVs have probably the highest amount of research to ensure they catch as much as possible but it still does not work.

Moreover, "malicious" as commonly understood turns this into an AI-complete problem - whether or not a piece of code is "malicious" depends on things like intent and perspective of the person at the receiving end of code execution.

Exactly.

There are some people with more extreme opinons that label every ad as malicious while others (like me) will not label everything ad-like as malicious by default.

Philosophical Issues makes complicate.

You would be executing it within the sandbox, so even if there was malicious code, the ADsafe code wouldn't allow it to run certain parts of the code. You wouldn't have to know ahead of time it anything was bad.

That would work but only if the sandbox is perfect.

If the sandbox is leaky in either direction, the code can behave malicious again.

As some research showed, even if your sandbox is absolutely perfect, you can break out using memory corruption through cosmic rays (no kidding)

https://www.cs.princeton.edu/~appel/papers/memerr.pdf

So to almost 100% protect against malicious javascript code we would have to:

1) Create a JS subset that is verifiably safe

2) Create a Sandbox for that JS subset that is verifiably safe

3) Ensure the Sandbox cannot leak data, which is going to be hard since it's probably going to interact with the user in some way

4) Have the consumer run ECC memory to reduce the chance of Sandbox-Leakage

Microsoft's Xax is closest thing to it. Such architectures could in theory be made for solving problems like we're discussing. They're applying it to plugins, esp reusing legacy code.

https://www.usenix.org/legacy/event/osdi08/tech/full_papers/...

If we assume that ads are loaded through <script> tags then a browser addon could rewrite those to exist within sandboxed iframes.

The tricky part is only isolating the ads and not the functional parts of the website.

Do any ad networks permit running their scripts in ADsafe?

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

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 for more on a kind of malware that injects ads into browsers.

Reply on news.ycombinator.com