[ic] ExtraSecure and special_pages/violation - PATCH

Angus Rogerson arogerso at uwaterloo.ca
Wed Sep 7 20:36:56 UTC 2016

Sorry for the delay in replying. Too many people on summer vacation.

As requested, please find patch attached. I will send it directly also in case it falls off on its way through Pipermail.

The patch is relative to 5.8.0.

Unfortunately, our upgrade to 5.8.0 is on indefinite hold and I have not applied this patch to our 5.6 production systems so it has not had a rigorous workout. It does pass basic sanity testing.

On our 5.6 system, we use the 'secure' feature to identify CAS authenticated pages. For 'secure' pages, we require auth CAS, which sets the environment variable REMOTE_USER. So my 5.6 kludge is to include this on pages which require 'secure' or authenticated access.
> [comment]
>    If the remote_user environment variable is not set
>    then bounce to the secure version of this page to force authentication.
> [/comment]
> [seti scratch_remote_user][env REMOTE_USER][/seti]
> [if !scratch scratch_remote_user]
>     [bounce href="[area secure=1 href=@@MV_PAGE@@]"]
> [/if]



Angus Rogerson, BMath, BScN, RN

Duct Tape Programmer
University of Waterloo | Retail Services & WatCard | Information Systems

Visit Us Online & Right On Campus www.retailservices.uwaterloo.ca

From: interchange-users-bounces at icdevgroup.org [interchange-users-bounces at icdevgroup.org] on behalf of Jon Jensen [jon at endpoint.com]
Sent: Thursday, July 14, 2016 2:19 PM
To: interchange-users at icdevgroup.org
Subject: Re: [ic] ExtraSecure and special_pages/violation - PATCH


In going through some old email I found the thread forwarded below. I
checked the mainstream Vend::Page code and don't see any evidence that it
ever got patched with the changes we discussed.

Could you please attach a patch of the full diff between your Vend::Page
and the mainstream one? Or you can just attach your entire Vend::Page if
that's easier for you. Or a GitHub pull request would be great!

Anyway, I'd like to look this over again and get it committed to the
Interchange Git repository if we can.


On Mon, 23 Jun 2014, Angus Rogerson wrote:

>> 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.
> Not yet. The code which uses this is working well on my development system. Hopefully we will upgrading to 5.8.x in the next few months, unless my priorities are changed again.
>> 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?
> I finally had to give in and learn about map, grep and sort (not so scary when you read: http://www.perlmonks.org/?node_id=675494). Your change makes a lot of sense to me now that I have read about BounceReferrals and BounceReferralsRobot. The sort makes the output pretty but probably is unnecessary.
> I have done preliminary testing on:
> diff -r1.4 Page.pm
> 123,125c123
> <                     map { "$_=$CGI::values{$_}\n" }
> <                         grep { !$Vend::Cfg->{BounceReferrals_hide}->{$_} }
> <                             sort keys %CGI::values;
> ---
>>                      map { "$_=$CGI::values{$_}\n" } keys %CGI::values;
>> 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.
> I am actually referring from an https url to another https url which forces the user to authenticate against the university central authentication service using mod_auth_cas.
>> If anyone objects, please speak up soon.
>> Thanks,
>> Jon
> Thanks
> Angus
> ---
> Angus Rogerson, BMath, BScN, RN
> Duct Tape Programmer
> University of Waterloo | Retail Services | Information Systems
> Visit Us Online & Right On Campus www.retailservices.uwaterloo.ca

Jon Jensen
End Point Corporation

interchange-users mailing list
interchange-users at icdevgroup.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patchExtraSecureRedirect.txt
URL: <http://www.icdevgroup.org/pipermail/interchange-users/attachments/20160907/e7e9a79d/attachment.txt>

More information about the interchange-users mailing list