• Prepared statements. There’s no need to concat potentially harmful data in SQL statements. Provide them as a parameter when executung a prepared statement. More efficient too.
• ORM. If you think SQL should be behind an abstraction layer, you can do so. Propel and Doctrine are the best known solutions for PHP.
• Well structured programming. If, for some reason, you want to build queries the old way you can force upon yourself (or your team) some good practices. See example below.

$dataTainted['un'] = $_POST['un'];
$dataTainted['pw'] = $_POST['pw'];
 
// escape all array values using a custom function of some sort
$dataSafe = mysqlEscapeValues($dataTainted);
 
$query = <<<SQL
SELECT
  *
FROM
  users
WHERE
  un = "{$dataSafe['un']}"
AND
  pw = SHA1("{$dataSafe['pw']}")
SQL;

And that’s just the coding part of the story. In the area of application design a lot can be done to minimize the consequences of an exploit. For example, different database users can be set up that have different levels of access. Only parts of a website needing customer data then use the credentials that do provide such access.

So, for PHP there are good practices and solutions aplenty. For more information on SQL injection one can start at OWASP or Wikipedia. And finally, the subject isn’t non-existent in .NET and JSP.