What is the best practice to handle dangerous characters in asp.net?

Question

What is the best practice to handle dangerous characters in asp.net? see example: asp.net sign up form

Should you:

1. use a JavaScript to prevent them from entering it into the textbox in the 1st place?
2. have a general function that does a find and replace on the server side?

The problem with #1, is it will increase page load time.

Answer 1

ASP .NET handles potentially dangerous characters for you, by default since ASP .NET 2.0. From Request Validation in ASP.NET :

Request validation is a feature in ASP.NET that examines an HTTP request and determines whether it contains potentially dangerous content. In this context, potentially dangerous content is any HTML markup or JavaScript code in the body, header, query string, or cookies of the request. ASP.NET performs this check because markup or code in the URL query string, cookies, or posted form values might have been added for malicious purposes.

Request validation helps prevent this kind of attack. If ASP.NET detects any markup or code in a request, it throws a "potentially dangerous value was detected" error and stops page processing.

Perhaps the most important bit of this is that it happens on the server; regardless of the client accessing your application they can not just turn of JavaScript to work around it.

Answer 2

You accept them like regular characters on the write-side. When rendering you encode your output. You have to encode it anyway regardless of security so that you can display special characters.

Answer 3

Solution number 1 won't increment load time by much.

You should ALWAYS use solution number 2 along with solution number one, because users can turn off javascript in their browsers.

Answer 4

ALWAYS validate input on the server, this should not even be a discussion, just do it!

Client-side validation is just eye candy for the user, but the server is where it counts!

Answer 5

Thinking that

ASP .NET handles potentially dangerous characters for you, by default since ASP .NET 2.0. From Request Validation in ASP.NET:

is like thinking that a solid door will keep a thief out. It won't. It will only slow him. You have to know what are the most common vectors and what are the possible solutions. You must comprehend that every EVERY EVERY variable (field/property) you write in an HTML/CSS/Javascript is a potential attack vector that must be sanitized (through the use of appropriate libraries, like some methods included in newer MVC.NET, or at least the <%: %> of ASP.NET 4.0), no exceptions, every EVERY EVERY query you execute is a potential attach vector that must be sanitized through the exclusive use of ORM and parameterized queries, no exceptions. No passwords must be saved in the db. And tons of other similar things. It isn't very difficult, but laziness, complacence, ignorance will make it harder (if not nearly impossible). If it isn't you that will introduce the hole then it's the programmer on your left, or the programmer on your right. There is not hope.

Answer 6

What is the best practice to handle dangerous characters in asp.net?

I did not watch the screencast you link to (questions should be self-contained anyway), but there are no dangerous characters . It all depends on the context. Take Stack Overflow for example, it lets me input the characters Dangerous!'); DROP TABLE Questions-- Dangerous!'); DROP TABLE Questions-- . Nothing dangerous there.

ASP.NET itself will do its best to prevent malicious input at the HTTP level: it won't let any user access files like web.config or files outside your web root.

As soon as you start doing something with user input, it's up to you. There's no silver bullet, no one rule that fits them all. If you're going to display the user input as HTML, you'll have to make sure you only allow harmless markup tags without any scriptable attributes. If you're allowing users to upload images, make sure only images get uploaded. If you're going to send input to an RDBMS, be sure to escape characters that have meaning for the database manipulation language.

And so on.