Mark Wills wrote:
> Suffer from hacks? Well okay. I think you're thinking about Forth ala
> Gavino, i.e. in the web world. But there's a much larger world out
> there. Forth is niche, and I wouldn't turn to Forth to develop a fault
> tolerant, hack-proof, robust web based system. There are other
> languages (and systems/sub-systems, such as SQL, fault tolerant
> message queues etc) perhaps better suited to the task.
Huh? Actually, the current web ecosystem has proven to be not very
hack-proof and fault tolerant. IMHO the idea that a language is "hack-
proof" or such is nonsense, one of the most popular attack targets today
is Java - which was deliberately created to be "secure". It isn't.
These of course are all "bugs", it's not features; in Forth, the
insecure parts are features.
The way to make an execution environment secure is to sandbox it from
the outside - not to sandbox it from within, as Java does. If you read
Googles papers about sandboxing e.g. Flash, they are very deliberate
that the sandbox itself must be a rather simple and straight-forward
thing to be robust enough.
Dijkstra had once said "Programs are either so simple that they contain
obviously no bugs, or so complex that they contain no obvious bugs".
That means to be secure, you must separate the supervision of a program
from the program itself, and make the supervision a rather simple task.
The many mistakes that have been done with SQL injections show that
"complex" isn't "good". Web scripts are usually written in programming
languages which are feature-rich in text processing, and the user abuse
those features because they are so easy to use. So people write a web
form like "select * from students where name=$name;", and $name is a
string variable. Well, we have such features even in standard Forth
now, you could use SUBSTITUTE for that. But it's wrong. You shouldn't
do it that way, and SQL even has a mechanism to pass parameters to
queries, where you can compile the query once, and execute it with
different parameters as often as you like - without risking any SQL
injection ever. These parameters won't be parsed and analyzed by the
SQL statement compiler, so it doesn't matter if name is "Robert'; drop
table students" (Little Bobby Table). You don't even need to sanity
check that name - it's always treated as non-interpretable string, and
then it's fine to have funny characters in it.