I'd like to use SSL for the post action on the login page of my MVC 1.0 app. I've seen some articles related to the [RequireSSL] attribute in ASP.NET MVC Futures. However, since this works using a redirect, I assume it's not an option (can't redirect a POST, correct?).
Ultimately, my goal is to get the Html.BeginForm method to render "https://..." as the form's action so that I can secure the information being posted (login info).
How have others handled this?
You could secure the form GET as well. If the form is retrieved with HTTPS, Html.BeginForm will automatically add https when rendering the form.
Related
I have a .Net MVC application. I use Asp.net Identity for login and roles.
Every controller I have is decorated with [Authorize]
I have not done anything else in the code to protect the application.
Is there anything Else that must be done in ordet to protect the site? And im not takling protection of the webserver. Only the website.
Thanks
Add MVC's anti-forgery support, this basically writes a unique value to an HTTP-only cookie and then the same value is written to the form. When the page is submitted, an error is raised if the cookie value doesn't match the form value.
It's important to note that the feature prevents cross site request forgeries.
How to use it:
Decorate every controller action used to post data with this: [ValidateAntiForgeryToken] and add the unique value to your form posting the data by adding the following to your form #Html.AntiForgeryToken()
I am using the new MVC 4 Beta Web API. I want to add an [Authorize] attribute to the Get action in order to have the user authenticate themselves before getting data from the server. I am using fiddler to test the action, but it is redirecting me to the Login Url that is defined in the web.config. I am using [System.Web.Http.Authorize] to add the [Authorize] attribute.
The reason for this happening is because the Forms Authentication module hijacks the 401 HTTP status code returned by the Web API and redirects to the Login page. You may take a look at the following blog post in which Phil Haack talks about how to configure ASP.NET to prevent it from doing this for AJAX requests. You could slightly modify his code so that it does this for all requests, or only for requests for your Api controllers.
To get it working in my API I just removed the authentication section from web.config and wrote (well converted from my WCF WebApi code) a message handler. I've put what I did in to a blog post.
Setup
In my MVC3 app, MembersController is decorated with an [Authorize] attribute.
MembersController has an Action called MyPage. Due to the Authorize attribute on the controller, MyPage can only be requested by authorized users.
Problem
When an unauthorized user tries to request /Members/MyPage they are correctly redirected to the Login page.
However, the ReturnUrl parameter is not passed into the login page, so when the user authenticates, they are taken to the default page (lets call it /Members/Home) instead of /Members/MyPage.
Question
Why?!
In another app, developed in MVC2, the returnUrl QS parameters is there and works as expected.
Other Issues:
The Autorize attribute is being ignored when decorating both controllers and actions.
Resolution:
Sections of web.config not properly updated between .NET 3.5 and .NET 4. See answers below.
#Marcind put me on the right track, #Darin Dimitrov's answer very instructive of the process involved.
Diagnosis
It seems that the issue was related to a web.config that I did not update properly when merging an existing Web Forms .NET 3.5 app to a .NET 4.0 app. I can't recall how I went about this.
Anyway, by comparing the web.config of my app with a new MVC 3 web.config, I was able to find the extra bits that should not have been there, left over from 3.5 days.
Resolution:
The issue was resolved by correcting the bits in the <authentication><forms> tag in the web.config, as well as the <membership> tag.
Other Issues Caused by this:
Another issue caused by this was the fact that if I decorated a controller with the Authorize attribute, it was ignored, so the controller tried to process info based on the current user, that obviously was null, so all manner of exceptions were fired.
It works for me. I created a new project using the ASP.NET MVC 3 RC2, default template, added a MembersController, decorated it with the [Authorize] attribute, run the application, requested /members/index, was redirected to /Account/LogOn?ReturnUrl=%2fmembers%2findex, logged in, was redirected to /members/index. There must be something else wrong with your code.
Here's how it works:
The [Authorize] attribute checks if the user is authenticated and if it is not it returns 401 status code.
The FormsAuthenticationModule which is part of ASP.NET and handles forms authentication intercepts the 401 status code and redirects to the login page by appending the ReturnUrl parameter to the request which points to the initial request.
The FormsAuthenticationModule module is not specific to ASP.NET MVC, this is standard ASP.NET stuff
Need to submit some CC data from the View to the Controller where it will be processed, can I just POST it or is there some common way of securing the data in transit?
Post the data using SSL.
Here's a good resource on setting up SSL with IIS and ASP.NET.
Posting with SSL like Rex M mentioned is definitely the first step. You should probably make the page where they are typing their credit card number SSL as well. This will give your users the green URL of comfort.
You should also include protection against CSRF attacks. Use the anti-forgery token.
Also, you should use the PRG (Post, Redirect, Get) pattern to make sure that the credit card numbers aren't submitted twice. After the post, don't just render a different view, send a redirect so their browser does a GET against another URL - probably your confirmation page.
You'll run into a few ASP.NET MVC specific things:
If you have some http pages and some https pages, how will you code the links to the https pages from the http pages. You can hard code them, but you'll have to hard code the domain and protocol. You can't just use <%= Html.ActionLink(... see this SO question for more details.
You'll want to make sure you can't hit your controllers when you are not using SSL. This will help you catch any errors, and ensure that no one uses http instead of https. See the [RequireSsl] attribute in the futures assembly. Here's a blog post about it from Adam Salvo
I haven't read about the implementation of the ASP.net-MVC. However, i believe that you have mixed up the terminology.
The MVC Pattern would be evaluated on the server end. [So there is little need to do security checks between the components (unless they are exposed outside the program)]
I believe that many people get the impression that you are talking about HTTP POSTS after a form submission (as opposed to HTTP GETs)
I'm using ASP.Net MVC beta 1 and I'm using the asp.net membership provider with the standard authentication controller to restrict access to my site.
I'm using ajax functionality to provide e.g. editing of values by loading partial views into a div with either jQuery $.get/$.ajax or with the Ajax.Actionlink MVC helper. This all works fine most of the time.
My problem comes once the login times out and you click on one of the ajax edit links - the ajax call returns the login page which is put into the div normally used for the edit form.
I want to find a way to redirect the whole page to the login form, when the authentication has timed out and an ajax link is clicked.
One way I can think of is looking at the html returned from the ajax call in the response callback and searching for the 'login' text or form field and doing a redirect from there - but this doesn't feel very clean - is there a better way?
This might help some:
Bypass Forms Authentication auto redirect to login, How to?
From the above answer it looks like http 403 isn't intercepted by Forms Authentication, so you can roll your own ActionFilter that returns an http 403 response if its an Ajax Request and Authorization failed.
On the client side, you could then check the response code for 403, and redirect to the appropriate login url.
There are probably other ways to do this as well!