Massive file update with sed

Recently I generated kickstart files for a virtual environment where people could experiment and virtual machines could be rebuild quickly. Sadly enough a typo slipped into the generated files that would make the anaconda installer stop. Every kickstart file could be corrected by hand off course, but one sed command could also correct the typo in all files in one go.

$ sed -i 's/namesever/nameserver/' *.ks

The Unix toolkit is full of handy tools and options like this and it pays to get to know your environment. Specially when it is your work environment and you’re familiar with the Unix philosophy.

Starting to stop SQL-injections, part 2

In a previous posting I gave an example on how to make database queries safer by using parameter binding and basically stopping SQL-injections. The next step is to make the code more readable and maintainable. This doesn’t sound a like a priority for secure software development, but readable code is also code that can be verified and maintained by other people. It gives you the edge to debug problems quickly and invites others to supply patches. So let take the example where the previous posting ended.

$sth = $dbh_rw->prepare('select userid from accounts where username = ?');
$sth->execute(array($form_username));

For one or two parameters this may work, but when queries become bigger you need to start counting and counting beyond three is a bad idea in most cases. So let change the question mark with a named variable called ‘:username’ in this example. One could then use the function bindParam() to specify which named variable needs to be replaced and has additional features, but in this example we use the standard binding during in execute phase.

$sth = $dbh_rw->prepare('select userid from accounts where username = :username');
$sth->execute(array(':username'=>$form_username));

Please remember to use a named variable only once in a SQL-query as it will only be replaced one time and not multiple times.

Starting to stop SQL-injections

In a lot of PHP-examples strings are concatenated before a database query is being executed as below. Some examples advise to use PHP-functions mysql_real_escape_string() and/or addslashes() to make database query safe against SQL-injections. But this isn’t really a solution as when using addslashes() also requires the use of stripslashes() after retrieving data from a database. Some sites show the lack of a proper implementation and show the famous \’ string in a website.

$sth = $dbh_rw->prepare('select userid from accounts where username = "'.$form_username.'"');
$sth->execute();

Like in Perl with DBI, also PHP has PDO that allows for variables to be parameterised while executing a query as in the example below. This removes the need for home made solutions that don’t cover all usecases and allows for a way to provide a stable and more secure interface for your applications when communicating with databases.

$sth = $dbh_rw->prepare('select userid from accounts where username = ?');
$sth->execute(array($form_username));

This doesn’t stop the need of sanitizing variables like as with input from users.

Cleaning input enough?

Input validation is known issue, but writing some PHP-code today let me write the following and I’m wondering if I forgot something. It is only to make sure no cleansed variable will enter a switch statement for example.

  if (isset($_POST['action'])) 
    if (strlen(preg_replace("/[^a-zA-Z0-9-]/i","",$_POST['action'])) == 0)
      $page_action = $_POST['action'];
    else
      $page_action = '';
  else
    $page_action = '';
 
  switch ($page_action) {

For now I need to check the code that no $_POST variable is entering the code unchecked before I put the code online. This also include variables for SQL-statements to eliminate SQL-injections.