Re: Dangers of web apps written in Tcl
- From: Fredderic <put_my_name_here@xxxxxxxxxxxxxxx>
- Date: Fri, 21 Jul 2006 02:33:39 +1000
On Thu, 20 Jul 2006 16:23:21 +0100,
Derek Fountain <nomail@xxxxxxxxxxxxxxx> wrote:
I'm sorry, but this is getting bloody ridiculous.
set flagOn [expr $flagValue eq "on"]They are not the same.
if { [expr $check eq "checked"] } {...
Are you saying that these two statements are not the same? What is
the difference?
You, mate, are an idiot. But we'll ignore that for the time being.
[expr $flagValue eq "on"] vs. [expr $check eq "checked"]
Now, where's the difference? Validate the values before you use them
ALWAYS, and there's no problem. Brace the values in an [expr] ALWAYS,
and there's no problem. In an [if], [while], etc., use {}'s around the
condition, ALWAYS, and there's no problem. Don't double-evaluate your
expressions unless you know EXACTLY what you're doing, and there's no
problem. Applying ANY one of those to every one of your examples,
renders them totally inert.
set flagOn [expr {$flagValue eq "on"}]
if { [expr {$check eq "checked"}] } {...
Both of them are now safe with a simple set of braces. PLUS, they're
even faster, to boot. Two bonuses for the price of one braincell.
In the case of you and your friend; simply don't write code which goes
anywhere near untrusted input until you get a clue, and there's no
problem. End of story. This bull*** argument should have ended about
20 posts ago. I repeat, so you can understand what I'm saying here; if
you don't understand the language, get someone who does to do the
user-side work, or at least check what you've done.
The difference is that I use the first construct all the time[*] -
storing the boolean result of an expression for later use. The second
is incorrect (dual expression evaluation) and I've probably not used
that since I was a Tcl-newbie (about 10 years ago).
There's really nothing to it. If you don't know what you're doing,
then don't do it. Simple. And stop being a dickhead by persisting
with your bull*** whining. How many times do you need to be told?
Piss off and let the people who have a clue, get on with helping those
who actually want one.
I only put it in my post to make the similarity with the PHP and Perl
equvialents apparent, but as has been pointed out, other, less
experienced people /do/ do it.
No, you put it in there to highlight a bogus argument. Your TCL
example was nothing at all alike the other two; even as a greenhorn
when I first started using TCL, I'd never have been that stupid as to
put an [expr] in the midst of an [if] like that. Yes, I used [expr] as
one side of an equivalence, but not as the whole expression. Anyone a
company allows anywhere near a programming language should immediately
see that SOMETHING is wrong with that, surely! And no, at first I
didn't originally know about bracing my [expr] expressions. Which is
why the people I was writing scripts for didn't let me anywhere near
the important stuff until I'd gotten recognition off a few who DID know
what they were doing.
And if you can't do that, and even if you can, have a testing plan in
place to check for stupid security fubar's. No programmer worth their
weight in your arguing skills (which is to say stuff-all) puts a
companies trust entirely in the correctness of the programming language
they're using. If it's an important piece of the system in a vulnerable
position, then you back it up with security behind it, in front of it,
within it, and around it, and when you're done doing all that, then you
test it, audit it, and test it some more. THEN, you put it online.
You only relax some if it's not critical to your lively hood, but they
you're making a judgement about just how important you consider your
security, vs. how lazy you wish to be, and you wear the consequences.
But you don't throw around garbage to make it look like your argument
is valid, when all you're doing is demonstrating a fact that everyone
already knows; that ANY tool, in ANY occupation can be misused by
someone of sufficient cluelessness. I wouldn't leave a 2 month old
child alone unattended with a bamboo skewer, in case they shove it up
their nose or poke their eye out. So don't let someone who doesn't
know how to brace their TCL expressions near your web front.
[*] I like to think I put braces in there each and every time, but I
know I probably miss them occasionally.
So does everyone else. Live with it. I like to think that I
check ever C character array to make sure there'll be no buffer
over-runs, but I probably miss them occasionally too. I just make damn
bloody sure that I've checked and re-checked every single one that
involves user input, and then if I'm even the slightest bit uncertain,
I'll ask a friend or co-worker to proof-read it just to be sure.
Web-fronts are a dangerous place. If you're writing one, then it's up
to you to write it in a language you are decently competent with, or
have someone else build sufficient fences around it that it doesn't
matter. Either way, someone at some point has to know what they're
doing, or your company is going to be in for a really bad day. Don't
blame the tool. If you can't handle it, don't use it.
I don't think anybody is trying to shootdown your argument. It isOK, convince me. How do you compare one user-entered string value
just that, the same vulnerability exists in every language from C
to SQL, and Tcl happens to have several, and arguably more advanced
mechanisms to deal with it.
with another hard coded string value, in Perl or PHP, such that if
there is Perl or PHP code in the user supplied value, it gets
executed? The only way that I know of is to use the language's eval
function to wrap the user-entered string on one side of the
comparison, which makes no sense in the script, and would be
completely obvious if someone were to type it. Is there another, more
subtle way that I don't know of?
That happens to be EXACTLY what you did in your contrived "TCL is more
dangerous than PHP and Perl" examples. I handed those three examples
off to someone who didn't even know TCL existed, and they saw the
mistake!
There. That's what I've thought of this entire discussion from about
the fifth post onwards. Derek, you're an idiot. Simple as that. Come
back when you're willing to get a clue. Bye now. Ta ta! (Wonders off
ranting and raving, heard muttering into the distance something about
"some people are just .......") (Actually, that was kinda fun... Bit
of a stress relief really. No wonder flame wars go on for so long...
It really does help one's overall demeanour to just let it all out!)
Hope no one (with the obvious potential exception of the OP) was
offended by any of that. Really. Just trying to put things in
perspective. :)
Fredderic
.
- Follow-Ups:
- Re: Dangers of web apps written in Tcl
- From: Ralf Fassel
- Re: Dangers of web apps written in Tcl
- References:
- Dangers of web apps written in Tcl
- From: Derek Fountain
- Re: Dangers of web apps written in Tcl
- From: Joe English
- Re: Dangers of web apps written in Tcl
- From: Derek Fountain
- Re: Dangers of web apps written in Tcl
- From: Neil Madden
- Re: Dangers of web apps written in Tcl
- From: Derek Fountain
- Re: Dangers of web apps written in Tcl
- From: Kaitzschu
- Re: Dangers of web apps written in Tcl
- From: Derek Fountain
- Re: Dangers of web apps written in Tcl
- From: tunity5
- Re: Dangers of web apps written in Tcl
- From: Derek Fountain
- Dangers of web apps written in Tcl
- Prev by Date: Re: Dangers of web apps written in Tcl
- Next by Date: Re: Dangers of web apps written in Tcl
- Previous by thread: Re: Dangers of web apps written in Tcl
- Next by thread: Re: Dangers of web apps written in Tcl
- Index(es):