[ic] ExtraSecure and special_pages/violation - PATCH

Jon Jensen jon at endpoint.com
Wed Jun 11 22:50:41 UTC 2014


Angus,

Following up on a long-dormant thread ...

On Thu, 14 Nov 2013, Angus Rogerson wrote:

> On 2013-11-13, at 10:37 AM, Jon Jensen wrote:
>
>> On Wed, 6 Nov 2013, Angus Rogerson wrote:
>>
>>>> On Fri, 25 Oct 2013, Angus Rogerson wrote:
>>>>
>>>>> In an email exchange ending with 
>>>>> http://www.icdevgroup.org/pipermail/interchange-users/2009-December/051506.html, 
>>>>> Jon and Tom described a solution for better behaviour for the 
>>>>> ExtraSecure feature.
>>>>>
>>>>> In an email 
>>>>> http://www.icdevgroup.org/pipermail/interchange-users/2013-May/054042.html, 
>>>>> Paul hints at the need for similar functionality.
>>>>>
>>>>> The patch below implements this feature in 5.8.0. Sorry, I don't 
>>>>> have git.
>>>>>
>>>>> With this patch, the user gets a 301 redirect to the secure version 
>>>>> of the page instead of the violation page. The logGlobal uses some 
>>>>> non-standard CGI values which would need to be added to @Map in 
>>>>> Vend::Server.
>>>>
>>>> Thanks for sending that, Angus. You mention that you needed to change 
>>>> something in Vend::Server. Will you please send a patch for that too 
>>>> so we can consider the whole set of changes together?
>>>
>>> Sorry about the delay. Please find attached patch which adds 
>>> script_uri to list (@Map) of environment variables to copy to CGI. 
>>> This is used to log anytime the bounce happens so we can identify who 
>>> is sending people to the non-secure page.
>>
>> I'm a little confused about exactly what is going on here. The 
>> SCRIPT_URI environment variable you're using only exists when Apache's 
>> mod_rewrite was in effect for the request, which is far from the only 
>> way requests pass through to Interchange.
>>
>> That is explained here:
>>
>> http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html
>>
>> I could see the patch making sense if it can use one of the standard 
>> environment variables Interchange already has. Is there one that would 
>> work, or one of the catalog path configuration variables, or something?
>
> We use mod_rewrite in our installation so I didn't realize others did 
> not have access to SCRIPT_URI. Please find attached a revised patch 
> which does not use script_uri, just the referer. This patch does not 
> require any changes to Vend;:Server.
>
> Since users are now being redirected to the correct secure version of 
> the page anyway, it is not terribly important to be able to track down 
> who might be linking to a non-secure version of our page. If for some 
> reason it was important, then it should be possible to use the time the 
> error is logged and the referer to find the offender in the web server 
> logs.

Are you using the patch you submitted on a production website? If so, I'd 
still like to get this committed to Interchange so you don't have to 
maintain a forked version.

I noticed something in the patch that you brought over from the 
BounceReferrals code that I don't think belongs here:

     grep { !$Vend::Cfg->{BounceReferrals_hide}->{$_} }

You're excluding URL query parameters that are excluded from 
BounceReferrals redirects, but I don't think any parameters should be 
excluded on a redirect from http to https. So I would remove that grep. Do 
you see any problem with that?

Otherwise, I think this should be fine. There has been some debate about 
whether redirecting users from http to https automatically is a good idea 
or not:

http://security.stackexchange.com/questions/49645/actually-isnt-it-bad-to-redirect-http-to-https

But everyone seems to agree there is no reasonable alternative given 
current browser behaviors, so I'm inclined to say this is a usability 
improvement worth making.

If anyone objects, please speak up soon.

Thanks,
Jon


-- 
Jon Jensen
End Point Corporation
http://www.endpoint.com/




More information about the interchange-users mailing list