[
Lists Home |
Date Index |
Thread Index
]
Jim Ancona wrote,
> --- Miles Sabin <miles@milessabin.com> wrote:
> > Interestingly, the RESTian push for GET over POST for web services
> > is likely to make exploits of this sort easier. That's not a
> > criticism of REST per se, but it suggests that RESTians probably
> > have a duty to think about the security implications of GET vs
> > POST.
>
> The HTTP spec describes some of the security implications of method
> selection.[1][2] No REST advocate I've encountered has advocated
> using GET for actions that are not safe. What sort of additional
> implications were you thinking about?
The implications of web services as they actually are/will be deployed
as opposed to how they _ought_ to be deployed.
No matter what RFC 2616 says, unsafe actions will (continue to) be made
available via GET. This is particularly likely in (thought to be)
closed and controlled environments, eg. the internal network in the
firewall penetration scenario I described earlier. GET based services
are the ones which would be most vulnerable to the external entity
tricks discussed, because it's easier to trick an application into
issuing a meaningful GET than a meaningful POST.
It's tempting to say that people who don't follow the rules get what
they deserve, but that ignores the fact that compromised systems can
hurt innocent third parties.
Nb. I'm not arguing that the GET based SOAP binding is a Bad Thing,
merely that it needs to be emphasized that GET based services might
need to be secured more carefully that POST based ones.
Cheers,
Miles
|
