Re: [rest-discuss] More media type questions
>I'm referring to application-layer security, not just network-layer
> The entire security architecture of the Internet is based on media
security, to clarify -- application security is based on media type,
network security may take media type into account, but in neither case
is media type the only concern. 2010 saw many sysadmins block PDF
outright, across all protocols, until Adobe and Microsoft released
patches for their vulnerable software.
Just one tiny example I stumbled across in my bookmarks today, of this
hard-and-fast rule of the Internet (use the media type which best
describes your intended processing model for the data type you're
Nothing to do with REST, just a plain fact -- work against the Web, and
the resulting system is one which can't be hardened by anyone, not even
Google (except by changing the media type to what it should've been in
the first place). Of course, there's a guy in the comment thread who
insists on continuing to use text/html for his JSON because his entire
system is based on vulnerable, undefined browser handling of JSON as
JSON despite being served as text/html, where changing to application/
json would present his users with a download dialogue -- NOT REST.
REST systems, by working with the Web, may be more easily hardened by
avoiding all concerns derived from improper design:
There's a whole industry out there dedicated to "securing" things like
cookie-based authentication, sessions (randomized session IDs instead
of sequential) or AJAX-driven stateful cookies -- which just aren't
relevant concerns in REST. The "crawling" concern is entirely based on
figuring out what the links *really* are, since resources are defined
as URI + cookies, instead of the identification of resources constraint.
But these crawlers are still based on <a href> and <link> -- not URIs in
random markup -- plus the ability to decipher XHR code. This industry
is based on known exploits targeted at standardized data types (or, HTTP
un-RESTfully implemented). There is no way to predict what exploits may
be possible with unknown data types, so unknown data types are
considered security holes in Web systems, regardless of what REST has
to say about the practice.
My advice for hardening any website, is to first re-architect it as a
REST system, even if that means accepting crummy browser implementations
of HTTP authentication, or media/data types which are less-than-ideal.
Such tradeoffs have far-reaching benefits which outweigh the problems
they entail. The consequences of avoiding such problems only increase
with the scope, scale and longevity of the system. There's enough to
worry about not only *by* using standard media types, but also in *how*
they are used, without introducing unknowns into the system.
The security profile of any REST system is a known problem, not a
boundless one requiring consultant deployment of $30K dynamic security
software. I'm not implying that REST is secure, only readily securable.
REST systems are invulnerable to SQL injection, because SQL isn't part
of the API -- it's encapsulated behind a uniform interface, not exposed
*as* the interface. This concept is typically ignored -- by systems
which are then compromised by SQL injection.
IMO, Web security _starts_ with proper media type selection. You may
address everything else, but by straying from the IANA registry you're
still left with an unknown at the heart of your system, which is just
begging to be exploited -- likely in a manner that's already been
exposed and corrected for standardized media types, or which would have
been brought to light in discussion on ietf-types as part of the