Bots submitting incomplete requests cause exceptions in Clai

Posted by Community Admin on 04-Aug-2018 17:39

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

All Replies

Posted by Community Admin on 01-Mar-2016 00:00

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!

This thread is closed