Why you should sanitize input data

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Why you should sanitize input data

Clarence Martin via use-livecode
I suspect the paranoid among us already know this, but I didn't realize
it was quite so easy:

https://null-byte.wonderhowto.com/how-to/use-command-injection-pop-reverse-shell-web-server-0185760/

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Why you should sanitize input data

Clarence Martin via use-livecode
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.

Bob S


> On Jul 15, 2018, at 14:31 , J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> I suspect the paranoid among us already know this, but I didn't realize it was quite so easy:
>
> https://null-byte.wonderhowto.com/how-to/use-command-injection-pop-reverse-shell-web-server-0185760/
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Why you should sanitize input data

Clarence Martin via use-livecode
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.

Thanks,
Brian
On Jul 16, 2018, 9:51 AM -0500, Bob Sneidar via use-livecode <[hidden email]>, 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.
>
> Bob S
>
>
> > On Jul 15, 2018, at 14:31 , J. Landman Gay via use-livecode <[hidden email]> wrote:
> >
> > I suspect the paranoid among us already know this, but I didn't realize it was quite so easy:
> >
> > https://null-byte.wonderhowto.com/how-to/use-command-injection-pop-reverse-shell-web-server-0185760/
> >
> > --
> > Jacqueline Landman Gay | [hidden email]
> > HyperActive Software | http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Why you should sanitize input data

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
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.

Kee

> On Jul 15, 2018, at 2:31 PM, J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> I suspect the paranoid among us already know this, but I didn't realize it was quite so easy:
>
> https://null-byte.wonderhowto.com/how-to/use-command-injection-pop-reverse-shell-web-server-0185760/
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Why you should sanitize input data

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
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
surface becomes.

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
burglars.

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.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode