How can I change the admin path in SilverStripe 3.1.x? - security

Can anyone tell me how I can change the path to the admin on SilverStripe 3.1.x? A site I built has a medium risk security issue outstanding from a security scan - apparently the path /admin is too easy to guess.
The recommendation is to:
Modify the link, name or location of the administrative login page so it cannot be easily
identified/guessed by an unauthorized user. If only internal users require access, implement
additional restrictions to restrict access from the Internet.
I found something for SilverStripe 2.x here: http://www.silverstripe.org/archive/show/3550 , but I need something similar for SilverStripe 3.1.x

Not fully test but adding those into your config.yml seem to do the trick:
Director:
rules:
'admin': ''
'fancyLongAdminURL': 'AdminRootController'
AdminRootController:
url_base: 'fancyLongAdminURL'
LeftAndMain:
url_base: 'fancyLongAdminURL'
Only thing I can see not working is the myProfile link in the top left corner. But that's because the url is hard coded in the template LeftAndMain_Menu.ss, which you could create your own.
Edit: The above should work fine for the framework. For the CMS and other modules, this will have to be investigated and may need more classes/templates overrides, for example:
The CMS seems to have hardcoded admin url in
Intall_deleteinstallfiles.ss, AssetAdmin.js, VirtualPage.php,
SiteTree.php, AssetAdmin.php, routes.yml....
The Reports module have it hardcoded in Report.php
In those cases maybe a URLRewrite might be more convenient until this is implemented in the core.
Update: This has now been merged into the master branch so it should make its way into the next 4.0 release:
https://github.com/silverstripe/silverstripe-framework/pull/3274

No, there isn't currently any mechanism for changing the admin path. If this is something you really think should be in core, you could consider raising an issue for it.
It's interesting that there is an issue with this. SilverStripe is used for a large number of Government websites and the website of a major bank, so it should have passed quite a few code audits in the past.
The best course of action would be to use .htaccess or similar method to restrict access to /admin to a whitelist of IP addresses. This is far more secure than simply changing the path - "security through obfuscation" is not true security.

Related

Switching off subdomains in phpfastcache

I'm using phpfastcache with files strategy. I'm caching sql queries.
As I see phpfastcache creates folders with subdomain name (ex. www.domain.pl).
I have admin panel in admin.domain.pl which calls api.domain.pl.
Problem is that when I, for example, want to clear cache from admin panel it clears api.domain.pl directory - not www.domain.pl.
Can I turn off subdomains in phpfastcache? I don't see such option.
Edit:
I found answer here: https://stackoverflow.com/a/33848394/979911
Accordinglly to: https://stackoverflow.com/a/33848394/979911
phpFastCache::setup('securityKey', 'phpfastcache'); is responsible for directory name
I'm a bit late on this, but a quick heads up on the securityKey:
In your example you tend to mutualize your website cache and admin cache.
This could to potential security issues as the cache directory are not longer compartmentalized.
I warmly advise you to setup two different security key and call them from your admin panel.

Using a Web Site Document with an XPage - how to setup correctly?

I have set up a small XPage and have until now used the full path to the Xpage for testing, i.e.
http://devsrv1.magerman.ch/Development/Schulungen/Schulungen1_0/Schulungen_(1_0)_Dev.nsf/HomeWithDataView.xsp
I then tried to apply a Web Site Document
But the links are no longer currently functioning. I have the feeling that I'm missing something pretty basic, and am unsure as to what the best practice is. I'm quite happy with having the original request to the hostname resolve to a full path, i.e.
input
schulungen.magerman.com
and have it resolve to
schulungen.magerman.com//Development/Schulungen/Schulungen1_0/Schulungen_(1_0)_Dev.nsf
but haven't found a way to do this elegantly.
At the moment, my relative links '/OtherXpage.xsp' fail as they try to get to schulungen.magerman.com/OtherXpage.xsp
Any pointers?
Create a Web Site Rule. You can create it from your Web Site document in edit mode with action button " Web Site ... / Create Rule".
You can find a description how to fill the fields here.
The problem is usually that you need to add a trailing slash to the hostname
http://www.xpagedeveloper.com/2013/quicktip-get-right-path-when-autolaunching-an-xpage

SSL with CartThrob - in-template redirect or htaccess on the basis of URL segment?

this is a broader question than I would probably ask of the CartThrob folks, which is why I'm posting it here. What would the community recommend as far as SSL is concerned with CartThrob? The store functions are limited to a couple of key template groups. So my thinking was perhaps the best way to handle it would be htaccess on the basis of the presence of those URL segments. I would like to return the user to a non-SSL connection when they are not in the store area. So a trigger might be the first segment being "basket" or "account" for example. Or what about an in-template redirect to the secure URL? Very interested to hear the community's suggestions on how best to handle SSL within a given area of an EE site. I'm interested in whatever makes the most sense to implement, while also ensuring that, for example, all assets - even those loaded with path variables - are loaded via SSL. Thanks all!
I've always used CartThrob's https_redirect tag (docs) on my checkout screens, which will rewrite your {path}, {permalink} (etc)-created URLs to use https, as well as redirect you to the https:// version of your page if necessary.
That, combined with using the protocol-agnostic style of calling scripts and stylesheets should get you most of the way in getting your secure icon in the browser.
(Example:)
<script src="//ajax.googleapis.com/ajax/libs/jqueryui/1.9.1/jquery-ui.min.js"></script>

Security of website with user's pages: folders or subdomains?

The client wants to make the site (webservice, as he named it), where users can create their own pages, including with JS scripts, etc. I see two ways - using the folders:
http://service.com/user/name/ ...
and subdomains:
http://user.service.com/...
Both paths are not the problem, but the client wants to make it using folders for SEO benefits.
I think if I use folders, it will make the site less secure. For example, user can send AJAX request from its page and the server will respond him. If it was a sub-domain, in accordance with the SOP (Same Origin Policy) request would be rejected. Correct if I'm wrong.
Is it real problem with SOP for folders?
Are there any other security issues for folders?
Is it safer to use subdomains?
Continuing study this issue. As I understood, in case of using folders user also can create page with Black Hat SEO and search Engines will ban my domain. Am I right?
So I can already see 2 security issue in folders and no way to fix it. Are there solutions for it? Are subdomains really more safer or they have other issues?

Can I unprotect a single script via .htaccess using CodeIgniter?

I'm in a development environment and we're using basic .htaccess/.htpasswd authentication to keep lurkers out. But some of my AJAX calls are coming back with HTTP/401 authentication failed errors. Is it possible for me to allow access only to those specific URL's? I can't easily do it by popping a new .htaccess in a subfolder because CodeIgniter uses ReWrites.
It's not possible to allow access only to those specific URL's. Unfortunately, .htaccess and .htpasswd authentication operates on a directory level only. And you're exactly right about why just using a subdirectory won't work - b/c of CI rewrites, which happen AFTER Apache has transferred control to CodeIgniter's index.php front controller.
The easy option, if you're working on something that (1) is not likely to be hacked in the first place, and (2) can't reveal sensitive data even if it is, is to use security via obscurity. Don't have any links to your dev site, include a noindex directive for search engine crawlers, and go on your merry way. This also has the advantage that you can test versions of the site with your colleagues and friends by just telling them the URL to go to.
If you're more worried about security, then you're probably building an auth module for your website's users. In that case, for your dev environment, just call that auth module in the constructor for all of your controllers, and redirect to the login page if the user is not logged in.
Good luck!

Resources