Security of the ABL language

Upon reading the blogs at computerworld.com (or infoworld.com - I can't remember) I came across a PDF report on safe coding practices (which can be found here http://www.safecode.org/publications/SAFECode_Dev_Practices1008.pdf ).

While the PDF has some ideas on management oriented safe practices, it does delve a little into safe practices regarding technology. What it doesn't is how it applies to ABL coding.

One of the biggest problems in SQL based database apps is something called SQL injection. (Google it - plenty of articles on that.) The good thing with ABL coding is that it is practically IMPOSSIBLE for a program written in ABL to be susceptible to SQL injection. That said, any program that uses the SQL engine of the database IS susceptible to this kind of trouble making.

Another problem with other languages - especially those close to assembly like C or C++ - is the dreaded buffer over run. As before with SQL injection, it is practically impossible for your ABL program to be subjected to a buffer over-run. The 4GL variable system is to abstracted away from actual implementation on the system to cause trouble. (The only player in this system that might cause problems are MEMPTR variables - but even then these are not exactly char *Ptr type variables like found in languages encountering this problem.)

When speaking to resistant MIS organizations about the ABL one may wish to point out these factors in safe coding.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
alonb's picture

I agree ... as long as it's

I agree ... as long as it's a static for each not a dynamic query.