RE: Re: [PHP] Are there free http mysql tunneling writed in php ?

> -----Original Message----- > From: Wolf [mailto:lonewolf@nc.rr.com] > Sent: Thursday, June 05, 2008 10:49 AM > To: Boyd, Todd M. > Cc: php-general@lists.php.net > Subject: RE: Re: [PHP] Are there free http mysql tunneling writed in > php ? > > <!-- Snip --> > > I seem to have hit a nerve. Sorry for explaining best practices when > I feel they're applicable. > > > > If you read through the archives, this same type of thing comes up > about every other month. That and the "I want to know how to do this" > where there is no PHP involved and/or no PHP code posted that is > actually being used (such as how come I'm getting an empty variable > from a strtolower call). > > So, a bit of a nerve if you read the FAQs and such attached to the join > the list page (at least last I looked), it talked about these same > things. > > If you take code from the list and don't test it and put in your own > security practices, you are asking for exploitation as this list is > rife with spammers and such. So when someone gives a brief "do > something along these lines" in some bit of code, it's normally a fore- > gone conclusion that it's expected the one using it to be responsible > for their own coding and security of their code. Warning: Getting a tad bit off-topic here... I have read through (some of) the archives, and I have scanned the "join the list" page. I am not some mailing-list-autistic user who jumps from forum to forum and steals the thunder of the list's regulars. However, I have noticed that security is often left unattended with regard to coding examples, suggestions, and the like. In one of my database systems classes, the professor didn't even explain the steps one would take to encrypt a password so that it isn't tossed around as plain text. I don't see the point in replying to someone's question with a solution that is completely open to vulnerabilities (and not touching on the fact that it is vulnerable). I don't mean buffer overflows and the like, but suggesting that a user create a PHP script that accepts almost-literally anything as input and is translated directly to SQL baffles me. Why not just suggest that a user eliminate passwords to simplify their login code? If security concerns are never mentioned, then mobs of coders come to the front lines ill-prepared to deal with security. This is one of the reasons that SQL Injection (which is INCREDIBLY easy to safeguard against) is such a rampant occurrence on the web nowadays. Tutorials explain forms without even a casual mention of HTTP Splitting. Programmers suggest code for Javascript data sanitizing without alluding to the fact that server-side sanitization must also be performed in order for it to truly matter. Et cetera... I understand that code submitted to this list should be taken with a grain of salt, and your own best practices should be applied before the code is run in a production environment, but... jeez, dude. Calm down. PHP is predominantly a language for programming web applications. Web (or even just networked) applications require security above and beyond that of local applications, and I don't see the harm in my suggesting to the OP that he take a different route... or at least take steps to secure the method in question. If secondary or tertiary posts to answer a user's question containing security tips are not welcome, then I will desist; but it seems counterproductive to the programming community as a whole to leave these topics undisturbed. Yes, as you said, the user is responsible for the security of their own code. They are also responsible for their own code itself--which you have given suggestions as to the nature of. I am merely giving suggestions as to the nature of the security of that code. I don't feel that this is violating any guidelines for this mailing list (or any programming-related mailing list, for that matter, without a specific "security" counterpart), and so your "DUH" was taken as offensive and unprovoked. If this was not the case, well, then let's let bygones be bygone. In fact, I don't care about that either way--but I do care that my security-related suggestion was squashed as being irrelevant to the list. Todd Boyd Web Programmer