Re: Larkin, Power BASIC cannot be THAT good:

Nobody wrote:
On Thu, 11 Jun 2009 20:48:33 +0100, Martin Brown wrote:

Manipulating data as structured text using string manipulation functions
is the road to hell. I'm convinced this approach has created more security
flaws than buffer overflows ever have.
I'm not so sure.

I haven't conducted a rigorous survey, but that's my impression from
being subscribed to BugTraq for the last 13 years.

Injection attacks in (mostly) PHP scripts are the low-hanging fruit of
vulnerability analysis; the phrase "shooting fish in a barrel" comes to
mind. Some days you might see a dozen posts from one wannabe security
researcher who just went looking for the most obvious bugs in PHP scripts,
and found no shortage of them.

Google says:

Results 1 - 10 of about 154,000 for "sql injection attack"

Okay, so by page 10 it's lowered its estimate to 73,400, but it's still
not exactly obscure.

I think I will concede the point entirely where PHP Internet exploits are concerned that is a lost cause. But I am not sure if the problems are the fault of processing structured text by string manipulation or inadequate safeguards in the script language.

Sure, you *can* write correct code in Perl; it just makes doing a
half-arsed job so much easier than doing it right.
I am not so purist as to insist on perfection. A write once and throw away program can be done in whatever language makes the job easiest. The only tricky thing is making sure that the code really works as intended.

Security doesn't matter if the program will only be run by its author on
data created by its author; there's no mileage in exploiting your own
account.

Yes. I had in mind jobs which are essentially turning the rubbish formatted dump of raw data that some manufacturer outputs into a format that is useful to their customer. You would not believe the number of expensive instruments that output measurement data in the most user hostile and bulky formats possible.

Unfortunately, code which reads and/or writes structured text formats is
frequently used in exposed environments, either on web servers or for
processing data obtained straight off the 'net.

And that is where it is very prone to abuse. I am still inclined to think that the problem is more with the current implementations and sheer number of bad exploitable scripts around than with the concept itself. Easy to use tools without safety guards is never a good idea.

Regards,
Martin Brown
.

Relevant Pages

  • Re: Access 2007 user level security (lack thereof)
    ... No. User-Level Security is only available with the MDB format. ... Can't you use the database password and code it into your VBA so ...
    (microsoft.public.access.security)
  • Access 2007 user level security (lack thereof)
    ... Is it possible to create and work with user-level security from within the Visual Basic Editor, though in ACCDB file format? ... Can't you use the database password and code it into your VBA so ...
    (microsoft.public.access.security)
  • Re: [SLE] Proposal:TML. HTML without the H for markind up mail, etc.
    ... I think you mis-understand the objection to html in email. ... It is not objectionable ONLY because of security issues, ... It is after all, mostly a Microsoft problem ... an exploit is found in the format. ...
    (SuSE)
  • Re: Access 2007 Security
    ... Has Microsoft given any reason for not making user level security avalalble ... Access 2007 supports User-Level Security from previous versions ... as long as the file format remains as a Jet file. ... managing User-Level Security in an existing database, ...
    (microsoft.public.access.security)
  • Re: dangers of operator overloading
    ... >> (This also assumes you don't care about security) ... > easy to encrypt the source for storage and then decrypt it and compile ... > the native-lisp-sepxr format to whatever new data format you need. ... > invent an input routine for a new syntax, ...
    (comp.programming)