Personally, I'd rather have the error messages go SOMEWHERE useful, and write custom error handler to put "nice" error messages to the browser that reveal nothing. If things go wrong in my script/software/hardware/network, I don't want the system to just silently FAIL and swallow errors. Yes, it's remotely possible that I could manage to somehow screw up my custom error handler some day, and that would then expose things, but that's less likely than the CC server going down or the script to process the CC getting changed and messed up and passing QA somehow or... A customer error handler is pretty much a set it and forget it kind of thing for me, so I'm not really likely to screw that up and risk exposure. Whereas the processing of the form for ordering stuff and processing the credit cards seems to change all too often... The client changes their preferred shopping cart, or their Merchant or their data-gathering of non CC info or... As much as I try to separate that stuff out, they usually somehow manage to insist on some bone-headed "requirement" for the form/processing that makes me change the stuff that breaks the CC processing and while you catch THAT during testing before you go live, there still is more risk that the code you changed is somehow going to break "live" than the custome error handler you haven't touched since day 3. I'm kinda religious about the "software shouldn't silently fail" thing, though, so maybe it's just me... PS Got no idea what ob_start() does to buffer your output... Wild Guess is it just uses RAM, and if your HTML is too big to fit in RAM/swap, you are screwed. On Wed, May 11, 2005 3:14 pm, Colin Ross said: > at this point, I'm planning on (at least on production) turning off all > error reporting, I am using PEAR::ErrorStack mainly for error handling, > which I love using btw... > > all I'm trying to do is make sure that no information gets outputed from > the > script, even if some horrible error occurs, i guess i figured i could just > have it buffer output, then destroy the buffer output after... > ie. > > <?php > ob_start(); > ..... > ...... do my CC processing here > ..... > ob_end_clean();** <http://us4.php.net/manual/en/function.ob-end-clean.php> > ?> > > Maybe this is just the wrong way to think about it... In the end though, > i'd > rather error on the side of security and output no info (even on an error) > then output _too much_ info if you know what I mean. > > if the buffer gets saved into the swap file, that okay. I'm with you on > that > point, if he can read my swap.. i'm just S.O.L. and the system is > compromised, period. I was just wondering if PHP saved this kinda info in > the same style that it saves session data (under /tmp) by default, one of > the main reasons why session data should not be concidered all too > secure.... > > Colin > > On 5/11/05, Richard Lynch <ceo@xxxxxxxxx> wrote: >> >> On Wed, May 11, 2005 10:02 am, Colin Ross said: >> > I am working on a bit of code for credit-card processing, so please >> keep >> > in >> > mind, security of the data is essential.. >> > On part of it i wish to use a buffer, but i wonder if that data is >> saved >> > anywhere on the running system (as a temp file, etc), or is it just >> held >> > in >> > the system's memory? >> >> What kind of a buffer? >> >> Actually, scratch that question. >> >> There is no guarantee, in PHP, that the data in your running script will >> not be stored in swap (temp file) on disk as the script runs. >> >> It would be nice, perhaps, if there were a way to allocate memory only >> in >> RAM that could not be swapped. >> >> There are, in some OSes, low-level calls to do this, but I don't think >> PHP >> wrappers exist (yet) for them. >> >> At any rate, my point is that if the Bad Guys can read your swap files, >> you're probably already in so much trouble that the credit card numbers >> isn't your #1 concern. It is that bad. >> >> > My concern is that if an error occurs in the processing, i don't want >> that >> > buffer to remain (with possible valid Credit Card data) on the >> system... >> >> You want to catch/handle as many possible errors as you can, and work >> through them intelligently. >> >> No matter what you do, it's possible that you'll end up with a core dump >> (or similar) with your RAM including CC#s in it. You'll want to make >> this >> as unlikely as you can, but you'll also want to think about what you'll >> do >> if it *DOES* happen. Should you turn off core dumps on a production >> server? Probably, if you can. Does that guarantee that somebody (maybe >> you a year from now) trying to detect some other issue won't turn it >> back >> on, yes, even on a production server? Probably not. So, prepare for it, >> and do the right thing, whatever you think that is. >> >> Back to your buffers: It really all depends on how you build the buffer, >> and where they are allocated/stored/free'd. PHP has no data type of >> "buffer" so we don't really understand the question until you clarify >> that >> a bit. >> >> -- >> Like Music? >> http://l-i-e.com/artists.htm >> >> > -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
