Aware of while developing an secure ASP.NET MVC application
- CSRF(Cross Site Request Forgery)
Windows Authentication Provider :
Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications.
Forns Authentication Provider:
Provides information on how to create an application-specific login form and perform authentication using your own code. A convenient way to work with forms authentication is to use ASP.NET membership and ASP.NET login controls, which together provide a way to collect user credentials, authenticate them, and manage them, using little or no code. For more information
The authorize attribute also allows you to set some parameters to enforce authorization rules. First we need to know the user’s identity and then we can say only the specific identities to allow accessing these actions.
Authorize attribute also allows you to specify the Roles. In Windows Authentication by default map to Windows groups on server or groups configured in the active directory. You can put roles like below
In Forms Authentication ASP.NET has a role provider. By using these you can store, manage roles in a SqlServer database. These can configured in the application by default.The easiest way to do that is use the below button in the solution explorer
It launches ASP.NET configuration tool .This is the tool you are only going use in the local development machine. It’s going to look in the web.config location and use the same application services database as that Form Authentication provider of using that is already configured inside of there. You can add , manage roles from here. While doing these it automatically map to db we are configured in the web.config file.
Given the way browsers parse HTML, each of the different types of slots has slightly different security rules. When you put untrusted data into these slots, you need to take certain steps to make sure that the data does not break out of that slot into a context that allows code execution. In a way, this approach treats an HTML document like a parameterized database query – the data is kept in specific places and is isolated from code contexts with escaping.
This document sets out the most common types of slots and the rules for putting untrusted data into them safely. Based on the various specifications, known XSS vectors, and a great deal of manual testing with all the popular browsers, we have determined that the rule proposed here are safe.
<%@ Page Language=”C#” AutoEventWireup=”true” CodeFile=”Default.aspx.cs” Inherits=”_Default” ValidateRequest=”false” %>
Cross-Site Request Forgery
A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target destination without their knowledge or intent in order to perform an action as the victim. The underlying cause is application functionality using predictable URL/form actions in a repeatable way. The nature of the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting (XSS)  exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session riding, confused deputy, and sea surf.
CSRF attacks are effective in a number of situations, including:
- The victim has an active session on the target site.
- The victim is authenticated via HTTP auth on the target site.
- The victim is on the same local network as the target site.
CSRF has primarily been used to perform an action against a target site using the victim’s privileges, but recent techniques have been discribe to disclose information by gaining access to the response. The risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-origin policy.