joev_

I seem to remember trying this (passing {scope:'/'} in the register call), and it doesn't work. Some googling seems to agree:

"Service Workers are restricted by the path of the Service Worker script unless the Service-Worker-Scope: header is set" [1]

I do wish the spec required a 'Content-type: text/service-worker', as that would effectively eliminate accidental ServiceWorkers as a threat.

[1] https://infrequently.org/2014/12/psa-service-workers-are-com...

ServiceWorkers are scoped to the basename of the path they are served from, so you could only intercept a small subset of all possible CDN URLs. In the example, this would be resources under `/hads-ak-xat1/t45.1600-2/`. But you probably can't create a ServiceWorker here anyways as you need a route that returns valid Javascript of your choosing with a Content-Type `text/javascript`. Usually when I've seen an opportunity for ServiceWorker exploits it's due to a JSONP endpoint that does not sanitize its callback parameter.

If you could create a valid ServiceWorker at this route, and load it inside some same-domain HTML page, then you could theoretically use it to intercept and rewrite responses to any resources on the domain under its path. Depending on how you rewrite the response you might be able to get the browser to cache the rewritten resource, which could then get used by other domains. Theoretically. I have never tested this :)

I mucked with this a while back. You can dump all your passwords over the websocket pretty easily (provided your 1password is unlocked):

https://gist.github.com/joevennix/438782cbe447e86f2506

It would be more interesting if an arbitrary website could do this, but they prevent that attack by checking the Origin header on the initial websocket request.

Out of curiosity, did you actually replace the Browser app, or did you just install a new one? If the stock Browser is still installed, you may consider the fact that it can probably be launched from Chrome with a specific URL intent.

> If I want to style my button, I set some properties on the button.

You cannot be serious. A 1000+ line long setup() method that creates a ton of one-off elements, sets a million properties, and saves them all as instance variables is in no way superior to using some XML to structure your elements, and then a separate, extracted layer for styling. I've done the procedural shit before, in Java, UIKit, Cocoa, you name it. There's just no way you can actually think that is better. Presentational separation is a good thing. (btw you can write your UI in the same procedural way in Javascript if you think it is superior/are a masochist).

The rest of your comment is very rambling and does not really have a point so I will hold off on replying to it. I write polished, pixel-perfect, cross-platform interfaces, and HTML/CSS is the best tool I have found for the job. Nobody will ever say it is perfect of course, but IMHO it beats the hell out of WinForms! You are right, it is a lot to learn for a 1st year developer, but you are going to get a shitty UI out of a 1st year developer, who cares?

> Yes, there is more memory available than before, but that doesn't mean we should just waste it for useless stuff.

I disagree. I think the point is that it's not useless, by its own existence. It saves dev time (which allows more - and better! - programs to be built), it allows richer features and interactions, it lowers the barrier to entry for maintenance work, and most of all prevents constant re-inventing/implementing the wheel, which is reflected to the user in a lack of many common types of bugs, annoyances, and accessibility issues.

Obligatory:

http://jsfiddle.net/jrxvw1yd/

Compiled through emscripten to build a JS interpreter in a browser... at only 1.5MB!

> Apple wants to relegate websites to second-class status on their popular computers, and exercises viewpoint censorship on what “apps” they allow in their “app store”.

I don't remember it that way all. Does anyone else? From what I remember, there was a very heavy consumer demand for the App store, meanwhile Apple was telling everyone just to make web apps. They actively developed WebKit into a cutting-edge, standards-oriented, developer-friendly browser. I don't see how you could say they wanted to "relegate websites to second-class status".

Can you list some native UI controls that you'd like to use but can't recreate in HTML? I am writing a similar framework and would like to know the use-cases for doing this.

Edit: besides Window and Menu, of course

/bin/sh depends on the system. It might be busybox or a minimal shell (this is common on embedded devices). On some systems like OSX and I think CentOS /bin/sh is just bash. You can check with `/bin/sh --version`.

My understanding is that Chrome replaced Webkit in WebView's internal implementation in 4.4, so the bug should never appear in 4.4.

I didn't test back this far; I should have, it's about 10% of android users. I tested back to 4.0 (not that 4.0-4.1.2 being vulnerable matters much, since you can get remote code execution easily through the addJavascriptInterface vulnerability). I tried out 2.1 in the emulator just now and got the same results as you, so it looks like 2.x is not affected by this.

I don't know the exact location, but it is probably somewhere in the webview tree, since it affects apps that embed webviews as well:

https://android.googlesource.com/platform/frameworks/base/+/...

I wish I had tested this sooner, but yes, Webview is vulnerable (use document.write(document.domain) instead of alert() to test). So afaict apps that embed webview/ads on < 4.4 are at risk.

Actually X-Frame-Options does not save you here. There is a BYPASS_XFO datastore option in the module that turns this into a one-click exploit. This allows the attack to work against sites with the XFO header.

> I guess as a developer you would be using Canary Chrome vs. Nightly Firefox, to get the latest

Not always. As a developer I use the latest stable Firefox, since that's what I can recommend to my users.

Wow, this just makes me love America's Test Kitchen even harder.

Edit: and it's served from a statically-generated jekyll blog that is on their github page. Did I mention they have a github account. Very random and awesome.

To be fair, there is a large disclaimer:

> I'd like to start this post with a disclaimer: I don't know much about creating accessible websites.

It's still a much, much safer model than Firefox's Add-ons.

Unfortunately x-frame-options does not always fix these kinds of problems. If you can get the user to click more than once on your page, you can open a tab in the background on the first click (google for popunder.js), and if you can predict click #2 a split second before it happens (e.g. zalewski's game PoC), you can bring the popunder to the front and reposition it right under their cursor.

(note: amazon could fix this by detecting when opener is xdomain and requiring some minimum number of mouseover events in the page before the button is clickable).

Heh. I clicked a few before I realized what was going on (looking at the status bar shows the link, which somewhat gives it away). You could prevent this by adding mouseover/out and onclick logic that removed the :href on hover and just colored itself red.

Nah, you just set target="iframe name" on the form and post into a (hidden) iframe. Then in 2 seconds you redirect to LinkedIn. In my experience, getting clicks from targets is easy. One simple way is to show a page with a single link that just says "Redirecting". After a moment most users will just click the link.

Not really. Depending on the protocol CSRFs are often an easy 1-click exploit on noscript-enabled browsers. Something like this:

    <form enctype='text/plain' method=post action='http://192.168.1.1/vulnerable'>
      <input type='hidden' name="<!--" value="--> <SOAP...>" />
      <input type='submit' value="submit" style="position:fixed;top:0;left:0;width:1200px;height:1200px;background:#000;opacity:0;" />
    </form>

Is the corresponding 1-click that works on noscript.

There is no advantage. In fact, it's more annoying when you're debugging, since you don't get the fn name in the trace.

> Gratuitously changing "function" to "->" for no reason other than removing characters seems to introduce more brand new idiosyncrasies than it's worth.

What idiosynchrasies are you referring to here? Just curious. I love the stabby lambda (for the exact reason you listed, because I am defining functions on every other line).

The point is it doesn't pass static verification. It doesn't compile. It's a rather silly thing for the author to argue imho.

Ah cool I see that now, thanks :) It would have been the kind of bug that only bothers you once in a while, that's why I pointed it out.

Lots of network devices will not have nc, wget, curl, etc. Which makes exploiting cmd injection annoying, you often have to drop a bin in chunks using hex-formatted echo.

Good writeup, not enough people go in depth like this on shellcode!

Metasploit has some decent shellcode. What you wrote here is essentially a specialized execve payload. Some of metasploit's execve payloads support passing arguments to execve, by building the args array on the fly:

https://github.com/rapid7/metasploit-framework/blob/master/m...

There are also lots of reverse shells like this, and reverse stagers too. Additionally, there are other solutions to bind shells being noisy:

See https://github.com/rapid7/metasploit-framework/pull/3017

Which causes the port to show as "closed" in a scan, and

https://github.com/rapid7/metasploit-framework/pull/2981

Which prevents other IPs from jacking your shells.

EDIT: also I think you need a null byte at the end of everything, otherwise the last arg string might not terminate correctly depending on what's in memory.