OT: Decrypting PHP preg_replace Strings

[Richard Gaskin]

Sivakatirswami wrote:

> We have hackers on our web server getting in thru one Domain... I think
> there is a whole in WordPress.
...
> I can't wait until move our site over to RevIgniter; I think it will be
> much more secure!

Well, at least with injection attacks from buffer overruns, according to 
Dr. Raney the LC engine is far more secure than most alternatives:
<http://www.mail-archive.com/metacard@lists.runrev.com/msg02659.html>

I've been giving this subject a lot of thought recently, since a friend 
of mine had a site that was compromised using a similar exposure in 
Drupal.  The Drupal folks have since closed that particular hole, but 
this raises two key points:

1. If you're using any third-party CMS, you really need to be prepared 
to stay on top of updates.  A powerful CMS is also a complex one, and as 
complexity grows the range of potential entry points grows along with it.

2. If you write your own CMS, it may be helpful to change some coding 
habits to write more defensively.

Here's one example of this latter point:

For many years I've been in the habit of using "put url..." to get local 
file data, but if a system provides any way in which the name of the 
file being read is affected by inputs from the browser, it can be 
possible for that local URL reference to be a remote URL to some 
nefarious site.

So now, when writing CGIs I take the time to use 
"open..."/"read..."/"close..." instead.

While it takes a few more lines to write, it obviates the possibility 
that such code can be misused to inject remote URLs.

Of course even better is to monitor incoming params to eliminate the use 
of undesirable remote URLs, and that should be done too.

But as a system grows you may add features down the road which open up 
such possibilities, and if you've adopted defensive coding habits up 
front the implications are not so severe.

So at a minimum, these days when writing CGIs I make an effort to:

1. Never use "put url..." for local file access

2. Carefully error-check incoming params to avoid unwanted data

What other practices might we consider to make our CGIs more secure?

For example, SQL injection is a common vulnerability, and PHP provides a 
function to sanitize data going into the DB.  Any of you have a similar 
LiveCode function to sanitize data?

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv