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.
It is all about input validation. Access to a SQL server is reasonable. Access to the shell is something that probably should be avoided. In either case you need to be sure the user/hacker cannot send requests that you do not allow.
On Jul 16, 2018, 9:51 AM -0500, Bob Sneidar via use-livecode <[hidden email]>, wrote:
We had a system interface between a public web server and a SQL database that ran pre-formed SQL commands.
The table was specified, the variables were typed, the output was processed by XSLT, etc.
The public server called a function that included the variables and got back whatever the XSLT produced. Each variable was checked to make sure it conformed to the type of data that variable could contain. Integer, Float, String, Boolean, etc. Strings were not allowed to have quotes in them, and some strings were optionally length limited.
We had a SQL table with these canned queries and an internal interface for building them. Each command also had a sample output so that if someone was using the command as part of a test, it would reply with the desired test data and not actually affect the SQL database.
SQL injection is just amazing to watch. Once saw a demonstration of a bank in India. In the login, they added SQL to the password field and got back a list of all the tables in the database. Very scary.
> 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