Jani Hartikainen has shared a recommendations to library authors out there - don't make your library exploitable. That is, don't make it, by default, open to common attacks like SQL injection or cross-site scripting.

SQL injection is a pretty big deal. Its cousin shell injection is also a common issue, demonstrated quite well by a recent post to the PHP reddit. Although some suspect it was a troll, I heard echos from a variety of people who had seen pretty much exactly the same vulnerability in production.

This got me thinking: People writing libraries for doing things like shell commands, SQL, etc., don’t actually have to provide an interface that can be easily mis-used. An interface like this could just as easily be based on some other data type besides a plain string, completely side stepping issues caused by concatenation. “What on earth are you talking about?” – Let me explain...

He goes on to talk about more specifically about SQL injection issues (it is still first on the OWASP list after all) and makes a few suggestions to a better API. He points out a lot of it is about little or no education on security-related topics. He also suggests a "SafeSQL" kind of interface that would help prevent some of these common issues using something like Haskell.

Jani Hartikainen has posted the second article in his series looking at parsing PHP with Haskell (part one is here). In this new article he builds on the parser he built last time and gets to the actual evaluation of the PHP code.

Last week I wrote a post about a PHP parser / evaluator I wrote in Haskell. I explained some of the parts on how the parser itself was designed to process PHP code into an abstract source tree. Continuing from where we left off in the previous part, in this post I’ll discuss the actual evaluation part.

He starts by introducing the structure of the evaluator script, how it's broken up into functionality based on the type of object/data type being handled. He uses a "custom monad transformer stack" to handle the environment for the evaluation as is progresses. He talks about handling statements and expressions, declaring custom functions and the actual execution of the function call. There's also a mention of handling conditionals/looping as well as dealing with PHP's type juggling.

if you're interested in seeing the final result (and maybe trying it out for yourself) you can find the full source on Github.

Jani Hartikainen has posted the first part of a series of articles sharing his experiences with an experiment he's conducting - trying to parse and evaluate PHP in Haskell.

The other day I uploaded a new experimental project on GitHub – A Haskell PHP parser / evaluator. It doesn’t understand 100% of all PHP syntax, but it was an interesting experiment nevertheless. Here’s some insights and other thoughts from working on the code.

He gets the "why?" question out of the way early, noting that it was mainly a desire to play with Haskell and figured parsing something he already knew well was a good first project. He also mentions the "Parsec" library that seems well suited for the parsing part of the process. There were some issues that he came across, however including dealing with PHP's weak typing and handling all of the possible incarnations of PHP script structure. He includes an example AST showing his different data structures (PHPValue, PHPExpr and PHPStmt). The next part of the series will be more about the evaluation of this structure.

The latest issue of the Web & PHP Magazine has been published - Issue #7, "Full Throttle". Articles included in this issue are:

• Introduction into scaling for Big Data: Cory Isaacson's new column
• What can developers learn from the road? - By Arne Blankerts
• How to be an open source rockstar in 7 easy steps - By Jen Kramer
• PHP security for the real world - By Michael Stowe
• Developing Web Applications in Haskell - By Patrick Brisbin
• Speed up your applications using IIS & WinCache - By Arno Hollosi

You can download this latest issue for free as a PDF as well as picking up the past 6 issues with some great PHP-related content inside.

Juozas Kaziukenas has a new post to his Web Species blog about using "lazy evaluation" in PHP - loading the resources you need for execution and evaluation only as you need them, not all up front.

Recently I needed to process a huge array of data and because of PHP's somewhat inefficient variables and especially arrays that was resulting in "out of memory" errors. However, I couldn't use any other tools than PHP so was forced to come up with a solution implementation in it. Here is how I solved it using principles from functional languages.

He gives an example using Haskell to generate a Fibonacci sequence using its built-in lazy evaluation abilities. Unfortunately, PHP doesn't have such a thing built in, so he tries the next best thing - Iterators. He caries the idea over to the database side too, recommending fetch() in a loop over fetchAll() and some effective joins.