What are security issues in asp.net mvc?! and does MVC solved XSS and the others?!
As jfar says: watch out for SQL injection. :-)
It helps by allowing you to use some specific pieces, but you still have to use them in appropriate places.
Use the new default <%: that Html Encodes the output
Use the anti forgery request token
Use Any of the provided data access solutions. At the lowest possible level, use .Parameters to pass parameters
Pay attention to every bit of guidance
don't dismiss security advisory published, as the recent one affecting asp.net in general: is-asp-net-mvc-vulnerable-to-the-oracle-padding-attack
You still have to understand & question the security aspects.
The same as any other website. Just like any other language or framework Sql Injection and Request Forgery are only solved if you implement measures to prevent it. XSS is solved only if you don't need to accept HTML input and disable XSS validation.
Don't get soft thinking MS provided all the answers. It still takes a keen eye for flaws and a rigid application of counter measures to keep things secure.
Related
I was told that there is no need to put the ValidateAntiForgery mechanism on our razor form because it's not behind authentication and is totally open to the public.
I thought I read somewhere that it should be used on all POSTs.
Which is correct?
There are a number of articles which can tell you when and where it is most appropriate to use the AntiForgeryToken. Here's a few:
http://www.devcurry.com/2013/01/what-is-antiforgerytoken-and-why-do-i.html
http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
http://peterkellner.net/2014/05/19/asp-net-mvc-forms-need-include-html-antiforgerytoken-security/
The last one is explicit, the author recommends that you should use the feature for all forms. It will be generally beneficial to your entire website, provided that you care about the identity of your users.
If your users have no session, and there is nothing to be gained from hijacking their ASP.NET cookie, then the anti forgery token is not particularly useful.
VS2013, MVC, VB
I'm asking this question now because much time has passed since most of the posts that I read about XSS protection.
In the spirit of SO, my technical question is if someone can confirm that Microsoft's HtmlAgilityPack does not really do what AntiXSS does. I've read posts where people suggested that AntiXSS has problems, so they used htmlAgilityPack, but then the posts, including on SO, that state clearly they are not the same tool. That AntiXSS is what one would use for XSS protection.
If someone could clarify that I'd appreciate it.
A second, and not intended to be asking an opinion question per se, is to ask if the problems previously claimed against AntiXSS are by and large solved and is that the right tool to use for XSS protection when using MVC.
My intent is to use a whitelist approach for XSS protection.
Followed the guidance from this post as a basis for coding a whitelist filter using the html agility pack. The link shows a function used in a web pages approach, but the basic algorithm works fine coded in the controller of an MVC project to sanitize input from an RTF/WSIWYG editor (CKEditor)
I've got a news-feed style field which admins can edit that will appear on users' pages. All users and all admins are approved so this is a pretty low-security affair.
Is there a simple, built-in way to validate their input for malicious script injection?
Microsoft Web Protection Library: http://wpl.codeplex.com/
It's not built-in, but it's highly regarded and built for ASP.NET
Unfortunately, I don't think there is anything out there that is both simple and mature - at the moment. You can give OWASP Enterprise Security API a try, but you'll unlikely be any happier than with WPL.
I'd recommend adhering to the OWASP XSS guidelines, but I suspect you're already familiar.
I've read from a few individuals (Simone Chiaretta, Sebastien Lambla) that "you should remove the AccountController" from your ASP.NET MVC apps, but without much reason. I'm currently using it in one intranet site and am working on a second that will be considerably more widely used. What is wrong/bad about the default code that makes it undesirable?
Simone elaborates in comments. I have to disagree with him a little, though. Correctly implementing an authorization filter is not "easy." The first MVC previews got it wrong! In general, nothing which touches the area of security is "easy." However, the criticism of coupling is valid. Even if you use forms auth -- and you probably should use some off-the-shelf authentication if you're not a security expert -- the coupling is bad.
Here are some the commonly known practices for securing an MVC application:
Encode your output
Parameterize your SQL
Test your search backwards and forward
1 way hash passwords
Lock out accounts or limit login attempts
Use code based impersonation when accessing the file system
Access SQL with a locked down username
Use Honey-pots or captchas for form submissions to counter bots
If there are any I missed or misstated please feel free to contribute.
What other techniques/best practices do you use or think about when pen testing your own software. What do you do to "kick the tires" before taking a applications live.
What pen testing services or software do you use if any?
All methods that use modelbinding should be secured with whitelists or blacklists on bindable properties.
string[] allowedProperties = new[]{ "Title", "Description"};
UpdateModel(myObject, allowedProperties);
or
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create([Bind(Include="Title,Description")] MyObject object )
{
}
This is of course to prevent crafted requests from attempting to update/manipulate your objects in ways that weren't intended.
Your list is good, although it is a bit vague. For instance md4 is a one way hash, but its extremely insecure as i can generate a collision on my desktop in less than a day. sha256 with a large salt value is a more secure approach. (I know even this is description incomplete, don't flame)
There is never a catch all security check list that will work across the board. Specific applications can have specific vulnerabilities. Sometimes these flaws can be logic errors that really don't have a classification.
The OWASP Top 10 web application vulnerabilities is an excellent resource that you should study. Most notably you are missing XSRF on your list which can be a devastating attack. There are a large number of "sink" based attacks which you have not listed. For instance what if an attacker could pass in a path of his choice to fopen? A Study In Scarlet goes over many of these attacks against PHP.
All of your suggestions apply to any web application, not just MVC applications.
An MVC-specific suggestions would be something like "skinny controllers, fat models".