Try Now
More in this section

Forums / Bugs & Issues / Bots submitting incomplete requests cause exceptions in ClaimsManager.ValidateUser()

Bots submitting incomplete requests cause exceptions in ClaimsManager.ValidateUser()

1 posts, 0 answered
  1. Scott
    Scott avatar
    3 posts
    11 Dec 2014
    01 Mar
    Link to this post

    I have a brand new Sitefinity 8 site I just created with basically all default settings, and I'm seeing bots submit requests that are causing the application to crash with the message:

    ArgumentNullException: Value cannot be null.

    at Telerik.Sitefinity.Security.Claims.ClaimsManager.ValidateUser(String username, String password)
    at Telerik.Sitefinity.Security.Claims.ClaimsManager.TryParseBasicAuth(NameValueCollection values, User& user)
    at Telerik.Sitefinity.Security.Claims.SitefinityClaimsAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
    at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

    I tracked down the issue by dumping the full request headers from the bad attempts, and it appears to be caused by the line "Authorization: Og==" but without any username/password headers being passed. 

    To reproduce the issue, I used Fiddler to compose a request with the following headers and tried with https://www.hurl.it/  by just adding a manual header of "Authorization: Og==".

    Cache-Control: no-cache
    Pragma: no-cache
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
    Accept-Encoding: gzip,deflate, identity
    Accept-Language: en-us,en;q=0.5
    Authorization: Basic Og==
    Host: www.mysite.com
    Referer: https://www.somesite.com/
    User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 Firefox/1.0.4 (Ubuntu package 1.0.7)

    For my setup, the security settings are all default except we've added a new membership provider for LDAP users (the same as the original LDAPUsers provider) and set the DefaultBackendMembershipProvider=our new one.  That shouldn't have any impact on the public setup at all though.

    Any idea how to make this type of bad request go through as normal?  I need to prevent it from crashing, and without knowing the cause I'm worried there may be other related issues or vulnerabilities as well.  Thanks!

1 posts, 0 answered