SpringOne 2GX

Use-Case Zero

Alex Russell — Fri, 24 May 2013 16:00:24 CDT

Some weeks back I lobbed an overly terse “noooooooooo!!!!!” at the W3C Web Application Security Working Group over revisions to the CSP 1.1 API; specifically a proposed reduction of the surface area to include only bits for which they could think of direct use-cases in a face-to-face meeting. At the time I didn’t have the bandwidth to fully justify my objections. Better late than never.

For those who aren’t following the minutiae of the CSP spec, it began life as a Mozilla-driven effort to enable page authors to control the runtime behavior of their documents via an HTTP header. It was brought to the W3C, polished, and shipped last year as CSP 1.0; a much better declarative spec than it started but without much in the way of API. This is a very good way for any spec to get off the ground. Having a high-level declarative form gives implementers something they can ship and prove interop with very quickly. The obvious next step is to add an API.

Late last year I started digging into CSP, both for a personal project to implement a “user CSP” extension for Chrome, and to work with the spec authors to see what state the proposed API was in and how it could be improved. The short form of my analysis of the original CSP proposal was that it was pretty good, but missed a few notes. The new proposal, however, is a reflection of the declarative machinery, not an explanation of that machine.

Not coincidentally, this is also the essential difference between thinking in terms of a welded-shut C++ implementation and a user-serviceable JavaScript design.

For example, the previously proposed API provided methods on a SecurityPolicy class like allowsConnectionTo(url) which outline an API that the browser might plausibly need to enforce a policy at runtime. The new API includes no such methods. As someone working with CSP, you suspect the browser indeed has such a method on just such an object, but the ability to use it yourself to compose new and useful behaviors is now entirely curtailed. This is the extreme version of the previous issues: an API that explains would make an attempt to show how the parser is invoked — presumably as a string argument to a constructor for SecurityPolicy. Similarly, showing how multiple policies combine to form a single effective policy would have lead away from document.securityPolicy as something that appears to be a single de-serialized SecurityPolicy and instead be written in terms of a list of SecurityPolicy instances which might have static methods that are one-liners for the .forEach(...) iteration that yeilds the aggregate answer.

So why should any WG bother with what I just described?

First, because they’ll have to eventually, and by showing only enough skin to claim to have an API in this round, the question will be raised: how does one implement new rules without waiting for the spec to evolve? The Extend The Web Forward idea that flows naturally from p(r)ollyfills has shown real power which this new design puts further from reach…but it won’t keep people from doing it. What about implementing something at runtime using other primitives like a Navigation Controller? Indeed, the spec might get easier to reason about if it considered itself a declarative layer on top of something like the Navigation Controller design for all of the aspects that interact with the network.

There are dozens of things that no over-worked spec author in a face-to-face will think to do with each of the platform primitives we create that are made either easier or harder for the amount of re-invention that’s needed to augment each layer. Consider CSS vs. HTML’s respective parsing and object models: both accept things they don’t understand, but CSS throws that data away. HTML, by contrast, keeps that data around and reflects it in attributes, meaning that it has been possible for more than a decade to write behavioral extensions to HTML that don’t require re-parsing documents, only looking at the results of parsing. CSS has resisted all such attempts at gradual runtime augmentation in part because of the practical difficulties in getting that parser-removed data back and it’s a poorer system for it. CSP can either enable these sorts of rich extensions (with obvious caveats!) or it can assume its committee knows best. This ends predictably: with people on the committee re-implementing large bits of the algorithms over and over and over again for lack of extension points, only to try to play with new variations. This robs CSP and its hoped-for user-base of momentum.

Next, the desire to reflect and not explain has helped the spec avoid reckoning with poor use of JavaScript types. The document.securityPolicy object doesn’t conceptually de-sugar to anything reasonable except a list of policy objects…but that more primitive SecurityPolicy object type doesn’t appear anywhere in the description. This means that if anyone wants to later extend or change the policy in a page, a new mechanism will need to be invented for showing how that happens: meta tags parsed via DOM, not objects created in script and added to a collection. All of which is objectionable on the basis that all that will happen is that some objects will be created and added to the collection that everyone suspects is back there anyway. This is like only having innerHTML and not being able to construct DOM objects any other way, and the right way to be presented with the need to go build idiomatic types for what will eventually be exposed one way or another is to try to design the API as though it was being used to implement the declarative form. JavaScript first gets you both good API and a solid explanation of the lifecycle of the system.

There is, of course, another option: CSP 1.1 could punt on an API entirely. That’s a coherent position that eliminates these frictions, and I’m not sure it’s a bad option given how badly the API has been mangled recently. But it’s not the best solution.

I’ve got huge hope for CSP; I think it’s one of the best things to happen to webappsec ever. What happens about the API will always be overshadowed by the value that it is already delivering. But as a design microcosm, its API is a petri-dish sized version of scenario-solving vs. layering, and a great example of how layering can deliver value over time; particularly to people who aren’t in the room when the design is being considered. An API that explains by showing how declarative layers on top of imperative is one that satisfies use case zero: show your work.

Chrome 24.0.1312.52 has been updated for Windows, Mac, Linux, and Chrome Frame, (Wed, May 22nd)

Johannes Ullrich — Fri, 24 May 2013 11:00:40 CDT

...(more)...

ISC StormCast for Thursday, May 23rd 2013 http://isc.sans.edu/podcastdetail.html?id=3326, (Thu, May 23rd)

Johannes Ullrich — Fri, 24 May 2013 08:01:49 CDT

...(more)...

Deploying Applications to GlassFish Using curl

Jason Lee — Thu, 23 May 2013 16:00:12 CDT

Earlier today, I wrote about a quick and dirty hack I put together to create a very simple editor for AsciiDoc files. While I have no immediate plans to make this a full-featured editor, there’s a part of me that can’t help but hack on it. This evening, I added support for loading and saving files. In fact, I’m using the editor to write this post. :)

For those interested in helping (or just need a good laugh :), you can find the code for this oh-so-cleverly-named project here.

MoVP II, (Thu, May 23rd)

Johannes Ullrich — Thu, 23 May 2013 13:00:26 CDT

Volatility is a Python framework for performing memory forensics. If you haven't tried it ...(more)...

I Swear This Blog Isn’t About Elections…

Alex Russell — Thu, 23 May 2013 11:00:23 CDT

…but if it were, there would be time to cover the W3C Advisory Board election. This is truly inside-baseball stuff, as most of the AB’s work happens in member-only areas of the W3C website and most of what they effect is W3C process.

So why care? Because spec licensing matters, sadly.

Let me first outline my view: in an ideal world, specification language for web standards would be in the public domain or dedicated to it. The body of intellectual property that is non-copyright is fought over via an independent process, and to the extent that it accumulates in a standards organization, it should also be possible for the group of members that have contributed to take their ball and start again somewhere else.

Why does this matter? Competition.

Standards bodies should not be insulated from the pressure to try to deliver better results. There are, of course, pathologies around this; some of which are common enough to have names: “pay for play”, “venue shopping”, etc. But in general, to the extent that many bodies can produce substitue goods, it gives them a reason to differentiate. The concrete example here is WHATWG vs. W3C. I don’t think it’s controversial to assert that without the WHATWG, the current W3C would be f’d. Competition makes everyone better, even for products that are “free” for consumers and are the product of community effort.

This, then, is why it’s such a terrible idea for the W3C’s Advisory Committee (the people who have some power) to elect representatives to the Advisory Board (who have even more power) that are willing to take the self-interested side of the W3C against liberal licensing of specs over the competition-enabling position that liberal licensing makes everyone better off (to a first approximation).

If you are an AC rep, the time is now to quiz candidates on this point. If you truly think that the W3C is a unique community, it’s important to realize that what makes it that special is a set of shared values, not a death-grip on legacy intellectual property rights. And fixating on that ownership is the fast-path to making everyone worse off.

Wireshark 1.10.0rc2 is now available http://www.wireshark.org/download.html, (Thu, May 23rd)

Johannes Ullrich — Thu, 23 May 2013 08:00:11 CDT

...(more)...

ISC StormCast for Wednesday, May 22nd 2013 http://isc.sans.edu/podcastdetail.html?id=3323, (Wed, May 22nd)

Johannes Ullrich — Wed, 22 May 2013 16:00:05 CDT

...(more)...

Privilege escalation, why should I care?, (Wed, May 22nd)

Johannes Ullrich — Wed, 22 May 2013 13:00:19 CDT

In my day job I spend about 90% of my time on the red team, performing vulnerability assessmen ...(more)...

Exposing Enterprise Services via REST APIs

Max Katz — Wed, 22 May 2013 11:00:19 CDT

Appery.io has always made it quite simple to integrated with backend systems via REST APIs — but what if those systems are behind the firewall and don’t support REST?? Many enterprise apps required access to data that is sitting on a SQL Database or on some business application like SAP or Oracle.

Enter RESTXpress!

With RESTXpress enterprises can easily expose databases and business applications securely via REST. Once exposed as REST services, they can easily be integrated into Appery.io apps.

Deployed behind the firewall, RESTXpress comes in two easy-to-install parts. An administrative console (running in a browser) easily sets up enterprise assets as REST services and a run-time gateway presents the enterprise assets as services to the outside world.

Right now, RESTXpress supports databases as assets to be made into REST services. You can use any SQL database with JDBC drivers. This month, we’ll be rolling out SOAP web services as a new type of enterprise asset that can be easily wrapped into a REST service.

And, RESTXpress is free!

You can watch a demo video, download the installer, or join the discussion community…all from one info page.

Originally published on the Appery.io blog.

Building Apps with Appery.io and Mashery-Managed APIs [Webinar recording]

Max Katz — Wed, 22 May 2013 08:00:14 CDT

Chrome 27 stable released http://googlechromereleases.blogspot.ca/ some security fixes, (Tue, May 21st)

Johannes Ullrich — Tue, 21 May 2013 16:00:20 CDT

...(more)...

Cascading Pattern – Machine Learning for Cascading and Hadoop

Paco Nathan — Tue, 21 May 2013 13:00:18 CDT

Announcing Pattern, a new library and framework that executes PMML workflows as Cascading applications on Apache Hadoop clusters.

Read more about it on the Pattern project page, signup for announcements on the mail list, or read the press release.

ISC StormCast for Tuesday, May 21st 2013 http://isc.sans.edu/podcastdetail.html?id=3320, (Tue, May 21st)

Johannes Ullrich — Tue, 21 May 2013 11:00:11 CDT

...(more)...

Devs in the ‘Ditch Slides Posted

Johanna Rothman — Tue, 21 May 2013 08:00:16 CDT

I gave a talk at Devs in the ‘Ditch last week when I was in London. I posted the slides on slideshare: Overcoming Three Pitfalls of Transitioning to Agile.

The very nice people at 7digital made a video and posted it, too. If you can take the time, watch the entire video. Rob Bowyer gave a great talk about kanban and theory of constraints. My part about overcoming these three pitfalls starts at about 42 minutes in.

There are many other pitfalls to transition. This talk had just three of them: the stories are too big, you need experts to do the work, and you implement as layers instead of through the architecture.

I hope you enjoy the presentation and the video.

Sysinternals Updates for Accesschk, Procdump, RAMMap and Strings http://blogs.technet.com/b/sysinternals/archive/2013/05/17/updates-accesschk-v5-11-procdump-v6-0-rammap-v1-22-strings-v2-51.aspx, (Mon, May 20th)

Johannes Ullrich — Mon, 20 May 2013 13:00:19 CDT

----------- Guy Bruneau https://github.com/jamesward/play-auto-refresh

Special thanks to Josh Suereth for helping me figure out the SBT magic.