Before anyone assumes I’m being sexist here, I’m not. While most techy guys would prefer to have techy girls being gaming graphic designers who just wear cool Linux t-shirts, I don’t. I tend to like working with women in the IT field more than most men, because there’s usually less of a pissing contest. A lot of guys don’t like to admit they’re wrong, or ask for help in an area that they sometimes try to convey themselves as an expert in. I on the other hand, do. So do most of the women I’ve worked with. This makes the working environment much more comfortable, and each of us more receptive to each other’s ideas and input. That being said, forget about me being some macho nerd who feels the need to try and oppress women programmers.
CodeGrrl.com is a website focusing on PHP scripts and tutorials written by a handful of women contributors. Their user base is mainly women who run their own personal or community driven forum sites, and use CodeGrrl scripts to allow their site visitors to interact more dynamically with them. Some of the scripts offered include hosting fan listings, personal FAQs, and link-exchange type scripts, to name a few. While I understand that they’re not making large scale applications to be used on commercial sites, I think they’re very cavalier in the way they handle security in their scripts. It could be that they just don’t have enough experience to address all the problems they might face, but I’m sure they’re getting annoyed with having to constantly remove or update their scripts because someone found another gaping hole in their products. I visit their site here and there to see what’s going on, and there’s almost always a notice to update one of their products due to security concerns. Now that they even have their own Secunia entry, maybe they’ll take it a little more seriously. I know they’re not writing major apps, but you always want to make sure you don’t put the people that support you, in a vulnerable situation.
In light of this, here’s a quick list of things that should checked for when writing applications in PHP or any other server-side language:
That’s a good place to start, and would probably prevent most of the security problems their products face. This wasn’t meant to be a bash on CodeGrrl or its contributors, just some constructive criticism to benefit them and their users.
Comments 5
Hiya, Sasha here, co-founder of CodeGrrl.com.
We always appreciate constructive criticism!
However, as you may have noticed, all scripts have been pulled from CodeGrrl in November 2005. They are no longer available for download, and we have made all our users aware of the security problems. A group of around 10 of us is recoding the scripts to make them secure once again, and they will be back for download only when the problems have been fixed.
The thing is, when I started CodeGrrl, I knew only a little bit about PHP and MySQL. That was almost 3 years ago. I had written a few small scripts for myself, and found myself passing them around to many people who emailed me for them, which is why I started the site, to have one point from which to distribute them, as well as a place where girls like myself could come for coding help, since every other place seemed so guy-oriented.
The scripts were just small, personal things, and with my limited knowledge, I made them as secure as possible (which obviously wasn’t enough!).
However, I never expected the site to take off in such a way. PHPFanBase has been downloaded over 100.000 times - which is far beyond anything I could ever imagine. If a script is used by a handful of people, it’s not too interesting for hackers. With thousands using it, it suddenly became interesting. The scripts were online and for download and being used for two years before problems started to arise. Only in the past year have we encountered problem after problem, because suddenly we were being targetted by hackers. :/
And the main problem is: I didn’t know how to make the scripts secure. As I said above, I’m still learning all of this myself. I am by no means an expert in PHP or MySQL, and I’m definitely not an expert in security. I’m a designer, who just dabbles in code every once in a while. So obviously, my inexperience makes it a lot harder to make the scripts secure!
We never meant to be “cavalier”, the last thing I wanted was to put people’s sites at risk. But with the limited knowledge I had, I thought things were cool - especially when two years passed without any problems.
So, with all that said, we’re working very hard on making the scripts better now. It’s a slow process (we’re all volunteers with our own full-time jobs and/or studies, and CodeGrrl is something we do in our free time without getting anything in return for it), but we are comitted to making the scripts safe. I will pass your list above on to our Staff, and hopefully this will be of some help to them.
Posted 01 Feb 2006 at 9:47 am ¶The loggedinyes thing was part of my script which I released far too quickly. I put out a patch for that but unfortunately it never got released because it just so happened that that day the other insecure scripts were taken down. I have fully reworked my script though - rest assured that there are no unsanitized inputs or largely insecure cookies like the previous one now. Double md5s are used with HTML and malicious coding being stripped out wherever possible.
In fact, I’d love it if you would go through the new version and see what you can find that’s wrong with it - I have asked the other staffers for some input but we’re very likely to have missed things (like we did the first time round). Let me know if you’d be willing to do that and I’ll send you the files.
Posted 01 Feb 2006 at 9:59 am ¶I never intended this post to be an insult on any of your abilities. I just noticed a lot of people who were experiencing problems from using your scripts. Some people were getting their accounts suspended, or their files removed, because of the problems they were having due to these scripts. Don’t think that these problems are due to poor programming ability, because they’re not. I frequently help some big commercial sites, including one I’ve posted about here before, with stuff I find. A lot of the times it’s just overlooking something small, or not realizing the bad that could be done with it. I guess not everyone has a mindset of “How could I break this?” though. I’m sure you will do better; I just thought I’d voice my concerns in an appropriate manner.
In a day or two I’ll make a post of some common tricks used to exploit common holes in various web applications. They may or may not help, but if you’re not big on security, they’ll be interesting.
Good luck with everything.
PS: I should have added “competent beta testers” to the list. It seems like most beta testers are more interested in blogging about how they have the newest version, than they are of how to break or improve it.
Posted 02 Feb 2006 at 12:12 am ¶“PS: I should have added “competent beta testers” to the list. It seems like most beta testers are more interested in blogging about how they have the newest version, than they are of how to break or improve it.”
Posted 02 Feb 2006 at 4:24 am ¶Oh bollocks. Lost half my comment.
I said something along the lines of “yes, I discovered that the beta testers I picked for the old-new (2005) BB3.1 were crap and didn’t actually test it, they just installed it and ran it as normal. This is why when I finally re-did the whole script ready for release in January, I found semi-competent beta testers, and e-mailed you before I released it.” Always handy having an expert in your address book.
Posted 02 Feb 2006 at 4:27 am ¶Post a Comment
Feel free to use formatting, such as <strong></strong> for bold text and <blockquote></blockquote> for quoting text.