Why you should sanitize input data
ambassador at fourthworld.com
Tue Jul 17 16:57:35 CEST 2018
Bob Sneidar wrote:
> Judging by this, simply putting an SQL server behind a web server does
> not really protect the SQL server like some propose. Maybe I'm
> oversimplifying the issue, but it seems they are saying that using
> this method, shell commands can be executed, and that means access to
> the sql database can be had.
Everything is hackable.
But the more elements we put into place, the smaller the system's attack
Simply hiring a security guard will do nothing to protect your business.
But working with a well trained guard to examine your facility's
layout, identify entrances and exits, and establish a comprehensive plan
for patrolling and mitigating unauthorized entry will stop most would-be
Same with server middleware. The mere existence of
PHP/Perl/Python/LiveCode/etc. by itself won't do much. Smart of use of
those, however, represents common best practice for protecting the full
scope of MySQL's rich feature set from the open Internet.
While it's possible to mitigate many risks by using especially strong
passwords (using modern best practices favoring length over yesteryear's
fixation on complexity) along with stored procedures and other MySQL
features, the belt-and-suspenders approach with using middleware has
become the common best practice for good reason, allowing an additional
layer of fine-grained control over the details of handling requests that
are beyond the scope of MySQL's design.
Extra bonus points that crafting APIs with middleware can also greatly
accelerate client development, esp. where client implementation covers
different access options (native client as well as browser, for
example), and helps factor storage from model to allow changes to either
in ways that minimize impact on other elements.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode