Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy. This forum is not for asking programming related questions.
Just logged in the FTP on a really old PHP site I made and for a laugh I thought I'd see how bad the PHP was.
The first 15 lines or so were surprisingly good and then I saw this:
extract($_POST);
foreach ($_POST as $extractedpost => $tostrip) { // strip_tags and trim on all of $_POST
$$extractedpost = addslashes(trim(strip_tags($tostrip,'<p><ul><li>')));
}
Eeek!
In fact extract appear 6 times! Once on $_POST (as above) a couple of times on $row, once on $_FILES and once on $_GET.
At the time I wrote this I knew absolutely nothing about security and it shows.
Then of course I thought, why, as an inexperienced PHP developer, should one suspect addslashes() or extract() as being dangerous. They are there aren't they? Why not use them! I am now of the mind that extract() should be removed or at least trigger a notice and addslashes() should have a big fat notice in the manual saying where you can and cannot use it. addslashes() is as bad as magic quotes really.
Interestingly the main reason I used those appauling functions is because of "PHP and MySQL for Dummies" which uses them frequently in all the examples. That book is truely terrible.
That last time I did that I left the room in embarassment. I have since cleaned a lot of client sites I did early on, but hooo baby, it was some bad stuff.
Everah wrote:That last time I did that I left the room in embarassment. I have since cleaned a lot of client sites I did early on, but hooo baby, it was some bad stuff.
Haha! Well I'm confident of my abilities now so I feel no embarassment.
That is actually really funny, because I am working on a project right now, and I was going through the code and found extract($_POST);. Well I was pretty sure I knew exactly what it was, but just in case I went to the PHP website, and I thought to my self... What a huge security risk. Well my friend was right here with me and ask me what kind of security risk, and like what was said above, you can easilly send post arguments to the file and create or even change old variables.
A lot of code from the early stages of a new developers projects seems nasty. Unless that developer comes from a programming background. But in many cases people happen across PHP and begin to use it because it is fairly easy to get a hold of, conceptually. The problem is that most people use PHP to achieve a very specific purpose, something that they cannot do with javascript, HTML or other technologies. And they can get it to work the way the want it to work not understanding that there is probably a better, more efficient, more secure way of doing it.
I know I am guilty of that. My early code was all about getting done what I wanted done. As long as the syntax did not error, I was fat and happy. But as a developer begins to take development more seriously we begin to look for ways to make our work better. Then we can go back and look on what we have done and see that it was absolutely bitter-beer-face nasty.
For the last month or so I've been revisiting a site I wrote about 4 and a half years ago. The code is suprisingly good .. the HTML is a table nightmare .. but the really bad thing is the SQL. In several places I've rewritten an SQL statement to make the code about 100 times quicker.
I won't say my first scripts were bullet-proof (will they ever?) but I'm happy I've always been very, very careful and critical, even for the most basic scripts. Still a lot to learn!
But it is amazing how you read posts on forums which go like "Hi, I started with php this week so sorry if I make funny mistake but I made a portal site with forum and cms-thing, but my chat-script does not work. Can you help please? Below is my code."
And that code is put on a live server out there ....
makes me think. Isn't it very boring to be a scriptkiddie/hacker these days? Were is the challenge?
The first time i proudly released a portal application i got an anonymous (meanwhile i know who informed about it ) comment on my blog that there was a serious security hole.. So i'll share another vulnerability that occurs quite often
Since php defaults to sending text/html as content-type i think it should also apply htmlentitities to all output, unless for parts where it was explicitely told otherwise.