Re: User interface requirements for redirecting to unsafe methods

On Feb 14, 2010, at 2:06 PM, Roy T. Fielding wrote:

> On Feb 12, 2010, at 3:11 AM, Maciej Stachowiak wrote:
>> On Feb 12, 2010, at 2:57 AM, Julian Reschke wrote:
>>
>>> Maciej Stachowiak wrote:
>>>> RFC2616 has some MUST-level user interface requirements relating  
>>>> redirecting to unsafe methods:
>>>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.3xx 
>>>> > "The action required may be carried out by the user agent  
>>>> without interaction with the user if and only if the method used  
>>>> in the second request is GET or HEAD."
>>>
>>> That's a bug. It should talk about safe methods. Re-opening a very  
>>> old ticket: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/10#comment:5 
>>> >.
>>>
>>>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.301 
>>>> > "If the 301 status code is received in response to a request  
>>>> method that is known to be "safe", as defined in Section 7.1.1,  
>>>> then the request may be automatically redirected by the user  
>>>> agent without confirmation. Otherwise, the user agent must not  
>>>> automatically redirect the request unless it can be confirmed by  
>>>> the user, since this might change the conditions under which the  
>>>> request was issued."
>>>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.302 
>>>> > "If the 302 status code is received in response to a request  
>>>> method that is known to be "safe", as defined in Section 7.1.1,  
>>>> then the request may be automatically redirected by the user  
>>>> agent without confirmation. Otherwise, the user agent must not  
>>>> automatically redirect the request unless it can be confirmed by  
>>>> the user, since this might change the conditions under which the  
>>>> request was issued."
>>>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.307 
>>>> > "If the 307 status code is received in response to a request  
>>>> method that is known to be "safe", as defined in Section 7.1.1,  
>>>> then the request may be automatically redirected by the user  
>>>> agent without confirmation. Otherwise, the user agent must not  
>>>> automatically redirect the request unless it can be confirmed by  
>>>> the user, since this might change the conditions under which the  
>>>> request was issued."
>>>> I suggest that these requirements should be removed (or at least  
>>>> changed to SHOULD- or MAY-level) for the following reasons:
>>>> 1) It is inappropriate to dictate user interface requirements. A  
>>>> protocol spec should limit itself to the syntax, semantics and  
>>>> processing requirements of protocol elements. It should not  
>>>> attempt to dictate the user interface of tools using the protocol.
>>>
>>> That's debatable.
>>
>> Do you have a counter-argument? What possible justification can  
>> there be for a protocol specification to place requirements on  
>> application UI?
>
> It doesn't place requirements on the UI.  It places a constraint on
> automated continuation of a multi-request sequence (the redirect  
> protocol).

"Confirmed by the user" seems to be a user interface requirement. The  
phrase "interaction with the user" also seems to signal a UI  
requirement. Neither the contents nor the semantics of the protocol  
message are affected by whether it was "confirmed by the user" or  
whether there was "interaction with the user".

>
>>>> 2) There are no requirements for user agents to confirm an  
>>>> initial request made with a non-idempotent method with the user,  
>>>> to make such requests only in response to explicit user actions,  
>>>> or to let the user know that when they take an action that will  
>>>> request a new resource, that it is being made with an unsafe  
>>>> method, or what host the request is being sent to. Thus, the  
>>>> requirement to get user confirmation only on redirects to an  
>>>> unsafe method is not effective in preventing such requests from  
>>>> being made without the user's knowledge.
>>>
>>> See <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#rfc.section.7.1.1 
>>> >:
>>>
>>> "...Implementors should be aware that the software represents the  
>>> user in their interactions over the Internet, and should be  
>>> careful to allow the user to be aware of any actions they might  
>>> take which may have an unexpected significance to themselves or  
>>> others.
>>>
>>> In particular, the convention has been established that the GET,  
>>> HEAD, OPTIONS, and TRACE methods SHOULD NOT have the significance  
>>> of taking an action other than retrieval. These methods ought to  
>>> be considered "safe". This allows user agents to represent other  
>>> methods, such as POST, PUT and DELETE, in a special way, so that  
>>> the user is made aware of the fact that a possibly unsafe action  
>>> is being requested...."
>>
>> I don't see a normative requirement on user agents here. If the  
>> MUST-level requirements for redirects were replaced with similar  
>> non-normative suggestions, then that would be fine by me.
>
> The normative requirement here is actually in HTML, not HTTP.

I looked in both HTML4.01 (the current REC) and HTML5 (the current  
draft) and was unable to find a relevant normative requirement. As far  
as I can tell, there is no requirement on form submission to let the  
user know whether it will use a safe or unsafe method, to tell the  
user the URI that is being requested, to make requests using unsafe  
methods only as a result of user interaction, or to confirm requests  
using unsafe methods with the user. Or at least, I couldn't find it.


>
>>>> ...
>>>> 5) RFC2119 says "Imperatives of the type defined in this memo  
>>>> must be used with care and sparingly.  In particular, they MUST  
>>>> only be used where it is actually required for interoperation or  
>>>> to limit behavior which has potential for causing harm." In this  
>>>> case, there is no interoperability need for these requirements.  
>>>> And furthermore, per point 2, the requirements do not actually  
>>>> limit any behavior.
>>>> ...
>>>
>>> See above.
>>
>> Likewise. There's no normative requirement for user agents to do  
>> anything in particular to inform the user or seek user confirmation  
>> to make an unsafe request in the first place.
>
> Why would there be?

I can't think of a good reason for there to be such a requirement. But  
I also can't think of a good reason for the above listed requirements  
on redirects.

>
>>>> 6) The requirements cannot be met by a user agent that normally  
>>>> operates without direct user interaction.
>>>
>>> Confirming with the user doesn't not necessarily mean that this  
>>> needs to happen in time the 3xx is encountered. That being said, I  
>>> agree that it would be good add more guidance here.
>>
>> Removing the requirements in question, or making them SHOULD- or  
>> MAY-level, would address this. I should probably also add:
>>
>> 7) The requirements do not make sense for client software that uses  
>> HTTP networking as part of its implementation, but this is largely  
>> hidden from the user. For example, let's say a program uses a SOAP  
>> API to implement part of an application feature that is not  
>> obviously Web- or network-related. Prompting the user about a  
>> redirect in such a case would be nonsensical, since the user is not  
>> even aware that he or she is using an HTTP user agent.
>
> It doesn't require that the user be prompted.  It requires that  
> clients
> not include a rather obvious security hole or at least be specifically
> configured by the user for that purpose (prior confirmation).


On the face of it, this conformances requirement appears to require  
interaction with the user: "The action required may be carried out by  
the user agent without interaction with the user if and only if the  
method used in the second request is GET or HEAD." If it's not  
intended that interaction with the user is required, then certainly  
the wording could be clarified.

And this requirement appears to require that the user can confirm that  
specific request: "Otherwise, the user agent must not automatically  
redirect the request unless it can be confirmed by the user." By my  
reading, the referent of "it" is "the request". If that's not intended  
to require individual confirmation of each such redirect request, then  
once again, clearer wording would be helpful.

Also, could you please explain the security hole that would be created  
by not having the user confirm the request? It is not obvious to me. I  
would have expected that whatever security risk is presented by  
following a redirect of a POST is presented to the same degree by  
simply issuing a POST in the first place.

Regards,
Maciej