Q:

Are buffer overflows on websites stoppable?

Recently, I was at the bookstore checking out books on computers. I found an interesting book on various types of hacks and how to stop them on your servers.
One that caught my eye was the "buffer overflow". It was basically the hacker removing the limit on an input box, typing random gibberish into the input, and then sending it to the server.
The server would get a buffer overflow, and most likely crash.
Sadly, in this book, it did not include any information on how to stop these attacks. And to me, these attacks sound pretty unstoppable.
Scenario one:
I am the owner of a server. On the server, there is a website with a forum. In the forum, I have the user submit information to the server. The input box does NOT have a limit on it
How would I be able to stop a buffer overflow, if one is possible?
Scenario two:
I am the owner of a server. On the server, there is a website with a forum. In the forum, I have the user submit information to the server. The input box has a limit on it.
How would I be able to stop a buffer overflow?

A:

Limiting text in an HTML form doesn't really stop buffer overflows because a bad actor can edit your HTML or not use it at all.
Buffer overflow vulnerabilities are caused by programming errors.  Programs processing the data on the server must, if using fixed size buffers, count characters as they're stored and store no more than the allocated number of bytes.  When the buffer is full, the program must either allocate more memory or stop accepting data.
For web sites, this means not writing CGI programs in languages like C unless you are absolutely, positively sure you know what you're doing, and maybe not even then.
If you are using a scripting language like PHP, the language processor can have buffer overflow faults.  About all you can do about that is keep PHP, web server (e.g. Apache) etc. up to date and read the bug reports.  Mostly at the programming level, one isn't dealing with fixed size "buffers" in those languages, but you should still check input lengths as part or normal data validation.
Secure programming requires that you make no assumptions about any data that comes into your program from the outside.  Instead you must validate everything.  Validate by checking for acceptable values, not trying to "enumerate badness."
Enumerating badness (Marcus Ranum's term) means trying to filter out the things you know are bad.  All the bad actors have to do is find some badness you didn't think of and you're hosed.  Instead, accept only those things you know are good and reject the rest.  If you mistakenly leave something out of the things to accept, your program will break and you will fix it.  That's far better than having a compromised system.

