Question about form security, buffer overflow

I have seveal forms I made myself, and the php that parses them. In the php I first check each field for length of input and if too long I display a error telling the user that the field of input is too long. Now I was thinking is this realy preventing a buffer overflow if the php form verification is all done server side?

If I checked with javascript client side then that would be no good either because the visitor or client can make changes.

A while back I found in the form search feature, a question about guestbook security. Where server side verification of input is prefered because the client cant make the canges.

What I dont understand is if the large amount of data was submited, and is sent, then the server side script parses it, isnt that when the server would crash, how is it that the server can safely parse all that data?

Edit: I found the post on guestbook security here http://www.antionline.com/showthread...hreadid=236396

Client side verification is nice from a ease of use stand point, but does nothing for security as the user can submit data from their own for or via a get directly to the handeling script.
Most of PHP's functions are decently well coded with regard for buffer overflows so as a rule this isn't an issue, however there are some things to keep in mind for more secure scripts.

1. Accept only GET requests. This might not be applicable for your particular scripts, but GET requests are limited insize to 1024bytes as I recall. This saves your scripts from having to deal with huge requests attemtping to fail it.

2. Default fail design. Engineer the scripts in the manner that if specific criteria are not met, the script fails. Many people code for the script to run unless it failes a sanity check and this can get you into trouble if something unexpected ever comes up.

As I said before, for the most part PHP makes it pretty hard for a developer to shoot themsevels in the foot with things like unchecked buffers, but following the above suggestions will help you make all around safer scripts. :)

catch

I disagree with some of catch's points.

Quote:

---

Most of PHP's functions are decently well coded with regard for buffer overflows so as a rule this isn't an issue, however there are some things to keep in mind for more secure scripts.

---

True. PHP code should not, in general, be suceptible to buffer overflows. In PHP itself, you cannot allocate a fixed length string buffer (there is not method to do it as it would be unsafe). In PHP's own code however, some places may do. In these cases, I would hope that they do so safely.

Quote:

---

1. Accept only GET requests. This might not be applicable for your particular scripts, but GET requests are limited insize to 1024bytes as I recall. This saves your scripts from having to deal with huge requests attemtping to fail it.

---

I disagree strongly here. GET requests are not always appropriate. As a rule of thumb, a GET request should NEVER change anything. So you should make a search with a GET (look at google, etc, all GETs), but you should NEVER make a registration form that uses a GET method.

In particular, note that a browser may safely repeat a GET (for instance, if someone bookmarks the page), but will not send a POST again without the user's consent.

There is no inherent limit on the size of a GET, but some web servers / web browsers have their own limits, so you might think you're safe but in fact not be.

The rest of catch's statement sounds pretty reasonably.

As for myself, I like to first cut parameters down to size and convert them to the appropriate type first (for instance, convert to an int if you're expecting one), then check for validity (for example if it's an email address)

Don't strip out special characters like apostrophes, they are often valid (example: Irish surnames)

Usually your best bet is to ensure that the database access is safe by design, by wrapping dubious things (for example by using DB_DataObjects library), which can improve your code too.

MySQL actually truncates string data that is too long - this is different from many other DBs, which return an error. Bear this in mind.

I apologize, I should have been more clear on what I meant by:

"This might not be applicable for your particular scripts" regarding the GET requests. ;)

I had assumed that GET was limited to 1024 as a standard thing since all of the different web servers I've used had this limit, but after some research I see that slarty is correct, many do, but this is by no means a given. :)

catch

there are a few points that I need to air

Quote:

---

Don't strip out special characters like apostrophes, they are often valid (example: Irish surnames)

---

Sorry slarty but the ' (apostrophe) is the most vital character need for nearly all SQL injection and cross-site scripting attacks. I get you point that is with cirtain names, and there should not be stripped, but it should be changed to something like /'.

There are very few fuctions in PHP that are vulnerable to a bufferover flows, go to http://www.securityfocus.com/bid and search for the version of php you are using and see what exist. Say this you should still check the length of ALL inputs as you do not know what the future holds

SittingDuck

Was carefully reading through your responces, a point brough out on request size limits. I was looking through my server settings and found these:

Quote:

---

Max request size 128kb
Max URL size 10240 bytes

---

This concerns me, as I see 1024 comeing up alot perhaps I should change my server default.

The method I use alot is POST I thought since I was passing so many input fields as data that I might reach the limit and thought that POST might be safer because its not as easy to see the data as is in GET. But I am intrigued with what you are saying about GET and POST. I did not know that GET will resend data silently, but it makes sencs now because ive noticed when testing I get a warning asking me if I want to resend the data or cancle.

For the forgin characters in a GET request, I noticed in my server admin settings there is a restriction on the range of characters it will alow in a GET request.

Quote:

---

There are very few fuctions in PHP that are vulnerable to a bufferover flows, go to http://www.securityfocus.com/bid and search for the version of php you are using and see what exist. Say this you should still check the length of ALL inputs as you do not know what the future holds

---

I was thinking about this, reading your posts seems php offers some internal protection, if the makers of php are security cautious that perhaps I dont need to be so strict. I guess what I mean by this is as example of me checking the name field for non alphabetic characters, maybe to be easyer on the server I just make sure the common characters such as < > " and = are not in the name and maybe let everything else go by, so if they have a french name or as mentioned irish names. Seeing that my server seems to have a blacklist for special characters in a GET request.

Id like to thank you all for your input. Im becomeing more interested in form checking methods because now im tackleing a task of makeing a mini flat database message board.

Edit: In my server config I chose to only alow GET and POST requests, and I unchecked for HEAD requests. I was reading about it and seems that HEAD requests are used sometimes by offline browsers, perhaps I should turn it back on.

Remember the BOFed script can only run with the permissions of the script... clever use of PHP's safe mode can be used to constrain scripts, several PHP config files my be used in a least privilege architecture, this might be complicated though.

My action of choice is to use PHP's settings only to protect PHP related things, use compartmentalization to protect the server. I don't know if this is overkill for your needs, but you might want to check out Argus' Pitbull Protector for NT5 or Argus' Pitbull LX/NSA's SE Linux/HP's Trusted Linux if you are using Linux. These system are not actually linux, just look/work _mostly_ alikes. They have labeled security architectures which basically means that even if a user gains access to the root account (which is typically removed but that is neither here nor there for this example) they will still have the http label/level/compartment and will be bound by it, typically resulting in no gain of permissions/privileges. With this setup you can install netcat under the http label and make it a root shell and the user will only be able to have read permissions over http_root and bind to port 80 privs for example.

If this is not applicable either, just add something like URLScan or whatever the content based IDS du jour is for Linux (which I assume you are running since you are using PHP). You can set maximum sizes for requests and filter odd things going in or going out depending on your paranoia level. :)

best of luck,

catch

Quote:

---

There is no inherent limit on the size of a GET, but some web servers / web browsers have their own limits, so you might think you're safe but in fact not be.

---

It's worth noting that the same thing applies to HTTP POSTs for some applications. For example squid is configured by default to reject HTTP POSTs greater then 1MB in size which can be an annoying gotcha if you're browsing via a proxy. ;)