Re: IE Team's Proposal for Cross Site Requests

Laurens Holst wrote:
> I don’t really see how POST is less harmful than DELETE. POST (if used 
> in a REST-y way) can be used to wreak serious havoc (e.g. spam messages, 
> overload server data capacity, post viruses, adding new super user 
> accounts for the hacker, change settings such as passwords, influence 
> poll results).
> 
> Additionally, there are a great number of sites that are using the HTTP 
> POST method for operations that would be more suitable for PUT and 
> DELETE. The reason that this happens is probably HTML’s fault, because 
> it only supports GET and POST, crippling the functionality that HTTP 
> provides. Non-REST webservices protocols such as XML-RPC and SOAP also 
> exclusively use POST.
> 
> If XDR only supports GET and POST, it encourages sites to use POST to 
> implement delete functionality and abuse the HTTP protocol because that 
> is the only way they can get the functionality they desire to work. 
> Basically, you’re boycotting REST in favour of SOAP.
> 
> So, I do not see much benefit in the decision to disallow DELETE but 
> allowing POST.

As a matter of fact, it would be harmful.

> I don’t think you’re really keeping users very safe that way. To quote 
> an example, PHP is by default configured to send session credentials 
> entirely through sessionID link parameters when cookies are not 
> available, and thus don’t need cookies or authentication headers. And on 
> many sites (e.g. phpBB-based forums), communication with the server 
> (including deletion) happens exclusively through GET and POST requests. 
> XDR’s restrictions on methods and credentials will not do these sites 
> any good. Rather, they encourage even more sites to work around the 
> restrictions.
> 
> Additionally, if you really want to keep sites safe in this manner, you 
> should disallow cross-site POST requests for both XDR and HTML forms. 
> Otherwise, there is already a breach in the safety, POST is equally 
> suitable for ‘public’ data as DELETE and PUT are. You should allow those 
> methods, so that developers can at least provide a proper REST API and 
> are not forced to overload POST like XML-RPC and SOAP and friends do.

Absolutely.

> Then create a whitelist, with at least the Accept-* headers on it. They 
> are clearly defined, and it is doubtful that they are used in a 
> different manner than described. The use cases are clear and plenty.

Correct.

> I don’t think it is up to Microsoft to decide that content negotiation 
> is useless and that part of HTTP should not be supported even though it 
> poses no security risk. Part of the reason that content type negotiation 
> is reasonably uncommon in the wild is partially because of mediocre 
> support by user agents. By the way, content language and content 
> encoding negotiation is pretty common, actually.
> 
> Content type negotiation is very useful and I think a very nice feature 
> of HTTP, offering different ‘views’ (e.g. RSS or RDF, SVG or PNG) of the 
> same content. With XHR it was finally possible to use content type 
> negotiation in a good way in browsers, please don’t break it again in XDR.

Yes.

Not that it really matters -- even if Conneg wasn't useful, it's always 
bad if specs start profiling the base protocol without very good reasons.

> ...

BR, Julian

Received on Sunday, 16 March 2008 19:42:08 UTC