Regarding CSRF

DVS Developers asked on August 21, 2015 11:55


Recently our Acunetix software reported CSRF vulnerability in couple of pages which are developed using Kentico portal engine (Pages contain online forms). we tried to fix the issue with the help of available doc's

In Web.Config we have this configuration to fix CSRF

<machineKey validationKey="***********" decryptionKey="***************" validation="SHA1" decryption="AES" /><pages buffer="true" enableSessionState="true" enableViewState="true" enableViewStateMac="true" viewStateEncryptionMode="Always" validateRequest="false" clientIDMode="AutoID">

But unfortunately the suggested fix in doc's did not help us to fix the CSRF issue. So please suggest us what to do?


Recent Answers

Roman Koníček answered on August 21, 2015 12:43


I would also recommend to check the following article on DevNet regarding the CSRF -

The key information is that the protection is applied to all pages which inherit from CMSPage or AbstractCMSPage. Could you please clarify that this is true in your case? Also could you please double check that you are not using the following key in your web.config file < add key="CMSUseViewStateUserKey" value="false" /> ?


Best regards, Roman Konicek

0 votesVote for this answer Mark as a Correct answer

DVS Developers answered on August 21, 2015 15:30


We appreciate kentico taking CSRF seriously and introducing tokens in kentico version 9. The pages are designed using portal engine so we are thinking those pages are already inherited from CMSPage or AbstractCMSPage. The CMSUseViewStateUserKey does not exist in the web.config so we added it and set the Value to true and scanned it through Acunetix it is still reporting about CSRF. Any suggestions?


0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on August 21, 2015 18:48

What are the warnings you're receiving about CSRF on your Acunetix report?

0 votesVote for this answer Mark as a Correct answer

DVS Developers answered on August 24, 2015 09:56

Warning message: HTML form without CSRF protection

The form was designed using kentico app online form which is a simple form contains a Email text box and a submit button for subscription to newsletters.

Note: A validation rule already placed on Email text box saying only Emails are allowed to submit.

0 votesVote for this answer Mark as a Correct answer

Juraj Komlosi answered on August 26, 2015 10:43


in that case you can mark it as a false positive. Web application scanners look for some keywords in request/response to figure out if the website is vulnerable to CSRF or not. Typically it is CSRF hidden field, CSRF request header or CSRF cookie. If nothing is found the scanner marks it as CSRF vulnerable. Since we use ViewState as a CSRF protection, Acunetix is not able to verify if the website is vulnerable or not.

This false positive reported by Acunetix should be removed in Kentico 9.

Best regards.

0 votesVote for this answer Mark as a Correct answer

Mital Patel answered on March 23, 2017 15:03

Hi Juraj ,

As per your above answer , Is Acunetix scanner only search for "CSRF" keyword in request name parameter?

Example ,

<input type="hidden" name="csrf" value="bvjkdfh56757bfvh%jhdfusdfu6786d7d7d7d7d=="/>

  • this is getting successfully passed from CSRF attack.

<input type="hidden" name="tokenName" value="bvjkdfh56757bfvh%jhdfusdfu6786d7d7d7d7d=="/>

  • this is not getting passed from CSRF attack. Acunetix show this as a false positive attack type.

So that means Acunetix tool is only looking for "CSRF" keyword , and also it is not validating by attacking such form.

This is what I understood , please correct me if I am wrong and give your suggestion.

0 votesVote for this answer Mark as a Correct answer

Juraj Komlosi answered on March 24, 2017 09:26

Hi Mital,

I asked Acunetix support for help to be sure how Acunetix detects CSRF vulnerability. Here are the exact steps how does it work:


  • Acunetix has a crawler module that is searching for forms that don't have an CSRF token by looking for hidden input forms that meet some criteria list (based on input name and value). If a form without a CSRF token is found it is reported.


  • It first invalidates the session by deleting all cookies and then runs the Login Sequence again (to login again). Then it compares the response body with the previous response body (the one retrieved with the initial cookies). If the same response body (with 2 different set of cookies) is returned, the test would issues an alert that this request could be possible vulnerable to CSRF.
  • It works only if a scan is being run with a Login Sequence.
  • Only POST requests are validated.

Keep in mind that there is no foolproof way of automatically verifying a CSRF vulnerability, and therefore it is highly recommended that any CSRF alerts are manually verified since, in either case, identifying if forms should have CSRF protection is something that obviously requires some form of human intelligence.

Hope it helps.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.