[HTTPS-Everywhere] HTTPS to HTTP form submission warnings

[Richard Fussenegger, BSc]

You can easily reproduce the problem on any page by simply altering a 
forms action attribute to use the HTTP scheme with the developer console 
(in Firefox and Chrome). I couldn't find a public available website with 
the explained issue that also has a ruleset defined. I created the 
following test page, although it doesn't match any HTTPS Everywhere 
ruleset it might still be useful.

https://movlib.org/https-to-http-warning.html

The problem only targets forms. My proposition was to search only for 
action attributes. Something along the lines:

for (var i = 0; i < document.forms.length; i++) {
   document.forms[i].action = document.forms[i].action.replace("http://" 
+ httpsEverywhere.currentDomain, "//" + httpsEverywhere.currentDomain);
}

An alternate approach could be to simply intercept form submissions and 
check the target URL for above condition and rewrite it before the 
actual submission occurs. This would help with injected forms.

Richard

On 8/20/2014 8:30 PM, Jacob S Hoffman-Andrews wrote:
> I wasn't able to reproduce this prompt on Tumblr, in a fresh FF31.0 
> profile with only HTTPS Everywhere installed. Is there another site 
> that reproduces reliably?
>
> I would be mildly in favor of search the page after load for form 
> elements where action points to an insecure URL that we can rewrite. 
> I'm more on the fence about rewriting the whole page. It might enabled 
> us to re-enable some rulesets that were disabled for MCB, but it would 
> work pretty inconsistently because of JavaScript insertions and runs 
> the risk of moving HTTPS Everywhere from "slow" to "really slow."
>
> On 08/20/2014 02:27 PM, Nick Semenkovich wrote:
>> Chrome now warns about this too, per:
>>
>> https://code.google.com/p/chromium/issues/detail?id=253249
>>
>> Looks like it's on the beta channel (M37) which will probably hit 
>> stable in ~one month.
>>
>> On Wed, Aug 20, 2014 at 1:10 PM, Richard Fussenegger, BSc 
>> <richard at fussenegger.info <mailto:richard at fussenegger.info>> wrote:
>>
>>     This topic was already raised once in the past (see
>>     https://lists.eff.org/pipermail/https-everywhere/2011-June/000914.html)
>>     but I'd like to discuss it again because it's pretty annoying and
>>     might even be disturbing to new users of the extension.
>>
>>     I found that the main problem are websites that have the scheme
>>     hard coded on form action attributes. I therefore propose that
>>     the extension could parse the page and rewrite any URL pointing
>>     to the current domain that has the http scheme set instead of the
>>     secure one. I'm also willing to produce this feature but I don't
>>     know if this is even possible with an extension like
>>     HTTPS-Everywhere. You might be able to answer this or maybe you
>>     have some arguments why this would be a bad idea.
>>
>>     Richard
>>     _______________________________________________
>>     HTTPS-Everywhere mailing list
>>     HTTPS-Everywhere at lists.eff.org
>>     <mailto:HTTPS-Everywhere at lists.eff.org>
>>     https://lists.eff.org/mailman/listinfo/https-everywhere
>>
>>
>>
>>
>> -- 
>> Nick Semenkovich
>> Laboratory of Dr. Jeffrey I. Gordon
>> Medical Scientist Training Program
>> School of Medicine
>> Washington University in St. Louis
>> https://nick.semenkovich.com/
>>
>>
>> _______________________________________________
>> HTTPS-Everywhere mailing list
>> HTTPS-Everywhere at lists.eff.org
>> https://lists.eff.org/mailman/listinfo/https-everywhere
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140820/fb632f8b/attachment.html>