CSRF attack detected on live site when using Smart Search

jeff McDaniel asked on April 4, 2017 19:43

Hi all,

I recently set up a Smart Search box on my live site so users can search from the root page and it is inherited across the site. It works successfully in the Kentico back end (when I search for something through the pages application for example).

However, the live site seems to think me searching something is a CSRF attack. Searching anything on any page in my site crashes the site and comes back with a server error in '/' application. The event log shows the below error message that a CSRF attack was detected.

Message: CSRF attack detected.

Exception type: CMS.Protection.Web.UI.CsrfException
Stack trace: 
at CMS.Protection.Web.UI.CsrfProtection.ValidateCsrfTokens(Byte[] cookieToken, Byte[] hiddenFieldToken)
at CMS.Protection.Web.UI.CsrfProtection.OnPostMapRequestHandlerExecute(Object sender, EventArgs eventArgs)
at CMS.Base.AbstractHandler.CallEventHandler[TArgs](EventHandler`1 h, TArgs e)
at CMS.Base.AbstractHandler.Raise[TArgs](String partName, List`1 list, TArgs e, Boolean important)
at CMS.Base.SimpleHandler`2.RaiseExecute(TArgs e)
at CMS.Base.SimpleHandler`2.RaiseExecute(TArgs e)
at CMS.Base.SimpleHandler`2.StartEvent(TArgs e)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

I don't have the best background with network security, but I've read that CSRF attacks come from the ViewState. I noticed that in the layout tab for the Smart Search Box Web part there is a EnableViewState="false" attribute in each line. I figured that would make CSRF attacks not possible and search trusted since the ViewState is not enabled. This is a brand new site I've set up, although on the same instance where search works fine for other sites, but it is possible I missed something I needed to set up.

Is there something special I have to set to allow the site to trust activities such as search? What would be the difference between the live site seeing this attacks and the Kentico backend not seeing the same?

I always appreciate any answers or suggestions from the community that helps me become a better understand Kentico and become a better developer.

Thanks, Jeff

Correct Answer

jeff McDaniel answered on April 10, 2017 22:24

Hi Michael and anyone else who may have this issue.

I have figured it out. The search was not working when the site was using http but worked okay when using https.

I'm not sure why it thought a CSRF attack was happening on http, but my fix was to always force https on my server (which I should have been doing anyway)

Thanks

Jeff

0 votesVote for this answer Unmark Correct answer

Recent Answers

Trevor Fayas answered on April 4, 2017 23:34

Ran into this with another site that had a CDN attached, the postback from the CDN site caused the CFR attack to trigger. I ended up disabling it completely with this web.config key:

<add key="CMSEnableCsrfProtection" value="false" />

Like i said though, mine was unavoidable because it was a CDN posting to the origin server, and that is kind of what a "CSRF" is suppose to look like, except this was okay and not malicious. If anyone else wants to chime in, feel free!

0 votesVote for this answer Mark as a Correct answer

Michal Samuhel answered on April 5, 2017 08:55

Hi Jeff,

A bit of theory at first: "Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.(https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF))"

Viewstate in ASP.NET actually complicates these attacks making manipulation more complicated. If ViewState is enabled, you cannot send tampered POST requests to an ASP.NET application because validation of ViewState fails.

I suggest you take a look at explanation of our protection implementation at:

https://docs.kentico.com/k10/securing-websites/developing-secure-websites/cross-site-request-forgery-csrf-xsrf https://devnet.kentico.com/articles/protection-against-cross-site-request-forgery-(csrf-xsrf)

Shortly speaking we are protecting the requests by validating each post to the site by a cookie and hidden field security tokens. Cookie stored with user is validated against page hidden field on each post request. Currently we validated all post requests coming to any page that inherits from abstract CMSPage.

Since search is a post action (you are posting search text to page), this causes protection to trigger. Usual case is that the post request does not contain the cookie (e.g. cookie is not created for public user), or there is another page reload or other action, that would break tokens pairing.

First and usual case are cookie issues and there was a hotfix for this that ensured that CSRF cookie is an system cookie (9.0.44). Otherwise you can try inspecting request headers, if cookie value is part of the request and maybe check network tab in browser console to see how the is the request handled(there might be network interference, redirect...)

One note for Trevor, unfortunately we can not control posts from 3rd parties, nor can we force them to send us some headers or other validation means so this creates a slight issue with situation like yours. Since v10.03 there is a workaround to disable CSRF on page level, but is available only with changes to page template:

https://devnet.kentico.com/articles/payment-gateways-and-csrf-protection

HTTPHandlers are not part of this protection mechanisms so in general they are best to handle posts from 3rd parties (unfortunately, it would be hard to set in your specific case with CDN)

1 votesVote for this answer Mark as a Correct answer

Trevor Fayas answered on April 5, 2017 15:36

I learned something new! i'll have to look into the page-level disabling instead of across the board when we upgrade them to 10.

0 votesVote for this answer Mark as a Correct answer

jeff McDaniel answered on April 6, 2017 19:58

Hi Michael,

That is good information. I'll check out the headers on the cookie. If it was the case that the cookie's headers were mismatched, how would I be able to fix that?

Jeff

0 votesVote for this answer Mark as a Correct answer

Michal Samuhel answered on April 7, 2017 11:01

Hi Jeff,

Error in stack trace suggests, that cookie is should be present as part of post message, but token values does not match, but still checking that cookie exists and is part of POST request is better.

As cookie should be set on Get while page is requested by client this should not be changed. So it would mean that the page might have been reloaded or altered by other requests, changing the hidden field value.

0 votesVote for this answer Mark as a Correct answer