PDA

View Full Version : limiting form textarea input

Stephen
09-16-1999, 04:24 PM
is there any way to do it? what happens when you drop the encyclopedia brittanica into a textarea form input used to collect comments for processing by a mail program, etc?

usually i check the size of the named textarea field input when i retrieve it. but is there any way to stop the browser from sending a CGI program a very large input field?

with the text input field you can specify a MAXLENGTH parameter to do this. is there no corresponding equivalent for the textarea? and why not!
Deb
09-16-1999, 04:40 PM
This is where I see JavaScript come into play ;) Each element in a form has a value; the value for a TextArea is in String form, and all Strings have a default length property. Using an event handler for the TextArea, we can check the length of the content and chop it off if it is too long. This example uses a length of 10 characters.

<HTML>
<HEAD><TITLE>Self-limiting TextArea</TITLE>
<SCRIPT LANGUAGE=&quot;JavaScript&quot;>
<!--
var content;
function limitArea(){
[nbsp][nbsp] content = document.TestForm.TArea.value;
[nbsp][nbsp] len = content.length;
[nbsp][nbsp] if (len > 10) {
[nbsp][nbsp][nbsp][nbsp][nbsp][nbsp]content = content.substr(0,10);
[nbsp][nbsp] }
[nbsp][nbsp] document.TestForm.TArea.value = content;
}
// -->
</SCRIPT>
<BODY>
<FORM NAME=&quot;TestForm&quot; ACTION=&quot;http://some.domain.name/some.pl&quot; METHOD=POST>
<TEXTAREA COLS=50 ROWS=10 NAME=&quot;TArea&quot; onKeyUp=&quot;limitArea();return true&quot;>
</TEXTAREA>
</FORM>
</BODY>
</HTML>

Taken from http://www-c.developer.com/experts/javascripts/answer189.html

Deb
Stephen
09-16-1999, 06:29 PM
Thanks Deb!

Truth is I've avoided javascript for the longest time, but recently I'm starting to see that when it comes to filling out forms it does seem to offer some real advantages. Looks like I'll be learning some js after all. I appreciate the pointer (because I would never have figured this out!).
Stephen
09-16-1999, 09:27 PM
Well, it works great in IE, but NN 4.08 and it's a mess. On reaching the text size limit it goes back to the beginning of the string and starts overwriting it.. backwards!

If anyone tries out this snippet in NN and gets it to work please let me know. Thanks.
Stephen
09-17-1999, 01:34 PM
Now I remember what I didn't like about js. You have to explicitly take account of which browser your code is been handled by. onKeyUp works with IE, but with NN you need something like onBlur or onChange to effect the same end result.

Since I'm totally ignorant of the js protocols, can someone tell me of an on-line resource which discusses event handler compatibility for the two main browsers? i.e. are there are shared-name event handlers which work both in IE and NN, therefore obviating the need to write browser-dependent javascript?

S.
--who hopes that gates' billion-dollar scholarship fund goes a little way to educating the next generation of programmers on how not to re-package the wheel in the shape of a square...
Stephen
09-19-1999, 01:15 AM
wait a gosh darn minute there...

why am i pursing this javascript method (i finally got it working) when the user can simply switch off the javascript capability of their browser?!

i was looking for a method to inhibit those who might try to crack open a cgi script by overwhelming it's buffers. actually, i don't know exactly how this is effected but i've read that it's to be avoided at all costs.

anyone know how to stop-up this apparent weak link in a script that offers a textarea box? or is my concern overrated? (somehow i doubt it). does CGI.pm offer any implicit protection in this regard? (i haven't read anywhere that it does).
Justin
09-19-1999, 03:14 AM
A few notes: First of all, anything you do in HTML/JavaScript can be overridden by simply saving the page locally and editing it... Second, your script should be validating form input all the way - especially length. I doubt you would cause a buffer overflow by trying to dump lots of data/text into a script - consider using an upload script and uploading a several meg file. It's done all the time :)

Just validate the form input and you'll be fine, and never count on MAXLENGTH or any HTML/JavaScript for validation, as these things are *very* easily circumvented...

HTH

------------------
Justin Nelson
FutureQuest Support
Terra
09-19-1999, 02:36 PM
On a POST method, reading CONTENT_LENGTH is a good method, and taking only what you want...[nbsp][nbsp]Apache has a tunable configuration to reject excessive lengths 'LimitRequestBody'...[nbsp][nbsp]If the method is a GET, then the Linux Environment limits come into play...

Primarily the concern with buffer overflows is in the way of C type programs where you must be exact with the type of data you handle...[nbsp][nbsp]With scripted languages, this problem quickly diminishes (like perl) as all of it's memmory handling is done dynamically without you having to worry about the details...[nbsp][nbsp]Most CGI hacking is accomplished when arbitrary commands are embedded in normal input, and that input in turn is used in calling external commands from the script...

Pseudo:
$input=>>stuff from form<<;
decode $input;
$listing=`ls -l $input`;

That is all find and good; except when $input has the following...

input: qq@&quot;/mydirectory/www&quot;\;rm -r &quot;/mydirectory/www&quot;\;@;

The above is visual only, but you get the idea... ;)

When it comes to security related items, we are extrememly cautious in what we say due to the liability that surrounds it...[nbsp][nbsp]If I were to tell you how to secure your site, and someone manages to circumvent that, then we would be liable and could be sued for damages...[nbsp][nbsp]This is why there are lots of security professionals that do this for a living, and have the necessary insurance to cover themselves...[nbsp][nbsp]What was the ultimate in Security today, could be blown wide open tomorrow...[nbsp][nbsp]Just ask MicroSoft, they live with it daily...

As I've stated *many* times in the past, NO system anywhere is 100% secure (Military/NSA/Government sites getting hacked consistently)...[nbsp][nbsp]No matter how hard you try, there is always going to be something somewhere that was overlooked, and just waiting to happen...[nbsp][nbsp]Best anyone can do is stay abreast of security related issues, and be able to take proactive and/or reactive measures to stem the tide...

You would not believe the amount of 'ThrowAway' accounts that FutureQuest receives, where:
1) New customer signs up
2) We set them up in 24hrs or less (before any payment is ever received)
3) They login and nose around
4) They begin to try and crack the system
5) Various monitoring tools I've written see suspicious activity and I'm alerted
6) I go and investigate the activity
7) 7/10 times I have to terminate the account
8) They move on to the next host

The above wastes a lot of time/money/energy trying and is increasing as time goes on...

Due to the above waste of time, FutureQuest will be taking a proactive stance on 'ThrowAway' accounts by invoking a 'Setup-after-Payment' method to help stop these 'hit-and-run' accounts...

At least then, we would have a better idea of the true identity of the person, and if they were to use a bogus 'Credit Card' or 'Hot Check', then we would have more means of legal recourse to prosecute...

--
Terra
--Anonyminity on the net is a double-edged sword that can often stab you in the back--
FutureQuest
Stephen
09-19-1999, 05:03 PM
Terra,

Thanks for the info. Sounds as though writing my scripts in Perl alleviates part of the problem. I agree with what you had to say about pay-first then we set you up. Since you offer the 90-day satisfaction guarantee (as I remember it) there's not much a legitimate customer could object to.

By the way, my SSL activation letter never showed up. Could you resend it? Thanks.
LeafWind
09-19-1999, 10:17 PM
TeRRa said:
Best anyone can do is stay abreast of security related issues, and be able to take proactive and/or reactive measures to stem the tide...

Could you suggest any links, tutorials, or other resources where someone could get started in learning about this for themselves?

Thanks

Bekariso

------------------
www.LeafWind.com (http://www.LeafWind.com)
Growing web sites that thrive in the winds of change.
Deb
09-19-1999, 11:15 PM
If you haven't already, you'll want to check this one out ... http://www.w3.org/Security/Faq/
Stephen
09-20-1999, 12:46 AM
Justin,

I'm pretty cautious when it comes to writing my scripts. First off, I never assume that a user's input is what it's *supposed* to be. I length-check and character-check everything. I also check the form's referer page to make sure that it was submitted from my site (although I know the HTTP_REFERER can be overriden by those who know what they're doing).

But my main problem, the one I've been wrestling with, is not MY forms, but other people's. I now write software that parses other peoples web pages and re-presents them (Kookaburra being the publicly-mentioned one). The easiest route is to hand off a foreign form to the destination it was intended--which I now think might be the best solution for any form containing a textarea box.

But of course, that's not required. You can always redirect that form back to your own script (e.g. Kookaburra) and then repackage the form and send it on to its final destination. Why might you do that? To keep the user at your site, instead of losing them to the web site that provided the form (e.g. Amazon.com). Because you cannot anticipate what's going to be in the form, you need to preserve its structure when sending it on. I'm just looking for ways to head off a malicious user who tries to break my script by dumping too much data into a form.

Here's another question along this line: Regardless of which server a script is being executed on (i.e. not necessarily an FQ server, but ANY machine) what is the best strategy for rejecting an oversized form that has been pointed at your script? Examine the CONTENT_LENGTH environment variable and abort if it's too large? Would that actually DO the trick?

What say Terra on that one?

How do other developers handle this problem? What is the ULTIMATE solution I wonder...

Mr. Cautious-to-a-Fault(?)
--------------------------------------------------------
P.S. I was wondering why we don't have more in the way of security-related discussions here at FQ. I know Terra does a good job of tightening the lid, but maybe since the number of SSL-enabled sites is growing, perhaps a &quot;Server Security&quot; forum might be a useful addition to the site (private forum, of course). That could be a place to discuss a whole range of problems we face that we tend to keep mum about in public areas like this. Just a suggestion...
LeafWind
09-20-1999, 10:49 PM
Thanks I'm checking it out!