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).

In my last post, I looked at the session handling functionality that is built into the Windows Azure SDK for PHP, which uses Azure Tables or Azure Blobs for storing session data. As I wrote that post, I wondered how easy it would be to use SQL Azure to store session data, especially since using a database to store session data is a common and familiar practice when building distributed PHP applications. As I found out, using SQL Azure to store session data was relatively easy (as I'll show in this post), but I did run into a couple of small hurdles that might be worth taking note of.

He uses PHP's own session_set_save_handler to point to his custom Azure handling class with the needed methods (like write, close and destroy). He breaks it out into three simple steps, some with a bit of code attached:

• Create the database, table, and stored procedure
• Add the SqlAzureSessionHandler class to your project
• Instantiate SqlAzureSessionHandler before calling session functions as you normally would

The code for the Azure handling class can be downloaded here.

Why do SQL injections happen so often? The shortest answer is that SQL injections are so popular because of poor programming. Hackers know about the potential of a successful SQL injection attack and they search for vulnerabilities. Unfortunately, very often they don't have to search hard - vulnerabilities pop right in their face. [...] The good news is that fortunately, SQL injections are also relatively easy to prevent.

They list nine easy things you can do to help prevent the attacks:

• Patch your SQL server regularly
• Limit the use of dynamic queries
• Escape user input
• Store database credentials in a separate file
• Use the principle of least privilege
• Turn magic quotes off
• Disable shells
• Disable any other DB functionality you don't need
• Test your code

One of the frustrating things with working with MySQL is of importing large sql dump files. Either you get a 'max execution time exceeded' error from PHP or a 'Max_allowed_packet_size' from MySQL. In a recent task I needed to import a table of around a million records on a remote host, which quickly became an exercise in frustration due to various limitations on the server. SSH was of no help as changing the configuration files was restricted to the root user. My last resort was to split the huge 'INSERT' statements into smaller size files.

His script needs a little extra time to run (he sets max execute to 600 seconds) and takes the SQL file in line by line, splitting them back out to over files based on a "count" value - "dump-split-*". Depending on the size of your files, using something like this might not be an option. You might need something more like the command line "split" feature to keep it outside of PHP's memory management all together.

When I've asked people about their strategies for preventing SQL injection, one response is sometimes "I use stored procedures." But, stored procedures do not, by themselves, necessarily protect against SQL injection. The usefulness of a stored procedure as a protective measure has everything to do with how the stored procedure is written. Write a stored procedure one way, and you can prevent SQL Injection. Write it another way, and you are still vulnerable.

The short answer is "not always" but he gets into a more detailed answer with a sample login script and the SQL to create the stored procedure the "wrong way" (using the value dynamically in the SQL of the procedure) and the "right way" (assigning them directly like bound variables).

The new SDKs have not, as you can say, fallen far from the tree. While they are really great new and shiny, documentation on how to use them is still vague, missing or spread out in the internet in blogs like these, in posts from us users trying to share the information with other soon-to-be-suffering developers. So this is an example of this, i have been using these new resources and the new PHP-SDK and have ran into various walls, so I decided to start putting some of this on my blog, for 2 reasons: to spread the word, and to have notes for myself when I come back to this.

The post gives an example of using the "api" method provided by the PHP SDK from Facebook to push an array of parameters, one being the query, to the remote API for parsing. He includes the code for a simple (namespaced) helper to take in the query and return the API's return data set.

A tedious task during web development is that of database schema creation. A schema containing a few tables comprising of a small set of rows is quick, while that containing dozens of tables and large numbers of columns is a tedious process. I usually resort to a small php script with some regular expression tossed in to automatically create a schema from a text file definition. But that is a little buggy as I've to manually add the indexes and other small things. Now that Doctrine has released a DBAL library, this will provide a nice ability to automatically create sql schemas.

He introduces the DBAL abstraction layer and includes a basic script to create a schema for a MySQL database, manually adding the columns and setting up things like primary keys and foreign key constraints. He also includes the SQL statements that it will generate and execute on your Doctrine-based connection.

The SQL Azure OData Service incubation (currently in SQL Azure Labs) provides an OData interface to SQL Azure databases that is hosted by Microsoft. Another way to think about this is that SQL Azure OData Service provides a REST interface to your SQL Azure data.

He shows you how to create the SQL Azure Server, make a SQL Azure database and creating the SQL Azure OData service. Then, with that all set up, you can use this other tutorial to connect your script to this new service.

So we got an interesting use case at work where we have an admin interface to setup filters in our system. Our staff is able to enter expressions in the web interface and we have a way of checking that whatever they enter is valid or not. While trying to optimize the validation code to do stricter checking with lower overhead I ran into a little gotcha. oci_parse() function doesn't actually do validation. This was a huge surprise to me and something I didn't grok.

Frustrated by the fact that the oci_parse function didn't seem to really do much more than bind variables and prepare the SQL for insert, he searched until he came across an interesting optional flag for oci_execute, OCI_DESCRIBE_ONLY. This flag returns some explain information by default and, if the query is invalid, returns an error.

The first thing you can do to rectify the situation is to find out where exactly the bottleneck resides by analyzing the time each SQL query takes to executes. Some inquisitive people among you may also be interested in knowing in what sequence the Wordpress SQL queries themselves are being run.

His method of benchmarking the SQL for the application uses some of the built in query logging in WordPress and some code dropped into your footer of your template to grab that information and push it back out to the waiting FireBug panel in your browser. The result looks something like this.