On Wed, Jun 23, 2010 at 12:43 PM, Peter Lind <peter.e.lind@xxxxxxxxx> 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 file. 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
