If you've been thinking about starting a local technology user group in your area but have been looking for some guidance, you should definitely check out this recent post from Joe Ferguson with some good "dos" and "don'ts" around groups and organization.

When I introduce myself before I give a talk at a conference or a user group I mention I am a user group leader and very passionate about community. I happily receive questions from people starting new user groups or reviving old groups.

I wanted to share a recent response I sent to someone today who was asking for advice about their meetup group: Congrats on jumping into the world of running a UG. A lot of this is “in my experience” so your milage may vary

He starts with the "dos" (like keeping it small to start and making meetings consistent) and "don'ts" (not to worry about sponsors and making the talks "conference level" every month). He also includes an interesting section about "protecting" your user group, preventing things like over-zealous recruiters from coming in and giving people a bad impression of the group. He also links to lots of other resources you can read and participate in to make you a more effective user group leader.

On the NetTuts.com site there's a new post talking about protecting your keys when using a public site like GitHub. This relates to an easy thing to forget - removing hard-coded credentials from code before pushing it public.

In December 2014, Slashdot ran an alarming story Bots Scanning GitHub To Steal Amazon EC2 Keys, based on developer and blogger Andrew Hoffman's experience trying out Ruby on Rails on Amazon with AWS S3. He inadvertently committed an application.yml file with his AWS keys. [...] It's an easy mistake and most of us have probably done a similar thing at one point or another. And it's not just AWS keys that are at risk. As our use of cloud-based services increases, the expanding use of a broad variety of service API keys can be leveraged by hackers and spammers alike.

He goes through a solution he's found to help protect those credentials, in this case working with the configuration of a Yii framework-based application. He starts with a mention of .gitignore but points out that it could have unexpected results from "quirks" in its handling. He suggests a different option - using a configuration file that lives someplace outside of the main git directory and can be referenced directly from inside the application. He provides two kinds of examples: one using a PHP-based configuration and another based on an INI file. He finishes the post with a mention about WordPress plugins and the fact that they're (usually) stored in a database and open to exposure if a SQL injection vulnerability is found.

The PHP.net site as new post with some supplemental information for those users of the PHP CGI that might be effected by the recently announced bug, the reason for the most recent release. Unfortunately, this patch only fixes some of the cases of the problem, so they've amended their instructions to included a more effective mod_rewrite rule to help protect your applications.

PHP 5.3.12/5.4.2 do not fix all variations of the CGI issues described in CVE-2012-1823. It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues. Again, people using mod_php or php-fpm are not affected.

The rewrite rule is there in the post, ready for copy and pasting into your config. Even if you're running the latest PHP 5.3.12 and 5.4.2., be sure to use this rule as a stop-gap measure for now. Another release is planned for tomorrow to fully correct the CGI flaw.

In a recent post to his blog, Gonzalo Ayuso shares a few tips on preventing SQL injection attacks on your applications.

Security is a part of our work as developers. We need to ensure our applications against malicious attacks. SQL Injection is one of the most common possible attacks. Basically SQL Injection is one kind of attack that happens when someone injects SQL statements in our application. You can find a lot of info about SQL Injection attack. Basically you need to follow the security golden rule: "Filter input, Escape output".

He advocates the use of the PDO abstraction layer to filter out a lot of the issues. Using its prepared statements, you can easily strip out things that just adding slashes to user input wouldn't prevent. He also includes a reminder about database permissions - allowing only certain users the ability to, for example, delete can help provide one more level of security (in other words, don't use a "super user" in production).

Artur Ejsmont has a new post with a passionate call to arms for anyone who thinks that just because their URL has "https" in it, it's secure. He presents his suggestion on how to properly secure SSL API calls for your PHP application.

Lets make something clear from the very start: JUST BECAUSE THERE IS https:// IN THE URL OF THE REMOTE SERVICE IT DOES NOT MEAN THE CONNECTION IS SECURE! I am sorry for the tone of this post but i am enraged by how popular this issue is online. If you ask why i suggest a little experiment [involving changing your hosts file and using a self-signed certificate].

The issue he spotlights is all too common - a server serves up SSL pages but doesn't actually verify the certificate in the process. He gives a bad example of how some scripts handle this issue using the CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST to turn off this verification - a very bad idea. To protect yourself from any kind of man-in-the-middle or DNS hijack issues, you should leave these on.

New on DevShed.com today is a tutorial helping you optimize your file downloading for your web application and provide a way to give users dynamic links to files instead of direct ones.

The true path to the downloadable content can be revealed easily and is not protected, allowing users to bypass web forms and download the content directly using a browser. [...] The Solution: A Secure and Efficient PHP Download Script

This tutorial is actually an update of their previous tutorial looking at a similar subject, with a few differences. Their code provides a way to limit the files a user can download, the number of times they can download it and a script to read the file and push it to the user without them ever knowing the path.

From Script-Tutorials.com there's a new post that wants to help you prevent one of the biggest menaces of the social online world - spam. Their solution uses the Akismet service to detect possible spam and notify you.

What is spam? – this is (usually) any message which not relevant to this page – usually just an advertisement of something (and even with a backward link to another site). Yes, you can put the first line of defense – a captcha, but I think spammers are also ready for this and find ways to avoid the CAPTCHA (or, they even can solve its by self). In today’s tutorial I’ll show you how to create a second line of defense against spam - using web services - for example akismet.

They include all the code you'll need to create a simple interface to the Akismet system with the help of this library that handles a lot of the connection and messaging for you. They apply it to a comment form and check the POSTed values against the Akismet spam checking. You can download the full package to get started immediately.

Gonzalo Ayuso has a new post that can help you protect certain files inside of a public folder by combining mod_rewrite and PHP.

Here's the problem. We have a legacy application (or a WordPress blog for the example) and we want to protect the access to the application according to our corporate single sign on. We can create a plug-in in WordPress to ensure only our single sign-on’s session cookie is activated.

In his example, he shows the handling of an uploaded file and a plugin that can be used to protect parts of the site based on session information. Unfortunately, by itself, this doesn't prevent the direct access of the file. His trick is to route all file access back through a central "media.php" script that fetches it from a file location (could even be outside the docroot). The routing to the PHP is handled via mod_rewrite and the code checks the permissions on the current user's session for access.

In a new post on phpRiot.com Quentin Zervaas shows you how to use ionCube Encoder to help protect the applications you've written and their source code.

One of the issues PHP developers face is that PHP is an interpreted language, meaning PHP source code is readable by anybody who downloads your applications. In this article I will show you how to protect your intellectual property by encoding your PHP source code.

With the help of the encoder to can convert your plain-text PHP files into something that only the end user with the correct loader setup can use. He includes a simple "hello world" example showing the before and after of using the encoder. Also included are the commands to encode and decode the scripts manually if you want to handle it that way.

New on the ITNewb.com site today there's a tutorial looking at making your forms a bit more "spam free" without resorting to CAPTCHA images.

Most anti-spam methods used by websites today are annoying at best. They use impossible-to-read captcha images, or they make users jump through some kind of hoop to get the email address instead of just clicking on it. This can mean lost sales and opportunities for you, because each hurdle turns away more users.

The trick uses some CSS and Javascript to hide a form field (display:none) and check on the submit to ensure that it's empty. The email address is the output of a Javascript document.write() as well, preventing those pulling the information off of your site without Javascript support (like some automated tools) to miss it completely.