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

Agree all round with Yngve here - I don't think any of us let you  
checkbox-disable the "HTTP submit from HTTPS dialog", and I agree  
that sites working around the situation are not the intended target  
here.  This is one of those "hope users never see it, because site  
developers see it during development and fix it before it is  
deployed" things.

I assume hard error means "display an error, dismissable case-by- 
case" and not "hard stop the action from happening."

Cheers,

Johnathan

On 19-Sep-07, at 6:22 AM, Yngve N. Pettersen (Developer Opera  
Software ASA) wrote:

>
> 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
> ********************************************************************
>

---
Johnathan Nightingale
Human Shield
johnath@mozilla.com

Received on Wednesday, 19 September 2007 14:24:33 UTC