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()

The forums are in read-only mode. In case that you want to directly contact the Progress Sitefinity team use the support center. In our Google Plus group you can find more than one thousand Sitefinity developers discussing different topics. For the Stack Overflow threads don’t forget to use the “Sitefinity” tag.
1 posts, 0 answered
  1. Scott
    Scott avatar
    3 posts
    Registered:
    11 Dec 2014
    01 Mar 2016
    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