Padraic Brady has posted part ten in his series on the construction of a blogging system with the Zend Framework. This part of the series focuses on the commenting system and using a reCAPTCHA and Akismet system on it to prevent spam.
Blogs all have two other features besides actual content. They allow readers to post comments, and they offer XML feeds of their content. With the blog application itself coming along nicely, and with Addendum #2's revised styling, it's a good time to take a peek at adding comments.
He has created a custom Service component for the framework that interfaces directly with the reCAPTCHA service (along with a form helper, view helper and validation methods) so that an element can be added just like anything else in a form. Code of its use is included.
He works this into his comment form, including the Controller and the action that would be called. He shows how to attach an Akismet call to the form too via the framework's own service methods. Finally, he handles the other side of things - the administrative piece and displaying the (hopefully non-spam) comments back out on the post.
Matthew Weir O'Phinney has posted one of his own security tips to the Zend Developer Zone today involving the use of a database abstraction layer to help prevent SQL injections in your application.
SQL injections are a common vulnerability in web-based applications that use databases. [...] There are several methods to prevent this type of attack.
He gives three helpful hints for SQL injection prevention:
Use your database extension's quoting mechanism to quote values prior to executing a query
In this new post to his blog, Chris Shiflett helps to solve one of the problems that several web designers face when allowing user input but wanting to protect themselves as well - allowing HTML while preventing a user from including a cross-site scripting issue.
This problem comes up more and more often due to the rise of social networking and other Web 2.0 properties that embolden users. [...] Of course, BBCode inevitably comes up during these types of discussions, but I really hate the idea of using yet another markup language just because I'm too lazy to deal with HTML, especially if the markup language doesn't even try to be user-friendly.
He looks for a good solution, one that doesn't require learning a new markup or becoming overly complex (while avoiding strip_tags). He provides several chunks of code for different aspects of the method - first make the content safe, then move backwards in the translation for the items you want to allow.
On the Zend Developer Zone, there's a helpful hint for users out there running a web service to help keep things safe:
Ok, so you've written a cool new Web API and you've written l33t JavaScript to call it from your page. The problem is, anybody who views your source can see how you call your new toy and use it for their own nefarious purposes. Granted, sometimes this is what you want but there are times when you want to keep your toys to yourself. For those times, here is a quick trick you can implement that will help thwart most evil doers.
The quick trick involves the placement of a secret variable into the session after the user has been validated. The sample code to make it work is provided and and example Ajax call illustrates how it's used. Then all the API has to do is check for that value in the data passed along.
PHPBuilder.com continues their look at preventing SQL injections in your PHP scripts with this new tutorial, the third part of the excerpts from the APress book Pro PHP Security.
They pick up where they left off last time with the creation of an abstraction layer for your application to act as a go-between and filter out possible bad data. They give examples of how to use it to secure a new application, use abstraction libraries like the PearDB functionality, and how to test your application's protection.
Everyone that knows of the social news site Digg.com knows the problems that being linked on it can cause. Smaller servers get overloaded and pages can either be very slow loading or completely offline within minutes of being "digged". There's a few out there that have come up with different solutions, but several of them involve mirroring the content somewhere else. In this proposal, however, they combine the power of Lightttpd and PHP to handle the loads.
We host a wide variety of sites, covering everything from converting your garage into a living space to video game addictions. Because we are such a small operation, being hit by a link from a big site such as Digg would be both a blessing and a curse.
In order to place our ads on each page, we use PHP's auto_append_file feature to run our advertisement code. By using PHP's other neato function, auto_prepend_file, I can create a small piece of PHP code to detect when the site is being hit by Digg. In this situation, I have chosen to use Lighttpd to handle the increased loads, because of its proven high performance with large numbers of concurrent connections.
In his example code, he shows how you can detect when a user is coming from a digg.com page and take them to a cached version of the page they've requested (with the .cache extension).
Spam has grown into one of the worst problems on the internet today. It effects everyone, even those that guard their email addresses with their lives. Information spreads so fluidly in the bits and bytes of everyday communication, that it's almost inevitable for your address to get out. Once it's out, you'll know, getting emails from people you don't know offering things you don't want. One tool spammers can use, unfortunately, are the unsecured forms on your own site. Thankfully, there's articles like this one from PHPBuilder.com that can help you safeguard your site against these attacks.
Insecure PHP scripts have provided great opportunities for spammers to abuse other's resources to send out their spam. In particular, it's the mail() function that can be abused. I myself was the target a few months ago when I noticed spam being sent from an old form on my server that I'd forgotten about. This month's article looks at techniques that can be used to harden your mail form, and reduce the chances of it being misused.
They set up the simple example script and show you how to exploit it to follow the wishes of potential spammers. They offer a few suggestions on hardening the form - filtering for a correct email address, checking for "bad strings" in the contents of the form, and looking for a REQUEST_METHOD value in the $_SERVER array. The methods aren't fool-proof, but they can help to dramatically reduce your chances of being the source of a lot of people's annoyance.
Via a pointer from the Zend Developer Zone, there's a new bit of code over on CodedFX.com to help you generate a CAPTCHA image to prevent spam messages from bots in your comments.
There's two files in his example - the main PHP that does the work and a font file to pull the text from. The code is pretty straight-forward, and can almost be cut and paste into any kind of application. Working with the font file is a little tricky, but GD has built-in functionality to work with it.
The script allows for any kind of true-type font input, multiple color schemes, transparency, and the ability to angle the letters to make them harder to interpret. The resulting output from his script is a PNG image, but with a few modifications, it could create JPEGs as well.
