Re: ISSUE-107: Should there be any recommendations for https->http form submissions? [Techniques]

On Wed, 19 Sep 2007 10:53:48 +0200, Thomas Roessler <tlr@w3.org> wrote:

> On 2007-09-18 15:42:24 +0200, Yngve Nysaeter Pettersen wrote:
>
>>> Per ACTION-289, I've updated the editor's draft to call out explicitly  
>>> that
>>> we do not consider it a "change of security level" if a form on an  
>>> HTTPS
>>> site is submitted by plain HTTP.
>
>>>   @@Web Security Context@@
>>>   Editor's Draft $Date: 2007/09/18 12:01:01 $
>>>  http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#change-redirects
>
>>> The issue is whether we should be covering this situation.
>
>> I think it should be covered, and that we should discourage the
>> practice. I know there are some harmless uses, such as submitting
>> a google query, but I do not think these are important enough,
>> and the query can be handled in a differen manner.
>
> One question is whether we'd best discourage this by way of an
> authoring best practice, or whether we suggest that this situation
> trigger a hard error.

Well, in this case I would prefer the hard error.

>> I think most clients are already warning about HTTPS->HTTP form
>> submits.
>
> ... with a "don't bother me again" checkbox pre-selected, or so.

Actually, I don't think any of us have that checkbox for this dialog.

>> While it is not form submission as such, and may be covered by
>> other sections of the document, I have seen sites [1] using Flash
>> applets to submit HTTP POST queries from HTTPS hosted applets,
>> and in one case [2](August 2006), involving the Wynn Las Vegas
>> Hotel , *credit card* details were submitted in that fashion.
>> AFAIK Opera is currently the only client warning about this type
>> of form submission.
>
> There are a number of techniques of that kind which could be used.
>
> E.g., you could write an <img/> (or script, or iframe, or ...)
> element into the DOM using JavaScript, and put the credit card
> number into the URL.  So, I'm wondering how we would frame this in a
> way that could actually be implemented.

Well, yes, a site could bypass blocking/warning by using such techniques,  
and there isn't really much we (browser vendors) can do about it if they  
decide to be that naughty.

In most cases where this happens I believe it is by accident (as it was in  
case [2] above), and not intentional (although Beatport's nonsensitive  
requests [1] are used intentionally to "save processing power"), and it is  
the accidents I want stopped.

If anyone decides to use such techniques as you mention above it should be  
clear to anyone looking at it that they are trying to sneak past a  
security mechanism, which by itself should be enough to question how  
serious the site really is.


-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Wednesday, 19 September 2007 10:24:08 UTC