In ASP.NET MVC views, it is typical to bind model values using Razor's syntax:
#Html.DisplayFor(m => m.Name)
We know that Razor will html encode the value by default. But imagine a malicious user inputting scripts in a textbox and submitting it:
<script>alert('Executing evil script')</script>
Now if we do not use the [ValidateInput(false)] or [AllowHtml] attributes, we will be hit with a HttpRequestValidationException which means this exception have to be caught every time a user submits a form.
From the answer in another stackoverflow question, I know we can disable request validation on an application level but many are suggesting this is a bad practice.
My question is, given we have Razor to escape all > and <, can we assume the site will still be secure if we turn off request validation?
No, relying only HTML encoding during Razor page generation and switching off request validation is not a good strategy to combat XSS attacks:
Request Validation prevents bad user input from getting into your database / storage / other user screens in the first place.
Html encoding (sanitization) is there as a backup strategy, e.g. where the attacker has already got through the door.
Considering that an App can serve more than just Html - e.g. Xml and REST services, which will not be subject to the encoding by the Html helpers. (e.g. attacker might find a way to put a malicious payload in an Xml CDATA section)
Also, consider running regular Sql / NoSql queries against your database looking for signs that your site request validation has been compromised.
Related
Request Validation is a powerful mechanism to prevent injecting malicious code via a request to server. This is done on server-side so regardless of the fact that whether any client-side validation has done or not, one can be sure if something unusual is coming then an exception will be thrown automatically.
My question:
While we have "Request Validation" in hand, does it still necessary to sanitize requests?
I'm using Asp.net MVC 5.0
PS:
I'm solely talking in the context of web (not DB or something else) and its potential vulnerabilities (such as XSS).
Yes! There is plenty of perfectly valid input in ASP.NET's eyes that could cause issues in your application if not dealt with correctly.
For example, if somebody passed some data in a request and you weren't correctly parameterizing queries in your data layer then this input:
x'; DROP TABLE users; --
Could result in this query:
SELECT FieldList
FROM Users
WHERE Email = 'x'; DROP TABLE Users; --
Oh noes! You've lost your Users table!
You should always treat user-input as hostile irrespective of request validation. This demonstrates some scenarios whereby request validation wouldn't save your skin.
HTML encoding when you render user-provided input is important... Never render any untrusted input using #Html.Raw and be careful that your HtmlHelpers correctly encode anything coming from a user.
Defence in depth is important. Think of request validation as just one piece of that process.
Here's a link about Xss on MSDN and Request Validation
https://msdn.microsoft.com/en-us/library/vstudio/hh882339%28v=vs.100%29.aspx?f=255&MSPPError=-2147217396
I have a large HTML form which has approximately 60 fields with a lot of jQuery based conditional fields, validation, and a lot of CSS applies to UL and LI tags.
The goal is to email the form responses and redirect user to a specific URL upon form submit.
SMTP has been configured on IIS 7.5 and is working. What I don't have is a .Net based sendmail equivalent on IIS that does not require for me to code in every single form field.
I have seen numerous solutions out there which suggest to wrap the form fields into <asp:textbox> <asp:checkbox> etc. tags, but that is totally out of the question. I need to preserve the existing form as is in HTML markup of the page and simply find a suitable form action that will allow me to post the form such that it's emailed out (and hopefully redirected to a new URL).
I understand that I may need to create an emailer script and I realize that it there is System.Net.Mail I am just not clear how to pass my entire form into the mail.Body without that it has to become an ASP form first.
You can use Request.Form to access posted form from any HttpHandler, Page or Controller. Given that you only need to post, maybe HttpHandler is the best choice actually.
Then it is up to you how to work keys/values in Request.Form to build your email.
Which validations are preferred : client side(using Javascript) or serverside (using validation controls in C# asp.net)?
You should always validate on the server. Client-side validation is fine to enhance the user experience, but anything that has come from the client is potentially dirty and should be validated on the sever again, as your server-side code is not vulnerable to malicious user manipulations (at least, not in the same way that client-side code is).
Always finally validate on the server!!
both are good, at minimum server side validation is a must. As client might have javascript disabled on the browser
Reason you shouldn't rely on client side validation
The end user could have javascript switched off
The data could be sent directly to your server by someone who's not
even using your site, with a custom app designed to do so
A Javascript error on your page (caused by any number of things)
could result in some, but not all, of your validation running
Both.
JavaScript is important because it prevents invalid postbacks to
server.
Server-side is important if client disabled JavaScript from browser
than JavaScript validation bypass.
I also recommend you to make validation at database level also. for reliability.
You should perform validations at server side as well as client side.Client side validations increase interactivity of your applications.In other words make your application more user friendly.However client side validations may have their shortcomings , if your user disables javascript , then he could very well enter non sense data values and send them to your server.You dont want this to happen.For that purpose you need to perform server side validations.Server side validation controls filter the input and make sure proper data is entered.There are good validation controls Asp.Net offers.You could very well utilize them.
I recommend you to use both client as well as server side validation for a blend of interactivity and protection.
Thanks
The basic validation such as the emptiness of the fields, valid emails, number, strings or dates should be done at the client side, but you should always validate at the server for any potential hacking like cross site scripting or tags (php tags for example) and to make more and more secure always use stored procedures and also make sure to have a function that replaces "'" by this """ or <> by empty string and any other dangerous characters.
I am using the Anti forgery token html helper at all the views that accept user input and the [ValidateAntiForgeryToken] on the associated action methods to protect from any possible CSRF attacks.
But i am facing a problem on how i can test that these line of codes is working well and they will prevent any possible attack.
BR
You could write a static HTML page that you could host just anywhere. Don't even need a web server, you could use the file:///c:/foo.htm for example. In this HTML page create a simple <form> that will contain the same input elements (same names) as some of the ASP.NET MVC views that you want to test against CSRF. The action of the form will point to the same action as your ASP.NET MVC views. Then submit the form. If an AntiForgeryToken exception is thrown, you are safe. If on the other hand the controller action is executed, you are vulnerable to a CSRF attack.
To learn more about CSRF look at the following article. Jeff Atwood also blogged about it.
And don't just expect some miracle tool that you will run and it will show a green or red light. If such tool existed, hackers wouldn't exist, as all sites would be protected and they wouldn't have anything to hack.
The best way to ensure that your site is safe is to consult with a security specialist who will perform an extensive audit and code review.
In an aspx C#.NET page (I am running framework v3.5), I need to know where the user came from since they cannot view pages without logging in. If I have page A (the page the user wants to view) redirect to page B (the login page), the Request.UrlReferrer object is null.
Background: If a user isn't logged in, I redirect to the Login page (B in this scenario). After login, I would like to return them to the page they were requesting before they were forced to log in.
UPDATE:
A nice quick solution seems to be:
//if user not logged in
Response.Redirect("..MyLoginPage.aspx?returnUrl=" + Request.ServerVariables["SCRIPT_NAME"]);
Then, just look at QueryString on login page you forced them to and put the user where they were after successful login.
UrlReferrer is based off the HTTP_REFERER header that a browser should send. But, as with all things left up to the client, it's variable.
I know some "security" suites (like Norton's Internet Security) will strip that header, in the belief that it aids tracking user behavior. Also, I'm sure there's some Firefox extensions to do the same thing.
Bottom line is that you shouldn't trust it. Just append the url to the GET string and redirect based off that.
UPDATE: As mentioned in the comments, it is probably a good idea to restrict the redirect from the GET parameter to only work for domain-less relative links, refuse directory patterns (../), etc. So still sanity check the redirect; if you follow the standard "don't use any user-supplied input blindly" rule you should be safe.
If you use the standard Membership provider, and set the Authorization for the directory/page, the code will automatically set a query parameter of ReturnUrl and redirect after a successfull login.If you don't want to use the Membership provider pattern, I would suggest manually doing the query string parameter thing as well. HTTP referrers are not very reliable.
The problem could be related on how you redirect the user to some other page. Anyways, the referer url is nothing you should take as absolute rule - a client can fake it easily.
What you're looking for is best done with a query string variable (e.g. returnURL or originURL). Referrer is best used for data mining operations as it's very unreliable.
See the way ASP.Net does redirection with logins for an example.