We currently had a security company do a intrusion test on our web application, based on DotNetNuke, and one issue that was reported was regarding "Cross site request forgery" (http://www.dotnetnuke.com/Resources/W...). Apparently, they said the could still do it in DNN 5.6.3, even though this was supposed to have been fixed in DNN by adding the following to page_init:

'add viewstateuserkey to protect against CSRF attacks
            If User.Identity.IsAuthenticated Then
                ViewStateUserKey = User.Identity.Name
            End If

When looking around on the internet regarding this, I've seen that most other corrections for this seem to be based on

ViewStateUserKey = Session.SessionID;

rather than:

ViewStateUserKey = User.Identity.Name

and having looked in the debugger, we've seen that they do not contain the same information (SessionID should be unique to the session, while UserName is unique to the user but not the session).

Is this difference any reason to be concerned? Also, we only looked at the Page_Init in Default.aspx.vb, do we need to implement anything in our modules with regards to this?

 Thanks for your quick reply.

So will the solution implemented protect against the "one click attack" described in your second link? It should be mentioned that we currently have a discussion with the company doing the intrusion tests regarding if this test was actually successful (ie could be exploited) or not, as they might have done a test that wasn't actually using ViewState at all. But if it was, then that should most likely mean that DNN 5.6.3 is not secure from one click attacks, how concerned should we be about this?

 Yes, as you mention and I also wrote in the subject, CSRF is the correct therm to use.

When you say default in DotNetNuke, I assume you mean fresh installations? As many other users I would assume, our installation is a summary of several upgrades, and thus web.config might not be exactly as in a fresh release of the latest versions. What are the settings to look for and verify here?

The CSRF attack used in the testcase was to fake the user into going to another site which then where able to send a "command" to our site which made the user logout, or rather being logged out (the user was logged in before). I've asked for more information about this to determin if the test case was not correct, or if the CSRF fix in DNN wasn't working as it should.