You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
System.Web.WebPages v.3.0.0.0:
Sometimes, more than one anti-forgery token is needed in a page (when there are multiple forms). Calling Html.AntiForgeryToken() causes the "X-Frame-Options: SAMEORIGIN" header to be emitted once per call. In extreme circumstances, this can lead to webserver/proxy malfunctions.
I encountered this issue on a page that uses the Anti-Forgery token within the row for each item in an index view.
The HTTP header was too large and MSIE aborted the connection when the list view was displaying roughly 500 records (selectable view size). Using Fiddler, I noticed the "X-Frame-Options: SAMEORIGIN" header was output for each call to Html.AntiForgeryToken(). The header wasn't output for like this when using Firefox and Chrome. In fact, it only seemed to be output when using MSIE. I was able to change the User Agent in Firefox and Chrome to identify itself as MSIE which reproduced the issue.
I realize there is more than one way to do things, but rather than rewrite the implementation in that view, I came up with a temporary workaround. For each Html.AntiForgeryToken() call made in the list loop. I removed the header eg:
- #7
* According to RFC7034, only these three values, DENY, SAMEORIGIN and ALLOW FROM are valid values and they are mutually exclusive; that is, the header field must be set to exactly ONE of these three values. This will prevent the CSRF code from inserting it multiple times as well as duplicating it if it was already set elsewhere (e.g. IIS Header)
* Changed var to const string per request.
* Changed const name to avoid SA130 error
* Changing to correct cost naming per standard
Original bug: https://aspnetwebstack.codeplex.com/workitem/2057
The text was updated successfully, but these errors were encountered: