Checkmarx is complaining about an XSRF issue in our web application. We are using ASP.NET web forms with framework 4.0 (not MVC)
Checkmarx said: Method btnSubmit_Click at line 1760 of \ABC.aspx.vb gets a parameter from a user request URL from element text. This parameter value flows through the code and is eventually used to modify database contents. The application does not require renewed user authentication for the request. This may enable Cross-Site Request Forgery (XSRF).
Any idea of how to prevent XSRF from ASP.NET Webform application?
We have tried a lot of solutions but none of them pass Checkmarx:
Here are some things we tried:
https://software-security.sans.org/developer-how-to/developer-guide-csrf
or
http://willseitz-code.blogspot.com/2013/06/cross-site-request-forgery-for-web-forms.html?m=1
or
https://security.stackexchange.com/questions/187740/two-solutions-for-csrf-on-owasp-for-asp-net-webforms
I think the solutions above should work and protect/prevent our web form from CSRF/XSRF risks, but why can Checkmarx not detect it? Is this a false positive?
It is recommend to check the CxQL queries from Checkmarx Portal (Settings/Scan Settings/Query Viewer) to understand how Checkmarx find a vulnerability, including what kind of protection that Checkmarx is able to detect.
For your case, check the logic in CSharp/Cx/CSharp_Medium_Threat/XSRF.
For Web Form Applications, the query CSharp/Cx/General/Find_XSRF_Sanitize is used to find if you have done any protection in your application.
As the comment of Find_XSRF_Sanitize said:
For ASP Web Forms, the main solution to prevent XSRF attacks is to
assign a unique token to the ViewStateUserKey property of the page.
Also
AntiXsrfTokenKey
is also considered a protection.
If you use ViewStateUserKey or AntiXsrfTokenKey, all the http interactive requests that are defined in the same method as the ViewStateUserKey or AntiXsrfTokenKey will be considered as sanitized request, and will be removed for the potential tainted request list.
Note that in the CxDOM tree, ViewStateUserKey and the sanitized request have common ancestor, which is the method declaration.
Related
I am working on a legacy Application which has some cross site scripting - reflected issues when we take the input from query string. The issues are being reported by Fortify code scan (WebInspect) tool.
For example:
I have a page called ProgressDisplay.aspx which takes reportPath as a query string parameter.
/ReportViewer/ProgressDisplay.aspx?reportPath=%27%3b%61%6c%65%72%74%28%35%36%36%34%35%29%2f%2f
In the above code reportPath is a query string parameter where the malicious payload is being passed which shows an alert in the response.
Above payload becomes alert(56645) after rendering.
Like this, there are several similar issues are being reported. Is there any centralized approach to fix all the issues at one shot by using any ASP .Net library Or making some changes in the config instead of fixing each issue Or I'll have to fix all the issue one by one?
After the fix, the page shouldn't return the response as 200 when a malicious script is inserted. We have to return a Bad Request in response.
Use below recommendation to avoid Cross site scripting attack in Microsoft.NET Language :
URL Encoding : It prevent malicious script from being injected into a URL.
Not: You can use Microsoft Web Protection Library (WPL) to avoid all xss-Reflected issues.
eg: <a href=<%# Microsoft.Security.Application.Encoder.UrlEncode(TEST.Url) %>>View Details</a>
Enabling a Content Security Policy (CSP)
Validated Input data:Input data should be validated Before execute.
XSS- Microsoft.NET
Encode data on output
I'm reviewing the security of an ASP.NET website that is about 7 years old. At the time the site was created the Microsoft guidance was to add the following to a common Base Page (inherited by all code behind pages):
Protected Overrides Sub OnInit(ByVal e As System.EventArgs)
MyBase.OnInit(e)
If Request.IsSecureConnection = True Then
ViewStateUserKey = Session.SessionID
End If
End Sub
This advice comes from the following MSDN Article from 2005.
My question is if this is still a valid and effective technique to protect against CSRF attacks.
Note, I read an SO question about this topic, but it appears the Visual Studio 2012+ project auto generated protection for CSRF are added to Master Pages. The site I'm reviewing doesn't use Master Pages because of CSS conflicts, and it is not in scope to add Master Pages into the current update.
Yes, this will mitigate CSRF if ViewStateMac is enabled.
This is because each individual user will have the ViewState authenticated by their own key (which is session ID).
As the ViewState is POSTed back to the server upon every request that has side-effects, ASP.NET will validate that the ViewState value is in fact from the current user.
Therefore any attacker cannot construct a POST request to entice their victim to submit because they do not have their victim's session ID in order to do this.
Note that the above assumes that all requests that have side-effects are done via postbacks. That is, the application is following RFC 7231 in regards to the definition of "safe" methods and there are no other handlers for POST requests other than the postback mechanism.
Note that any custom AJAX requests in the application, such as those made by JQuery will not be protected from CSRF because these are not implemented as postbacks.
Setting and checking a custom header for these is recommended, like X-Requested-With. Note that due to various Flash vulnerabilities, you may want to also pass a token into the header to check server-side.
There was a weird issue yesterday about asp.net's outputcaching (webforms). We were using page-level caching (not partial caching) for a multi-lingual site (language is determined via querystring key) and for some purpose, caching stopped working for some languages. I kept track of GetVaryByCustomString method of Global.asax file but, it didnt worked. I will give more details in answer...
Perhaps you need to set the Shareable attribute on your cookies to true?
If a given HttpResponse contains one or more outbound cookies with
Shareable is set to false (the default value), output caching will be
suppressed for the response. This prevents cookies that contain
potentially sensitive information from being cached in the response
and sent to multiple clients. To allow a response containing cookies
to be cached, configure caching normally for the response, such as
using the OutputCache directive or MVC's [OutputCache] attribute, and
set all outbound cookies to have Shareable set to true.
https://msdn.microsoft.com/en-us/library/system.web.httpcookie.shareable(v=vs.110).aspx
Thanks to subversion, i kept track of recent commits. We made a mechanism allowing specific users to view some languages that have not been published yet, using cookies instead of session variables. This was the cause of problem. If a request comes to a language which is not the default language, this mechanism checks whether it should allow user to view page. And IMHO if you modify response's cookie collection, asp.net disables outputcache for that request. I tested it and it really disables cache if you add a cookie to response.
I have a web application where I have used http-handlers and jQuery for AJAX call.
Now the problem is user can type the same URL in the browser which is generated by the jQuery and operation is being performed.
Can I send some token with the query string and then on server side I can look for the right token before performing any operation.
Hope that I have written my problem correctly.
You may need to handle this in a similar fashion to how it can be handled in the MVC framework. Here is a similar post that describes a potential solution.
The above technique is called
Cross Site Request Forgery
Risk Impact
An attacker can hijack logged in users session for performing malicious transactions.
Recommendations
It is recommended implementing Page token (a random token as an additional parameter in the request) for all transaction pages. This token should be randomly generated and should be unique for each user.
The suggested URL are
http://www.owasp.org/index.php/CSRF_Guard
http://www.cgisecurity.com/csrf-faq.html
var cg = new CSRFGuard();
cg.SetupCSRFTokenNameAndValue();
SessionManager.CustomerConfig.CsrfTokenName = cg.CsrfTokenName;
SessionManager.CustomerConfig.CsrfTokenValue = cg.CsrfTokenValue;
Thanks a lot.
I have many Ajax.ActionLink's on my ASP.NET MVC (v1) page that perform destructive operations. This is "legal" because I set HttpMethod to DELETE in this case so it's not a destructive GET.
My question though is how to mitigate XSRF attacks on this operation so that other sites cannot craft this same Ajax DELETE request to delete user data from another site. This ActionLink does appear within a form that includes <%= Html.AntiForgeryToken() %> but since ActionLinks don't post the form, the anti-forgery token doesn't go to the controller, so it can't validate it.
To prevent against Cross-Site Request Forgery attacks you must block requests that originate from another site. In asp.net you can do this by checking to see if Request.UrlReferrer isn't from your host name. If the ajax request originated from a different server, then you should ignore the ajax request. If the referrer is null, then you should also ignore the request.
This link covers one solution http://tpeczek.com/2010/05/using-antiforgerytoken-with-other-verbs.html
However the most ideal solution is that when you use the actionlink it adds the Anti Forgery token into the query string so I'm going to try writing my own ActionLink extension method that appends that on.
Finally I'm going to write an attribute that inherits from the ValidateAntiForgeryTokenAttribute and that accepts forgery tokens in both the Request.Form and Request.QueryString