Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] More media type questions

Expand Messages
  • Eric J. Bowman
    ... I m referring to application-layer security, not just network-layer security, to clarify -- application security is based on media type, network security
    Message 1 of 6 , Oct 10, 2010
      > The entire security architecture of the Internet is based on media
      > types.

      I'm referring to application-layer security, not just network-layer
      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
      registration process.

    Your message has been successfully submitted and would be delivered to recipients shortly.