HTTPS for /admin - News

[martin42]

I don't like unencrypted HTTP logins, so I made /admin accessible by SSL only.  The web server blocks /admin for HTTP users, but HTTPS users get to see the whole tree.

PROBLEM.  In Admin / Content / News (/admin/moduleinterface.php?module=News), the links

• Add Article
• Edit Article
• Delete Article

are all showing up as HTTP, not HTTPS.  This breaks my site because /admin is not visible over HTTP.

Is there any way to change this?  Normal "Page" content works, it's just "News" content that has this problem. In fact, all other Admin-type functionality seems to work just fine over HTTPS.

Many thanks!

[Ted]

Well, we could modify the module API to have CreateLink have an https option...  Lemme see how hard it would be to whip that up as it would be a good idea.

[martin42]

Thanks for your reply. I think I've fixed it - well, kludged it for now anyway!
In CreateLink(), about 20 lines down, I just commented out the line that says:
        $text .= $this->cms->config['root_url'];
because at this point you already have
        <a href="
and you don't really need to add
        http://www.example.com
unless the link is off-site. Removing the http://www.example.com part will keep all the links relative, so it all just works!

The only other hacks I had to make were:

1. In config.php, specify HTTPS not HTTP for the upload links (for my site only admins can upload):

        $config['uploads_url'] = 'https://www.example.com/uploads';
        $config['image_uploads_url'] = 'https://www.example.com/uploads/images';

2. Make admins and authors log in as: https://www.example.com/admin/login.php. Because if they just go to https://www.example.com/admin then they get redirected to http://www.example.com/admin/login.php.

It all seems OK so far, except...

NEW PROBLEM! In "Edit Page" the editor has a bug: when you insert an Anchor or a Picture, the dialog box that comes up does not expand the language text. So when adding an Anchor, you get:
        {$lang_insert_anchor_title}
        {$lang_insert_anchor_name}  :Is this a known problem, or have I broken something with my HTTPS changes?

Many thanks!

[martin42]

I was logging some test traffic today with a web interceptor proxy (my favourites are Burp Proxy and Paros). I noticed that my prototype setup with /admin over HTTPS still sent the session ID cookie in clear-text HTTP GET requests for things like icons and Javascript files which live outside the /admin folder.

Two suggestions to mitigate this:

1. It would be great if all the hard-coded "http://www.example.com" references could be removed.  That way, if you started with HTTPS, then all GET and POST requests (being relative to the original URL-root) would remain in HTTPS.

2. During the login process, if HTTPS is activated,  it would be great to issue a new Session Identifier cookie and mark that cookie as Secure (i.e. just set the flag in Set-Cookie). This asks the browser never to send the cookie over clear-text HTTP.  So even if a stray HTTP link was referenced (e.g. a static image file), the cookie would not get sent over HTTP. 

The key benefit of these two measures is that they would prevent an eavesdropper from stealing your session cookie and using it to deface your site!  Of course, this is just a standard security issue which  is common to all cookie-based web applications (and one which is quite difficult to exploit without ARP-spoofing on your LAN). But if CMS can deploy the standard countermeasures, then so much the better.

Thanks again!

[martin42]

It's OK, it's so much simpler than I thought

In config.php, just get rid of all occurrences of "http://www.yoursite.com". You just don't need those things. Now you can browse by HTTP or HTTPS as you see fit.

Only remaining issues for HTTPS Admin are:

1. "View Site" link (from Admin page) fetches some pages by HTTP. This does means that your Session cookie goes out in clear-text, but intercepting this isn't enough for an eavesdropper to gain Admin rights...

2. When you log in successfully to the Admin page, there are some more cookies set:

Set-Cookie: cms_admin_user_id=1
Set-Cookie: cms_passhash=123xxxxxxxxxxxxxxxxxx456
Really, these Cookies ought to be marked Secure if we come in over HTTPS, and they should probably be given "Path: /admin" so that buggy browsers don't send them when they're not needed. But it all seems to work properly anyway (at least in Firefox).

It might be slighly more secure if the admin userID and password hash was not sent on every admin request. As a possible alternative you might consider a second session cookie (marked Secure) for those GETs and POSTs that require authentication. It might also be good to allocate user ID's randomly, just to make brute-force attacks harder.

Sorry if some of this seems pedantic. My day job is in security