Oh once correction to what I wrote below, after looking at the Java patch to modify their behavior (which I'll mimic in php-shindig):
1. Disallow POST/PUT requests of Content-Type form-urlencoded to the social API endpoints with a clear error message. 2. In the case where the new body signing oauth_body_hash parameter IS NOT available then include the raw body in the OAuth base string for signature verification the same was PHP Shindig does. This should allow API clients which are working with PHP Shindig to work with Java Shinding just by switching the content-type header. 3. In the case where the new body signing oauth_body_hash parameter IS AVAILABLE then use the new OAuth body signing verification mechanism Which I thinking about it is indeed the correct solution to make sure there's never any unsigned (and thus insecure) post body's going around. You can see the suggested patch for java land with more details at: https://issues.apache.org/jira/browse/SHINDIG-974 On Sun, Mar 15, 2009 at 1:51 PM, Chris Chabot <[email protected]> wrote: > Things are not quite settled yet to how this will be dealt with, > > The OAuth spec does indeed state it should include the POST Parameters with > form-urlencoded POSTs, however this is intended for having actual params > (foo=a&bar=b), and not for posting a JSON/XML/Atom documents as we're doing. > So even though php-shindig supports that, it's somewhat invalid since it's > the wrong use of form-encoded post's, and also java shindig can't mimic this > behavior since the servlet engines don't make the raw post body available on > form-urlencoded posts. > > The OAuth spec doesn't say anything about other content-type posts (like > the application/{json, xml, xml+atpm} we use), so according to the current > OAuth spec they shouldn't be signed, which means that those requests would > be vunerable to man-in-the-middle attacks (ie: the post content could be > modified in transit), which isn't an acceptable situation for us, we want to > have this protection. > > So to solve this situation, Brian is working on a new OAuth spec proposal > which covers this signing the post body of other content types: > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/3/spec.html > > Once the dust settles for this, I'll modify php-shindig to: > > - Not include the json/xml/atom document of the post body in the oauth > signature calculation for www-url-formencoded POSTs > - Do include the json/xml/atom document of the post body for > application/{json, xml, xml+atom, (and variants)} POSTs > > Which should make it consistent with both the OAuth spec's, and how Java > shindig will work. > > As I pointed out in my earlier post though, there are live sites which have > the old behavior, so we should keep that in mind for the REST/RPC client > libs and add an option to them to allow the old style including the > form-urlencoded post body in the signature for those 'legacy' sites. > > Hope that clears things up a bit :) > > -- Chris > > > On Sun, Mar 15, 2009 at 5:48 AM, Chirag Shah <[email protected]>wrote: > >> > Currently PHP Shindig always includes the POST body in the OAuth >> signature >> > checking, even if it's www-form-urlencoded, it'll use the raw post body. >> >> Does this mean PHP Shindig is signing the POST body when the content >> type is application/{json,xml,atom+xml)? >> >> If so, I thought the POST body should only be included in the OAuth >> signature when the content-type is x-www-form-urlencoded. >> (At least that's how I interpreted section 9.1 of the OAuth spec >> http://oauth.net/core/1.0/#anchor14 ) >> >> On Sat, Mar 14, 2009 at 10:22 AM, Chris Chabot <[email protected]> >> wrote: >> > Currently PHP Shindig always includes the POST body in the OAuth >> signature >> > checking, even if it's www-form-urlencoded, it'll use the raw post body. >> > >> > Also it only supports the application/{json,xml,atom+xml) content-type >> > headers and won't recognize things like text/xml or >> application/javascript. >> > >> > I'd be more then happy to adjust any of these things (not including the >> post >> > body on form-urlencoded, and adding support for the extra content type >> > headers, and even if you have a strong preference making the default >> output >> > content-type application/javascript), as far as code goes those changes >> are >> > pretty small. >> > >> > However we do have a 20-something medium to very large SNS's using >> > PHP-Shindig, and in my experience it can take months before everyone is >> > adjusted to a code update or a new spec, so it might be worth seeing >> what we >> > can live with, and minimizes the amount of breakage it'll cause in the >> > transition phase. >> > >> > On Sat, Mar 14, 2009 at 12:59 AM, Louis Ryan <[email protected]> wrote: >> > >> >> Chris >> >> >> >> I've implemented strict content type check for REST/RPC endpoint in >> Java >> >> shindig (see http://codereview.appspot.com/28042/show). The next thing >> Id >> >> like to figure out the variance between Java and PHP Shindig for body >> >> signing, in particular what happens currently in PHP to the signature >> base >> >> string when the content type is application/x-www-form-urlencoded but >> the >> >> body is JSON. For backwards compatability the Java implementation will >> need >> >> to do the same thing when the new content signing mechanism is not >> being >> >> used. >> >> >> >> -Louis >> >> >> > >> > >
