Re: arrange form data in same order as on form
From: Purl Gurl (purlgurl_at_purlgurl.net)
Date: 11/15/03
- Next message: Purl Gurl: "Re: Giving back"
- Previous message: Eric Wilhelm: "Re: accuracy (er, precision) problem"
- In reply to: Gunnar Hjalmarsson: "Re: arrange form data in same order as on form"
- Next in thread: Gunnar Hjalmarsson: "Re: arrange form data in same order as on form"
- Reply: Gunnar Hjalmarsson: "Re: arrange form data in same order as on form"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 15 Nov 2003 13:30:57 -0800
Gunnar Hjalmarsson wrote:
> Purl Gurl wrote:
> > Gunnar Hjalmarsson wrote:
(snipped)
> As regards that aspect of security, maybe I should have added that
> data submitted by users who are not logged-in, and which ends up on
> generated HTML pages, is converted by this sub:
> sub htmlize {
> $_[0] =~ s/&/&/g;
> $_[0] =~ s/"/"/g;
> $_[0] =~ s/</</g;
> $_[0] =~ s/>/>/g;
> return $_[0];
> }
> That conversion is done at a later stage, since (non-converted) HTML
> is occationally included in email messages.
> Wouldn't that take care of the risk with backticks as well?
As you know, the degree of risk of input data is directly
related to "what" a program does. If a program does not call
any functions susceptable to backtick syntax, no problem.
A classic example, a simple example, is a hit counter. Those
scripts exhibit very little security risk, and usually do not
work very well to boot!
Contrasting this, our Chahta Chat is susceptable to hostile
html tags. Nonetheless, we want our visitors to be able to
enjoy fancy fonts, colors, pictures and all that.
For html, like you, processing outside a read and parse takes
care of this.
my (@bad_word_list) = ("<applet", "<blockquote", "<body", "<dl", "<form",
"<head", "<html", "<ol", "<object", "<plaintext",
"<script", "<strike", "<xmp", "<ul", "<h1", "<h2",
"<h3", "<h4", "<h5", "<h6", "|/", "<embed",
"face=symbol", "face=system", "strnps", ... others
Simple matter of looping and looking. Some html tags will result
in a visitor being automatically banished. Others, a stern warning.
Before someone jumps on this, leading spaces are processed out
before looping takes place; < applet becomes <applet then processed.
Don't even bother trying. You cannot mess up our chat.
We just had a visitor drop in earlier, to test if he would be
banished for hitting a cgi script too fast, after I posted
an article about this. There are those here whose only intent
is to cause harm to others. Obviously I have been alerted to
what he was doing. Obviously our androids may elect to banish
him in the future. Jeeeshh... such stupidity. I cannot fathom
sitting in front of your computer clicking "Play Blackjack"
as fast as you can. He should be reseaching NASDAQ penny
stocks and working on becoming wealthy, or very poor.
Almost all security sites suggest allowing only that data you want,
otherwords disallow everything and make exceptions for safe data.
However, another approach is to disallow just enough data characters
to defeat many combinations. Disallowing a backtick does defeat a
very large amount of hacks. Most of the hack may appear, but without
a backtick, it won't work. Disallowing a right slash / prevents
directory changes as with ../ syntax. You really have to know
your programming and hacking to do this successfully.
What is important is to design your processing for a specific task
rather than use a broad sweeping brush to catch everything. Doing
that is very inefficient.
Your use of < and > is a good example. Doesn't matter what is
inside html tags because they won't work because of your parsing.
You have avoided having to parse out some html and allow other.
This is a serious weakness with Perl 5 modules. Most are useful,
many are well written. Nonetheless, a large majority of modules
incorporate too many features rendering them useless. Those are
modules which try to "second guess" how they will be used, and
literally always fail, eventually.
Back to Stein's module. If he was a bit better at planning,
read_parse.pm
form_action.pm
html.pm
nph.pm
some_other.pm
He could reduce the size of his module to one-fourth with
effective planning and even smaller with very good planning.
This allows more features per module, a reasonable amount,
without a need a create a monster which often causes more
problems than are resolved; bull in a china shop.
A philosophy often exhibited here is all programs should
be able to handle all circumstances. It is this thinking
which leads to worthless code and worthless modules. This
is a type of thinking, "conform code to all circumstances"
rather than controlling circumstances then coding accordingly,
which is what your code exhibits, to your benefit.
There is no substitute for good planning and good custom
written code nor is there any substitute for using your
limited lifetime, effectively; time cannot be purchased.
http://pennystocks.org/s2_main.htm
Purl Gurl
-- Purl Gurl Net, Delivering Rock N Roll And Fun At Two Megabits Per Second http://www.purlgurl.net/
- Next message: Purl Gurl: "Re: Giving back"
- Previous message: Eric Wilhelm: "Re: accuracy (er, precision) problem"
- In reply to: Gunnar Hjalmarsson: "Re: arrange form data in same order as on form"
- Next in thread: Gunnar Hjalmarsson: "Re: arrange form data in same order as on form"
- Reply: Gunnar Hjalmarsson: "Re: arrange form data in same order as on form"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
