Posts From September, 2010

mojoPortal 2.6

mojoPortal 2.6

Today, we're pleased to announce the release of mojoPortal 2.6. We had planned on releasing this version much sooner but we kept adding features! In the future, we're planning on releasing about once per month. Larger features will take more time but our community shouldn't wait for smaller enhancements.

With this release, we're introducing SuperFlexi and the Blog Post List modules. We also have a lot of enhancements and new features for existing modules. Finally, we've made some improvements to Framework and we're releasing a new free skin called "Scout", which can be downloaded from the mojoSkins project.

Where to Get It?

Head over to our GitHub Releases Page.

SuperFlexi

The SuperFlexi module is intended to serve as an easy templating system that works as a go-between for front-end developers and users. Developers can easily create "Solutions" that determine, to a large extent, the module's uses; controlling both what kind of input users can store in the database and what markup is created on the page. Users can then simply select a "Solution" in the module settings, and create their content with straightforward easily-understood forms, which will then be rendered as determined by the developers defined markup.

SuperFlexi aims to give end users much easier control over their content, even when that content might normally be quite complicated (as in the case of sliders, tables, structured or gridded HTML, and many other things). Possible uses for SuperFlexi are virtually limitless and we're really excited to be adding it as a core module in mojoPortal 2.6.

With mojoPortal 2.6, we're including 8 solutions; Accordion, Banner Slider, Icon Blocks, Image Blocks, Personnel List, Quick Links, Social Media Links, and Tabs. Each of these is demonstrated on the mojoPortal Demo Site. Please note, SuperFlexi does not currently support SQLite and PGSQL. We should have support for those database platforms in a couple of weeks.

To learn more about SuperFlexi, check out the documentation. We've also created a new Forum, just for SuperFlexi.

Blog Post List Module

So, for a very long time, the official guidance for showing a list of blog posts on pages other than the page your blog is on was to use the Feed Manager to consume your blog's RSS Feed. This meant that the Feed Manager had to make an http(s) connection back to your site, consume the feed, cache the feed contents in the database, and then query the database for the cached contents. Granted, the connection and subsequent caching only happened on a set interval but it was very unnecessary. We decided to cut out the middle-man (Feed Manager) and create a module which connects directly to a chosen Blog module and displays the posts. We went a step further by creating a Razor View Engine for this new module. Yes, you read that right, Razor. You can create Razor views to control the display of this new module.

To learn more about the Blog Post List module, head over to the documentation.

Blog Updates

We spent some time on the Blog and besides the wonderful new Razor-enabled Blog Post List, we have added Post Featured Image, Blog Featured Post, and automatic Meta Content creation for Facebook, Twitter, and Schema.org.

Post Featured Image

You can now easily add a featured image to each of your blog posts. This image will be used in the meta elements added to the page for Facebook, Twitter, and other social media outlets. The image is also treated a bit special by the Blog in that it is shown at the top of posts. More on the Post Featured Image.

Featured Post

This feature allows you to set a single post in your blog as "Featured". That post will always be at the top of the post list, even when using the Blog Post List module. More on the Blog Featured Post.

Automatic Meta Content Creation

Sharing posts on social media is a lot easier now because the special meta content markup that is necessary for sites like Twitter and Facebook to show correct titles and post images is now automatically added when you create a post. You can even edit the meta content that is created by editing the post and clicking the "Page Meta Data" tab (we're gonna change that to "Post Meta Data" in the next release).

Other Blog Updates

  • Added Display Settings for the Blog module to allow for easier skinning via CSS classes
  • Updated to actually move the blog navigation in markup instead of changing places with CSS * floats for easier styling
  • Cleaned up a lot of the default markup
  • Panels with no child elements will no longer be rendered
  • Added option to include comment body in comment notifications
  • Added SkinID="Blog" to CommentsWidget
  • Removed "Feed Links". These were links to old MSN, Yahoo and other defunct feed managers.
  • Added option to allow Post Title to be used as Page Heading when the PageHeading (or PageTitle) control is used in the layout.master for the skin

ASP.NET 4.6.2

mojoPortal now requires ASP.NET 4.6.2, which was released in August of 2016. Most hosting providers already support 4.6.2 so you should be fine upgrading your site. If your host doesn't support it and you purchase a hosting plan with i7MEDIA, we'll move your site for free.

TLS 1.2

mojoPortal will now enforce using TLS 1.2 for outgoing connections. This is important for connections to payment processors like Authorize.Net, WorldPay and PayPal.

Site Settings

The Site Settings page has a lot of options for configuring your site. We're actually working on moving more stuff from the web.config to the UI so it'll be easier to configure your site. Knowing that we are going to be adding even more to Site Settings, we implemented a few changes and reorganized some things to make using the Site Settings page easier. In the future, we plan on breaking this single page up into several smaller and more task oriented pages. In this release, you'll notice the following:

  • "Site Title" field moved to the General tab
  • "New Site" link removed (to add another site, go to Administration > Site List)
  • Skin options grouped on the General tab
  • Content Editor options grouped on the General tab
  • Registration options grouped on the Security > Main tab
  • User Account options grouped on the Security > Main tab
  • "Avatar System" option moved to User Account group under Security > Main tab
  • Password options grouped on the Security > Main tab
  • Security > OpenID tab renamed to "3rd Party Auth"
  • OpenID options grouped on the 3rd Party Auth tab
  • Windows Live options grouped on the 3rd Party Auth tab
  • "Host Name Mapping" and "Folder Name Mapping" moved to a single tab called "Site Mappings".
  • "SMTP Settings" tab renamed to "Mail Settings"
  • "Mail Settings" tab is always visible with information on how to enable the fields there. New sites will, by default, use this area for SMTP settings. You can enable this on your site by following the instructions here.
  • "Default Email From Address" and "Default Email From Alias" moved to "Mail Settings" tab
  • Reordered Recaptcha Site/Secret keys to match order on Recaptcha site
  • Added several contextual notes throughout the Site Settings page

Change Log

This change log isn't exhaustive because a lot of changes are already listed above. If we didn't list it above, it should be listed below.

Core

  • Updated mojoPortal to ASP.NET 4.6.2 and C# 7
  • Updated mojoPortal source code to use latest NuGet package management
  • Added RazorBridge method to allow use of MVC Razor Templating in Web Forms controls
  • Added MVC HTML Helper for internal Avatar and Gravatar use in Razor templates
  • Added Link control for inside/outside markup of the link
  • Added AutoEscapeStringForCsv method for exporting data in CSV format
  • Updated Gravatar in Forums to link to mojo user profile by default
  • Fixed File Manager/Page Picker for folder sites and sites running in a virtual directory
  • Moved First Name and Last Name fields to the General tab in the User Profile.
  • Added option to include comment body in notifications
  • Added ExportDynamicListToCSV method to ExportHelper
  • Added ImportHelper with GetDynamicListFromCSV method
  • Removed calls to jQueryFileTree and removed from ClientScripts
  • Removed calls to jQueryLayout
  • Removed call to greybox from Contact Form
  • Fixed possible XSS bug in help dialog
  • Removed WebStore from core (will be available as a separate download from the AddOn store)
  • Cleaned up user.config.sample file
  • Standardized on "Login" instead of "Sign In" (both were used before now)
  • Added Security Protocol information to "Security Advisor" (Administration > Security Advisor)
  • Added CombinePath method to DiskFileSystem file system provider.
  • Added FolderVirtualPath property to WebFile
  • Added NameProperty and ContentProperty to ContentMeta. This allows for creation of meta elements with custom names <meta property="foo" value="bar" /> instead of only allowing for <meta name="foo" content="bar" />

Skinning

  • Added FormGroupPanel control for settingrows to control their classes
  • Updated Site Settings page to use new FormGroupPanel control
  • Updated the Layout.Master.cs to expose SiteSettings (siteSettings), PageSettings (currentPage), isCmsPage and isMobileDevice to the Layout.Master for richer skinning functionality (Check out the layout.master in the Nature theme)
  • Updated CSSHander to allow for "https://" and non-http-specified ("//my-domain.com/") url calls
  • Updated Avatar.cs with new ExtraCssClass property
  • Cleaned up markup of CommentsWidget
  • Added themeable properties to CommentsWidget to help with skinning
  • Added themeable display settings for Contact Form
  • Cleaned up markup of the RelatedNewsletterSetting control
  • Cleaned up markup of HTMLCompare feature (used by version history)
  • Fixed Inline Editing in HTML Module for selecting files/images
  • Fixed CSSHandler for HTTPS URL calls
  • Fixed missing CKEditor Image2 Alignment Classes
  • Added InsideTopMarkup to replace LiteralExtraTopContent in BasePanel
  • Added InsideBottomMarkup to replace LiteralExtraBottomContent in BasePanel
  • Removed the .LESS CSS Utility from the Administration area. We recommend using a tool like Prepros for LESS management.

mojoPortal Is a Finalist in the 2010 CMS Awards

A big shout of thanks to the mojoPortal Community!

Thanks to your nominations, mojoPortal is a finalist in the 2010 Open Source Awards in the CMS Category.

Now the voting phase has begun and we need your vote! The voting phase goes from September 27, 2010 until November 5, 2010. Please take a moment and vote for mojoPortal! By voting, you also get a chance to win an Amazon Kindle.

https://www.packtpub.com/open-source-awards-home/vote-open-source-cms

Vote For mojoPortal in the 2010 CMS Awards

The competition is always tough in these awards, so every vote is important. We really need your vote!

 

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

mojoPortal 2.3.5.3 Released

mojoPortal 2.3.5.3 is now available on our download page.

This is another security update in follow up to version 2.3.5.2 which we released on Friday afternoon to address 2 mojoPortal specific security issues and it had some initial defense against a more general ASP.NET vulnerability the full details of which were released Friday afternoon at a security conference in Argentina. On Friday night Microsoft released information about the vulnerability and a workaround to help protect sites until Microsoft can provide a fix to the underlying problem. On Saturday morning I updated the post for version 2.3.5.2 with the workaround information.

Over the weekend we continued to review how best to protect mojoPortal and this morning we are releasing mojoPortal 2.3.5.3.

This release has the same fixes provided in version 2.3.5.2, but also has the Microsoft suggested workaround pre-applied. Additionally, we have added a new page in the Administration Menu that can detect a few common configuration issues that affect security and provide links to information about how to correct the configuration. If a serious configuration issue is detected, it shows an alert in the Administration Menu to bring it to your attention.

screen shot of security alert in the administration menu

Note that in a multi site installation this page is only available in the root administrative site.

I strongly advise everyone to upgrade as soon as possible if you haven't already.

There was also a bug introduced in version 2.3.5.2, the fix I had made for the FileService issue had caused an error in the page if using the alternate File Manager (which doesn't use the file service). This issue is fixed in version 2.3.5.3

Note that in this release I also commented out the PageNotFoundHandlerModule in Web.config. I'm not 100% sure this is needed but it is probably better to play it safe. The downside is that users who click bad links will not see the friendly page not found page but the generic error page. 

For more details see also:

UPDATE 2010-09-25

Scott Guthrie of Microsoft just posted about an additional protection that can and should be applied at the server level. If you have control of your own server you should take the additional step of installing UrlScan and configuring a rule as indicated in the article.

http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx

UPDATE 2010-10-04

The fix for the ASP.NET  security bug is now available in windows update. However, the change has a negative side effect for the current release of mojoPortal which may cause authenticated users to experience an error on your site. The error occurs when trying to decrypt the role cookie which was encrypted before the update was applied. Previously, if there was an error decrypting a role cookie, it was throwing a System.Security.Cryptography.CrypotgraphicException (which we were handling so the user would not experience any error). After the windows update it now throws a more generic HttpException which the current release does not handle so the user will see the error page, and the only way to solve it is to clear the cookie. I have added handling for the changed error for the next release of mojoPortal. There is one workaround you can do right away to solve this problem, you can add code to the ErrorPage.aspx in the root to clear the role cookie so that at least the user will only see the error page one time. To do this, edit the ErrorPage.aspx file with a text editor. At the top add this:

<%@ Import Namespace="mojoPortal.Business" %>
<%@ Import Namespace="mojoPortal.Business.WebHelpers" %>
<%@ Import Namespace="mojoPortal.Web" %>

then add this code to the bottom of the Page_Load event:

try
        {
            SiteSettings siteSettings = CacheHelper.GetCurrentSiteSettings();
            if (siteSettings != null)
            {
                string roleCookieName = SiteUtils.GetRoleCookieName(siteSettings);
                HttpCookie roleCookie = new HttpCookie(roleCookieName, string.Empty);
                roleCookie.HttpOnly = true;
                roleCookie.Path = "/";
                HttpContext.Current.Response.Cookies.Add(roleCookie);
            }
        }
        catch{}

 

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.

mojoPortal 2.3.5.2 Released

mojoPortal 2.3.5.2 is now available on our download page.

This is an important security and bug fix release. All users of mojoPortal are urged to upgrade as soon as possible.

Yesterday a security exploit bulletin identifying 2 security vulnerabilities in mojoPortal 2.3.4.3 was posted on the internet. I was able to verify the issues still exist as of version 2.3.5.1, so I immediately began working on a fix. You can see the information on this page: http://www.exploit-db.com/exploits/15018/ however it might be wise to disable javascript or use the NoScript Firefox plugin when visiting that page just out of respect for what these guys are capable of. When I view the source of the exploit information page it seems to have a lot of javascript. Possibly there is nothing malicious about the page but better to use caution just in case.

Issue #1

The first issue listed in the exploit bulletin was an issue in the file manager service where it was possible to target an admin with a social engineering attack to make him visit a malicious web site specifically targeting his site while he was logged in as admin and this would allow the attacker to run some javascript which would call the file service on the ADMIN user's mojoPortal site using the move command to rename the user.config file. If the attack was successful then the site would stop working the next time the application pool recycles because the user.config file is no longer there so it would not be able to find the connection string. From this it is described as a DOS (Denial of Service) attack because it could take the site offline. By renaming the user.config to something with an unprotected file extension like user.config.aaa the attacker could then download the user.config file and capture the database connection string and potentially other sensitive data that might be stored in user.config.

Mitigating Factors

  • if the site is configured as recommended with only the /App_Data and /Data folders being writable by the web process, this attack would not work because the web process would not be able to rename the user.config file in the root. So the site would have to be mis-configured for this exploit to work.
  • this requires a targeted social attack against a specific admin user and a specific site. The admin user would have to be tricked into visiting a malicious site while logged in as admin in his mojoPortal site for it to work, and the malicious site would have to be coded to target the specific mojoPortal site belonging to the user. Also javascript would have to be enabled. When I visit random sites from internet searches or links people send to me, I use Firefox with NoScript plugin, and I recommend you do the same.
  • if the site is actively monitored the Denial of Service would be corrected quickly

Issue # 2

There was a cross site scripting vulnerability on the public profile page /ProfileView.aspx where we were appending the user name/id into the page title without sanitizing it first. Since we were not enforcing any rules on user name/id by default other than it must be unique, a user could register with a specially crafted string to add an external script to the page. The script could be used for malicious purposes such as stealing the authentication cookie of a user who visited the infected user profile page. The fix for this involved both sanitizing the user name/id before we append it to the title and also adding some validation of user names /id when the user registers to prevent characters that can be used for this kind of exploit such as angle brackets.

Mitigating Factors

  • The user name/id is shown on the member list and is html encoded there so that no exploit is possible. It would be easy to spot a malicious user name/id on the member list and then edit the user profile and lock the account.
  • For several versions now we have had an optional config setting for entering a regular expression for user name/id validation. Sites that were already using this would not be affected since the user would not be able to enter the malicious user name.

Potential Issue # 3

This one was not from this exploit bulletin, and is not specific to mojoPortal, but could potentially affect millions of ASP.NET sites. This article was brought to my attention by a community member, George Birbilis. 
http://visualstudiomagazine.com/articles/2010/09/14/aspnet-security-hack.aspx

The full details of the vulnerability have not been posted yet so I'm not 100% sure whether it will affect mojoPortal or not. I will have to review it once the full details are posted. However from what I gathered so far, it sounds like a real issue that will affect a lot of sites. When I first read the article, I thought it was saying that the hacker would use error messages received from the server to crack the machine key and then they could forge a cookie to get administrative access to a site. If that is true then it is not as bad because by default no error details are sent from the server, there would only be sent the 500 status code which indicates an error. However from reading comments on a few other places it sounds like they do not in fact need any error details but can gradually decipher the machine key through a lot of requests just using the response status codes 200 (success) 404 (not found) and 500 (error). I took steps in this release in case that is how it works to help protect against this attack. Basically what I did was make it always return a 404 if there is a cryptography error. So if the theory is true that they need to see the 500 status code this solution may protect against it. We will have to wait for the full details to know for sure. As I understand it the full details will be released today at a security conference.

UPDATE 2010-09-18

Microsoft has posted a Security Advisory 2416728  on TechNet which says they are investigating this problem to provide an update. They also provide a workaround. The workaround is basically to use a custom error page so that no error details are returned from the server. We already have that by default in mojoPortal where we use error.htm as the default error page. The only difference in their workaround suggestion, is that they use a custom.aspx page to show the generic error instead of plain html, and they use some logic to make a random amount of time for the thread to sleep so that timing of the 500 status code cannot easily be used as an alternate to error details. I recommend that you copy the C# version of the error page they provide into a text file named ErrorPage.aspx, put it in the root of your web site, and edit the web.config as follows (this is also shown in the Microsoft article):

  1. wrap the entire <system.web section inside a location element <location allowOverride="false"></location> - this might cause an error in some installations, if it does just skip it and follow step 2.
  2. find this in your Web.config file:

    <customErrors mode="RemoteOnly" defaultRedirect="Error.htm">
          <error statusCode="413" redirect="~/NeatUpload/Error413.aspx"/>
        </customErrors>

    and change it like this:

    <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/ErrorPage.aspx">
       
      </customErrors>
     

That should help defend against possible attacks until an update is available from Microsoft. For more details to understand this problem, see http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx

You should also review the post installation check list to make sure you have configured your site securely.

UPDATE 2010-09-25

Scott Guthrie of Microsoft just posted about an additional protection that can and should be applied at the server level. If you have control of your own server you should take the additional step of installing UrlScan and configuring a rule as indicated in the article.

http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx

UPDATE 2010-10-04

The fix for the ASP.NET  security bug is now available in windows update. However, the change has a negative side effect for the current release of mojoPortal which may cause authenticated users to experience an error on your site. The error occurs when trying to decrypt the role cookie which was encrypted before the update was applied. Previously, if there was an error decrypting a role cookie, it was throwing a System.Security.Cryptography.CrypotgraphicException (which we were handling so the user would not experience any error). After the windows update it now throws a more generic HttpException which the current release does not handle so the user will see the error page, and the only way to solve it is to clear the cookie. I have added handling for the changed error for the next release of mojoPortal. There is one workaround you can do right away to solve this problem, you can add code to the ErrorPage.aspx in the root to clear the role cookie so that at least the user will only see the error page one time. To do this, edit the ErrorPage.aspx file with a text editor. At the top add this:

<%@ Import Namespace="mojoPortal.Business" %>
<%@ Import Namespace="mojoPortal.Business.WebHelpers" %>
<%@ Import Namespace="mojoPortal.Web" %>

then add this code to the bottom of the Page_Load event:

try
        {
            SiteSettings siteSettings = CacheHelper.GetCurrentSiteSettings();
            if (siteSettings != null)
            {
                string roleCookieName = SiteUtils.GetRoleCookieName(siteSettings);
                HttpCookie roleCookie = new HttpCookie(roleCookieName, string.Empty);
                roleCookie.HttpOnly = true;
                roleCookie.Path = "/";
                HttpContext.Current.Response.Cookies.Add(roleCookie);
            }
        }
        catch{}

 

Other Non Security Bug Fixes

  • fixed a long standing issue in the VirtualPathProvider that we use to serve the theme.skin file from the skin folder. For a long time this problem was not very noticeable because most skins did not have much variation in the theme.skin files, but more recently with our support for Artisteer we use settings in the them.skin file to control how markup is rendered so that we can add the needed markup for Artisteer and also the newer jQueryUI skin. The problem was that whatever skin was used first after the application startup, would have its theme.skin file cached and when pages with other skins were used it was getting the copy from the cache because the cache key was identical. Since the one in the cache may not have the correct settings then it could cause it to render incorrectly. The fix was to make sure they are uniquely cached. Note however that VirtualPathProvider does not work under medium trust in .NET 3.5 (it does work in 4.0), in that case all skins use the theme.skin file from App_Themes/default. For those in full trust or in .NET 4 hosting, you should see things work better in this release when using multiple skins or allowing user skins.
  • fixed an issue in folder based child sites where the canonical url rendered in the head was not correct, it was doubling the folder name.
  • fixed a bug where if using related sites mode, newly created sites were not correctly inheriting security settings from the parent site unitl you saved the parent site again and then it would propagate to the child sites.
  • fixed a bug where if using related sites mode, the admin and edit links were not shown consistently to site editors in child sites
  • fixed a bug where jquery script was disabled if you set the StyleSheetCombiner to not load jQuery UI
  • fixed a bug where the Superfish menu was not rendering the mouse over effects in .NET 4 - Thanks to Benedict for the solution!
  • fixed a bug where if FirstName and LastName were used as custom profile properties it was not loading them correctly
  • fixed a pgsql data layer error in the forums feature
  • fixed a SQL CE data layer error in the image gallery
  • added error handling to the feed manager so that if a feed is missing the required channel element it does not crash the page

 

Follow us on twitter or become a fan on Facebook

follow us on twitter become a fan on facebook

Gravatar Joe Audette is the founder of the mojoPortal project and was the primary developer until February 2017.