Should user input be validated for it's length?

Question

Is it bad not to validate length of user input to text field at server side. May it lead to such vulnerabilities as buffer overflows and other?

I think it depends on programming language of application. So, please describe it for PHP, Java, .NET, Ruby etc.

Answer 1

It does depend on the programming language being used. Keep in mind that if there is a buffer overflow for a language that manages strings, that overflow will generally occur at levels that you cannot reach. I think you might be more concerned about situations where you are going to pass the string into another domain (such as a database, a C-based module, etc.) At this point, it would be prudent to ensure the length and other data type characteristics are appropriate for the destination.

I remember reading in the original spec for HTTP (I think it was there) that a good server should be flexible in what it accepts, but be strict in what it returns. The same thing can apply here: be as flexible as you can about the user input you receive, but ensure that it is as safe and secure as possible before moving it to another domain.

Answer 2

While it's true that what happens during a buffer overflow has a lot to do with the development context in which the overflow occurs (ie, what language, what operating system, and even what type of hardware) - it's also a general good practice to check the size and syntax.

I'd be impressed if anyone has both the time to do a write up for each of the languages you mention... I know the vagaries of some of these languages, but not all of them - to really adequately hit all of them in a single answer would be quite an impressive level of expertise.

I can say for a managed language - like Java and (I believe --- no my forte) .Net - you are looking at (generally) less terrifying ramifications than in a language closer to the bare metal (C, C++). A buffer overflow in a language with managed memory should allow the program to allocate the memory as the information arrives and handle it in a somewhat eloquent fashion (to a point!). The truly classic overflow is one where the programmer has not allocated his character array properly and the data in the overflow has leaked into another segment of the program.

That said - even in Java a buffer overflow can cause unintended responses. In a managed language, it could be that you suck the process dry of allocated memory causing slowdowns. You could cause the machine to "fail open" if it hasn't been properly configured, you could produce unexpected output in whatever data persistence mechanism the program is using. All of this is true regardless of the language.

A general size check at the front lines is simply good programming practice. Why not bounce bad data before you work harder at it? You're saving CPU cycles, runtime and persistent memory, and you're protecting the back end. Layered security is just a good way to go.

Answer 3

I'd always validate everything simply because me catching an invalid input and displaying a nice error than trying to drop war and peace into a varchar(200) and watching things go wonky for the end user.

As for security holes? Typically not, because as stated, that is outside of the realm of scripting (low level language constructs), however I bet there are circumstances where you could get an application to possibly trim data, breaking the DOM and allowing for possible injection (completely off the top of my head though) and many other tricky ways to use the lack of length restrictions to your advantage.