Notice: CMSB v2.62 Beta 1 (April 29th, 2014)

Hi Dave,

I'm really pleased to hear you are ramping up the security.

Out of interest, can you explain the thinking behind the new directory structure please? And what will each folder will be used for?

Thank you,

Greg

Hi Dave

i tried to install over the top of the current install on our dev server to see if an upgrade would work and i am getting this error in the php_error.log.php file.

[30-Apr-2014 09:21:02 UTC] PHP Fatal error:  Call to undefined function isInstalled() in /home/domainame/domains/domainname/public_html/cmsAdmin/lib/init.php on line 410

Also i found that there are some errors on the upgrade when you want to use the new cmsUploads folder for uploads it keeps trying to reuse the old uploads folder.

that is only error i found in the upgrade process.

I also found when i did a clean install that it was using the uploads folder but in the section you where uploading the image into the thumbnail wasnt showing up in the in the section but the images where in the cmsUpload folder.

Hi Dave,

It seems that the Flash Uploader function does not function.
The activation or desactivation of the option in general settings does not have any effect.

Is it possible to modify the value of CMS_ASSETS_DIR/CMS_ASSETS_URL ?
I would like to use a particular folder.

Thanks! :)

Djulia

[edit]It seems that the Flash Uploader function does not function.

In fact, there is an error 404 on the file uploadify.swf

The variable CMS_ASSETS_URL uses the value of Program Directory.

Hi Greg, 

Out of interest, can you explain the thinking behind the new directory structure please? And what will each folder will be used for?

Sure, no problem.  The original intent is to prevent path disclosure of the admin folder.  Here's some background for anyone who is curious.

We're being asked to respond to more and more security audit reports, a web developer will do a website for a bank or a large corporation and then that company will order a 3rd party security audit, and the security company will produce a very large and nicely formatted report highlighting "potential" security risks, usually as low, medium, or high or using a color code system.  Some of the reported issues are extremely trivial, such as a full page write-up and "low warning" on an individual stray readme.txt left behind from Apache or something, or another full page for a leftover test.php file with no content.  And other times they have a few good suggestions.  Removing stray files (as an example) is a good practice, but doesn't pose a security risk if they don't contain code.

The end-clients (the corporations) want a response on any issues and don't really understand, and the web developers don't usually know what to say, so they pass it on to us with a request to address any "medium", "orange", or "red" risks, and we've explained it enough times that we've decided the simplest path is just to remove or modify anything in the software that could even be slightly perceived as a security risk or potentially justify a page in these reports.  It will just save everyone time moving forward.

So with the original /cmsAdmin/upload/ directory structure, anyone looking at the path to an upload could guess /cmsAdmin/ is a cms admin folder where the program might be.  They can't login without a password, but they'd know it was there.  This is called path disclosure and best practices are to obscure or hide as much of this information as possible, even though the design of the software should prevent access even if you knew all the paths and locations of files.  So we're changing the paths so future installations can't be flagged as disclosing the path of the admin folder.  No current sites are at risk, but that's why.  Here's the breakdown:

/cmsAdmin/ - The cms admin files live here, you can rename it on install for better security, but don't rename existing sites or you'll break your include code on the viewer pages.
/cmsAssets/ - Just holds the /3rdParty/ folder right now, things like jquery and tinymce, etc.  This will allow us reference jquery on code generated pages without having the path to jquery reveal the /cmsAdmin/ folder
/cmsUploads/ - This is where the uploads from the CMS will go.

Now, one potentially more serious issue we are addressing is cross-site request forgery (CSRF) attacks, that's where someone who knew the path to the admin.php script, and the email of a cms admin, could potentially trick an admin into clicking or requesting a link that would perform an action in the CMS with the admin rights.  This would require the admin was logged in to the CMS.  

So this update is a mix of enhancements to improve security across the board, and to reduce even trivial items that might get reported in a security audit and potentially alarm clients (or just take up time).

Hope that helps, let me know any questions.

Hi, Dave. I'm pleased to know there are enhanced security features!

I performed a clean install of the beta and have experienced the following:

-----

I think it was after the initial login to the admin I saw: "Upload Folder Url must be the web path only without a domain (eg: /uploads/)

The program automatically entered the url and install directory, as: http://www.mydomain.com/myinstalldirectory/../cmsUploads/"

But, I think it will want to indicate this instead: /../cmsUploads/'

-----

Security Settings: As advised by Security Tips, I renamed admin.php after install and then logged in with the new file name. (Could I have or should I have renamed this page prior to install?) It seems everything was functioning after logging in with the new admin URL except that I wasn't able to gnerate page code. After renaming the page, the code generator gives me this error:
"Forbidden You don't have permission to access /cmsb-beta/admin-uniquefilename.php on this server....."

-----

That's as far as I could get today, but please let me know if there are incremental beta updates and I'll reinstall and test again.

~ Deborah

Thanks everybody for the great feedback and beta testing!  I'm going to get a second beta out shortly that addresses all the issues mentioned.  Stay tuned!  Thanks.

Hiya Dave,

Sorry for the delay in responding to this but, changing form one directory in the root of the system to three is suboptimal. One of the things that becomes very difficult with working on people's sites is the amount of dross (ie files and directories) splattered all over the place.

The name of the app is cmsBuilder so the structure should be something like...

/cmsBuilder/Admin/
/cmsBuilder/Assets/
/cmsBuilder/Uploads/

With the option to rename /cmsBuilder/ to just /cms/ this still gives you the same result for the admin folder not being loaded for non-admin requests but also only one directory in the root of the site which is really preferable I think, it means that all of the cmsBuilder stuff is still based (default settings) in one base directory.

Cheers,
Larry