On Wed, Jun 23, 2010 at 12:43 PM, Peter Lind <peter.e.l...@gmail.com> wrote:

> I'm just wondering if this is a correct understanding:
> 1. plaintext data arrives on the web frontend.

or over SSL

> 2. It's sent to the app server

SSL or non-SSL - your choice

> 3. It's encrypted and sent to the DB server

encrypted or not encrypted - your choice

> Where does the data go after step 3? Does encrypted data go back out
> to the app server? In which case, what's to stop me from exploiting
> the web-server and then sending *bad data/commands* to the app server?
> But maybe I'm taking this too far: are you only looking at security in
> terms of storage? I.e. is this merely a question of avoiding dumps of
> the data?

It is mainly about how to stop an exploited machine (even shell
access) from accessing the data by simply looking at a PHP config

This solves that by reducing the risk with the only WAN-accessable
touchpoint (web servers, or well, technically the load balancer even)
which is only accessable via HTTP or HTTPS. Feeding bad commands is
always a risk, no matter what - but you could figure out how to setup
an IDS system or something to only accept POST/GET without exploitable
characters or anything. Suhosin type things come to mind.

But again - the only way to get data would be if you craft something
and use SQL injection or something to get the data out. You couldn't
exploit code to download a trojan or something because the application
server cannot talk to the Internet. I think it is a compartmentalized
setup that would solve my original question...

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to