Forum Moderators: coopster
The day started off with Bruce Perens, I found it funny that minck posted this today
[webmasterworld.com...]
they gave away a bunch of signed copies at the end of the conference.
He talked about open source books actually, he talked about software patents laws in the united states and really just the open source community and its problems and strengths.
He was absolutely fascinating to listen to, I didn't learn anything per se but he managed to make me feel very guilty for not being more involved and just generally made you feel part of something bigger. Which is very important when we all sit in our little offices coding and forget that all the open source products we know and love need a little help too.
We then saw Christian Wenz
He did, hands down, the best demonstration of sql injection and cross site scripting (XSS) I have ever seen. For people in the room who hadn't really played with it much I am sure they were more than a little surprised.
After lunch we saw Chris Shiflett
He did an outline of how a PHP security audit would be structured and what he generally looks for when doing an audit. The plan he outlined was encouraged for use in a peer review system, which is much less expensive than going out to get an audit by a company.
his presentation is available here
[brainbulb.com...]
we then heard from Chris Hubbard who talked about advanced data manipulation. Also a very knowledgeable fellow and I thoroughly enjoyed his presentation as well.
Things that I walked away thinking about
[badboy.com.au...] - an interesting testing tool, I have been looking for one of those.
[phpclasses.org...] - Chris Hubbard's validation class
"security by obscurity is not the answer" - I think all of the presenters mentioned this, I have commonly referred to this as security by obfuscation but it means the same thing
"most tutorials and code posted in forums is filled with security holes" - and yes I have already started looking at my own, and yes, I am an idiot sometimes.
"filter input, escape output" - yeah I knew this but will be much more vigilant about posting it.
"if you need to strip or decode you are doing something wrong" - I found this interesting, I don't really use those functions
things that should always be turned off in php.ini on a live system
register_globals
allow_url_fopen
display_errors
magic_quotes_gpc
all makes sense, though the fopen one was interesting, if someone gets through then they can't open a url to pull nasty things onto your server, tricky.
sending data to your db is output - never really thought of it that way
all http headers and the $_SERVER superglobal array are input, not to be trusted
"log all data that failed validation input in your forms" - now, I actually do this but I thought a lot of people may not.
I am going to be much more vocal in the forums regarding security I think. It just seems silly that we know this but don't always pass it on to new coders.
I urge you all to read every line in Chris' presentation because it gives you a bunch of things that you can look for even in your own code.
I would be interested in everyone's feedback as I don't think we talk about security enough.
As you say there are some really commonly known facts about the security that are on everybodies tongue, but still people (me included) say one thing and do another :-)
Thanks again for sharing this with us.
Re badboy: this looks very cool, it's a new sort of concept for me, this kind of software, "Web testing software" I guess is what you call it. I had the need for something to sort of record stuff as I browsed and wrote something that saved the source and other selected stuff for each PHP request, but this is a whole lot more advanced.
On those fopen url wrappers - PHP didn't allow for remote includes until PHP 4.3, after "register globals" was off by default. However, allowing remote includes and running non-security conscious code (old code in my case, very old code) with register_globals on is a script kiddies' dream - I got one site hacked this way. Fortunately, few files had server-writeable permissions, so the script kiddie did only minimal damage and lost patience. I have yet to come across a script that requires remote includes. In a way it's a pity that there aren't *two separate flags* here - one to allow reading and writing remote files (which can be really handy), and one to allow remote includes (which is sort of pervy, you can imagine the contorted code sequences it would create). But if you don't have to read and write remote files, yeah, this flag is best turned off. Unfortunately this isn't even a per-dir flag, so you can't plop old scripts into a dir with this turned off.
magic_quotes_gpc off: a good idea if you're only running your own code. However, this could be a huge security hole if you're running code that was wrtitten with magic_quotes_gpc on and didn't get audited properly. But running with magic_quotes_gpc on can also be a security problem for code that was written with it off, and unchecked. I think the best is just that standard internal check of all incoming parameters at the beginning, which strips slashes if necessary. (ergophobe thinks that I strip slashes for a living, I think - recursively if necessary)
<edit:> Schifflet suggests using htmlentities() for escaping HTML - I use htmlspecialchars(), don't believe (in most circumstances) all entities need to be translated -
Note, another thought: If you don't consistently always use double quotes in your HTML, and, e.g., at some point have user-input that goes inside, e.g., an alt or title tag that uses single quotes, you'll also have to stipulate which quotestyle you want when using either htmlspecialchars or htmlentities. Otherwise your user could enter something like
' style='position: absolute; top: 0px;
I've approached PHP from a how-to perspective, trying and hoping that I'm doing enough for security. That's the first presentation I've seen that describes the very basic necessities for good security - much easier to understand than reading it at php.net. I'll make a copy to carry with me, and read it whilst sitting under a shade tree by the swimming hole ;) When I get back there will be plenty to do.
I am going to be much more vocal in the forums regarding security I think. It just seems silly that we know this but don't always pass it on to new coders.
Perhaps the powers-that-be can start a "PHP Security" forum so we can separate the how from the why. Thoughts?
Thoughts?
One of the things that makes WW such an attraction is the discovery of the real gems. The best of them often make it into the forum library. I'd personally prefer to mine only one library for PHP gems.
magic_quotes_gpc
This is an area in which I changed my ways in the past year or so. I used to always want this set a certain way (on, because I was lazy), and posted about it a few times here in the forum. I have sinced changed my ways and always wanted to go back in time and be an evangelist -- oh well. This thread in particular on Magic Quotes! [webmasterworld.com] ... I should forward people from that one to this one on security -- I never leave magic_quotes_gpc On any longer. I would rather control and monitor it ( getting less lazier? Or getting smarter? hehe ). I always keep them both Off now and make sure I am editing and controlling user input and output.
I am going to be much more vocal in the forums regarding security I think. It just seems silly that we know this but don't always pass it on to new coders.
I agree wholeheartedly on the security concept within the forum here, too. I'm as guilty as the next person when it comes to just helping somebody over their issue as opposed to making sure they are securing things properly (particularly validating input/output). On the flip-side to that comment, I have noticed more and more members catching and suggesting when they notice issues, register_globals being the most obvious.
"if you need to strip or decode you are doing something wrong" - I found this interesting, I don't really use those functions
Could you be a bit more descriptive here, jk? I'm curious where they went with this (I'm thinking along the lines of all the CMS packages out there that folks use that are HUGE security issues, unless edited and stripped properly. Can you offer a bit more on what was discussed?
put it this way, the user enters the data, then it is changed before we get it, if you are a new coder it can maybe help a bit but for us old crotchety coders, we don't need it and it will only make us lazy. The data that was submitted is also changed when you get it.
There was some stressing of never changing data, which I agree with. You need to validate the data, not make it conform to your rules.
>> strip or decode
to be honest by the time I wrote it down we had moved on. I had a moment of thinking "huh?!", but it was quick, it mentioned using native functions like mysql_real_escape_string instead of using addslashes and not using stripslashes or urldecode at all.
It struck me and then slipped by, sorry. It is something I have thought about a fair bit though. I really don't use those functions so what am I doing differently, not sure, I porbably have to go through a few thousand miles of code to see.
>> can start a "PHP Security" forum
I see part of the issue being that we consider a different topic, it needs to be inherent in the way we code. One idea, we could pick a few of my posts, because I wouldn't subject anyone else to this torture, and analyze the good the bad and the ugly of the posted code.
I am thinking particularly of library posts, I have found a few that should be shot. ;)
It is all about trust, who do our applications trust, what data can be trusted?
What is input and what is output?
When we use code snippets or scripts from another source have we analyzed them sufficiently to be sure they are secure?
how about for an initial excercise we try analyzing a post of mine and let's see how stupid we can make me look. Give ma a bit of time and I will link to it here.
put it this way, the user enters the data, then it is changed before we get it, if you are a new coder it can maybe help a bit but for us old crotchety coders, we don't need it and it will only make us lazy. The data that was submitted is also changed when you get it.
Exactly my point, too, maybe I wasn't clear enough -- I was lazy ;-)
Thanks for the explanations, jk, and thanks for taking the time to share what you heard. We appreciate it.
PHP Peer Code Review [webmasterworld.com]
] not using stripslashes or urldecode at all
Not using stripslashes -> what are you going to do when some less-bright-than-you-are admin turns magic quotes on behind yer back? I don't like the whole slashes thing either, but just checking for magic_quotes and conditionally stripping slashes isn't so much work really
Not using urldecode -> what then are you supposed to do with data that goes in url parameters?
From his lecture I really did like the emphasis on filtering input with the means meant for *that specific type of input*, and the same for output, and not just using generic means or cobbling stuff together.
] security forum
I'd also be afraid it'd get a little dead. There was a whole site dedicated to PHP security a while ago (saw it still exists: [phpadvisory.com...] ), I think put together by some French guys, and it remained real inactive except for rss feeds from security sites on new exploitabilities. C.S. can keep his stuff good and active, but then again that's his primary focus in PHP, I doubt we'd have enough good stuff often enough to merit a forum.
One thing that would be nice is a thread (put together some good posts, all together, as few as possible 'me tooish' posts) we can link to on some standard security issues. When I posted here more often I'd often find myself vaguely mentioning, "and make sure you clean your input", "and make sure you make those strings database-safe", etc., probably with most newbies wondering what on earth I was griping about. Maybe one thread on security and input, another on security and output. You don't really want to explain each of these issues again and again, and occasionally you'll also want to give code examples where the "security" part isn't present, so some nice'n easy links would be welcome.
something to add to the library to get things started perhaps.
never use extract() on superglobal arrays
never use $_REQUEST - I haven't found a use for it yet in 5 years
Using extract on superglobals: one well-known content management system, not so long after 4.1 was released, added to its list of features "it works with register_globals off". But what did it do? Just extract GET and POST at the beginning of the script. Last version I saw still used this tactic.
Others, like geeklog and oscommerce, in the last versions I've seen, still required register_globals to be on. Ok, it's not very nice security-wise, it's a little antiquated. But in a way it's more honest than the script I mentioned above, and they're more likely to take care of this problem properly when they do get around to it.
[phpsec.org...]
