Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Small issues with 4.8.4Small issues with 4.8.4
Previous
 
Next
New Post
6/16/2008 12:37 PM
 

Starting with DNN 4.8.3 source distribution, I changed only the two lines mentioned in issue DNN-7785 and rebuilt. Here's the procedure I used:

  1. Started a new site in IIS, created an empty DB, and went through the installer
  2. Enabled HumanFriendly URLs in the web.config
  3. As host, created a new page named "YetAnotherPage"
  4. As anonymous, navigated to
    http://localhost/YetAnotherPage.aspx
  5. Clicked "Login"; the URL bar reads
    http://localhost/Login.aspx?ReturnUrl=%2fYetAnotherPage.aspx
  6. Entered host credentials; after login the URL bar reads
    http://localhost/YetAnotherPage.aspx?runningDefault=2

I'm going to download the source for 4.8.4 and diff the HttpModules code against 4.8.3 to see if there were any other changes.

Does anyone know of any changes to the authentication code between 4.8.3 and 4.8.4 that might account for what Chris is seeing?

Ed

 
New Post
6/16/2008 2:39 PM
 

During the post back after you click on "Login", HttpContext.Current.Request.RawUrl has the value

  • In 4.8.3, "/YetAnotherPage.aspx"
  • In 4.8.4, "/Default.aspx?TabID=54"

This value is being included directly as the "returnurl" query parameter value (see DotNetNuke_04.08.04_Source\Website\admin\Skins\Login.ascx.vb lines 117-140).

 

 
New Post
6/16/2008 3:12 PM
 

I'm pretty sure this change in behavior affects all post-backs.  I think it is caused by the change to DotNetNuke_04.08.04_Source\Library\Components\Shared\ActionLessForm.vb line 44

4.8.3:
html = html.Insert(StartPoint, "action=""" & objSecurity.InputFilter(
    HttpContext.Current.Request.RawUrl,
    PortalSecurity.FilterFlag.NoScripting Or 
    PortalSecurity.FilterFlag.NoAngleBrackets Or 
    PortalSecurity.FilterFlag.NoMarkup) 
    & """")
4.8.4:
html = html.Insert(StartPoint, "action=""" & objSecurity.InputFilter(
    DirectCast(DirectCast(HttpContext.Current.Request, System.Web.HttpRequest).Url, System.Uri).PathAndQuery,
    PortalSecurity.FilterFlag.NoScripting Or 
    PortalSecurity.FilterFlag.NoAngleBrackets Or 
    PortalSecurity.FilterFlag.NoMarkup) 
    & """")
I don't know what the motivation for that change was, so I'm reluctant to suggest a change.
 
New Post
6/16/2008 3:46 PM
 

thanks Esv, I appreciate you tracking this down. FYI that change was necessary to resolve this issue http://www.dotnetnuke.com/News/SecurityPolicy/SecurityBulletinno19/tabid/1166/Default.aspx

With the original code, Request.RawUrl returned the exact path, whether or not it was valid i.e. a path like this is invalid, but by using particular encodings, and duplicating the .aspx endings, it was possible to inject XSS code into the actionlessform

http://[SITEURL]/Default.aspx/encoded-javascript-here;.aspx 

When using PathAndQuery, it correctly extracts the only valid part of the URL i.e.

http://[SITEURL]/Default.aspx

As my test setup was not running friendly URL's I did not realise that PathAndQuery was not picking up the contextual rewritten path correctly, but was echoing the "true" path i.e. an unwritten url. Whilst this doesn't break any functionality, it does mean that postbacks will not be rewritten correctly for friendurl's. I will setup a new environment and see if theres a setting that can extract valid paths whilst preserving rewritten url's.

Cathal


Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
 
New Post
6/16/2008 5:09 PM
 

Great job you guys are doing ... but I think a warning to everybody using DotnetNuke in SEO environment should be good ..... I mean if SEO users would download DotNetNuke today they would very much like to use DNN 4.8.3 instead of than 4.8.4 if they knew about this issue..... a question: should the 4.8.4 be redrawn from download or what do you guys think?

/Johan

www.evolvia.se

 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...Small issues with 4.8.4Small issues with 4.8.4


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out