Безопасное программирование в PHP

12345; UPDATE users SET password='0' WHERE login='admin'

Что выйдет? Все верно, MySQL получит запрос (соединение-то уже установлено) и выполнит запрос на обновление пароля пользователя admin. После этого заходим этим пользователем с паролем '0' и можно считать задачу выполненной.
Для защиты необходимо экранировать пользовательский ввод. Это значит, что все специальные символы предваряются специальным символом "\" или заменяются. Для этого существуют функции:
mysql-real-escape-string 
Для библиотеки собственно mysql; mysqli-real-escape-string для библиотеки mysql; и addslashes для общего случая.

Почти всегда предпочтительнее первая, но иногда может пригодиться и вторая (когда хочется экранировать не все, например, для расширенного пользовательского поиска). Я лично вторую применяю в системах, ориентированных на заведомо добросовестных пользователей (да, бывают и такие) - например, какая-нибудь система администрирования для работы в узком кругу разработчиков некоторого проекта. Но бдительность терять все же не стоит и в таких случаях.


Оборона тыла

Бывают ситуации, когда даже хорошо написанный скрипт все равно приводит к взлому. Такое может случиться, если сама система настроена неверно. Это может быть ОС или веб-сервер. Или сервер БД.
Опять же, пример:
У нас есть 2 файла:

/www
    |
    +---database.inc
    |
    +---script.php

И script.php, скажем, выглядит так:

<?PHP 
include("database.inc");
//далее работа с БД
?>

Собственно, database.inc нужен для соединения с БД. Казалось бы - все хорошо и удобно, не нужно по нескольку раз в скриптах писать строки соединения с БД. Но опять же хитроумный пользователь вводит в строку http://наш_сайт/database.inc 
И что же? Да ничего хорошего. Пользователю просто отобразится этот файл, и все. Просто потому, что веб-сервер не знает такого типа файлов (в большинстве случаев) и предлагает его скачать. Ну а зная пользователя и пароль к БД можно много чего сделать.

Как защититься? Во-первых, не использовать невнятные расширения для подключаемых файлов. Подключайте просто *.php, и все. Во-вторых, все без исключения файлы, которые не предназначены для просмотра, выкладывайте в каталог, который попросту не доступен веб-серверу. Например, в каталог, который в дереве каталогов выше, чем корневой каталог веб-сервера. 
Иногда советуют использовать .htaccess файлы для запрещения доступа к таким файлам. Но я уверен - зачем так делать, если у нас есть универсальное решение? Решение с .htaccess я бы назвал скорее следствием, решением надуманной проблемы. Сильно сомневаюсь, что без всяких там хитрых *.inc не обойтись.

Далее - пример для БД. Здесь чаще всего проблемы с безопасностью возникают, когда у пользователя БД, от имени которого работает скрипт, слишком много прав. Правило номер 1 - никогда не работайте в скрипте от имени БД-пользователя root. Не нужно так делать, и все тут. Этот пользователь не предназначен для работы из скрипта. Исключения - слишком редки, чтобы так не делать. 

В остальном я бы рекомендовал под каждый проект создавать свою БД, для этой БД - одноименного пользователя и выдавать этому пользователю полные права (но без права GRANT) на эту базу. Здесь могут быть исключения, когда с одной БД должны работать несколько пользователей.

Тогда права следует раздавать так - сначала отобрать все права, а затем по мере необходимости выдавать. Тогда набор прав будет строго минимален. Затем добавлю, что все пользователи должны иметь право только локального логина (иначе говоря, пользователи с полем host, равным "%" в служебной таблице, по возможности, должны отсутствовать). Если уж и есть необходимость удаленного логина, то лучше каждый хост добавлять отдельно, избегая пресловутого хоста "%"

Теперь немаловажная составляющая - сама система. Имеется ввиду операционная система. Я уже упомянул, что UNIX-системы очень устойчивы, когда речь идет о безопасности. Но если не думать, то можно наломать дров и в таких системах. Правила я бы сформулировал так:
- Для каждого сервиса (веб-сервер, сервер БД, всякие фронт-енды, ускорители и т.п.) создаем отдельного пользователя, группа у всех одна (например, daemon). Право на исполнение дается только для тех файлов, которые фактически должны выполняться (а не просто chmod -R 755). Права "7" - полные права, стоит выдавать только на те каталоги/файлы, которые не могут иметь других разрешений. Как пример - каталог, куда мы принимаем файлы от пользователей (хотя сам по себе такой каталог - потенциальная брешь, подумайте почему).
- Использовать chroot для корневого каталога системы. Это надо на случай взлома - тогда хакер получит доступ только к веб-части нашего сервера, а не ко всему ему.
- Логировать самими скриптами все необычные действия пользователей. Иначе говоря, если все делалось правильно, и была отловлена попытка (не важно, случайная или злонамеренная) взлома, администратор должен быть уведомлен. Желательно так, чтобы пользователю ничего не отображалось при этом.
- Все php-сообщения об ошибках должны быть отключены. Ведь зная ошибки, хакеру по ним можно узнать структуру системы. А это облегчает задачу взлома. Тестировать систему, правда, я настоятельно рекомендую со всеми включенными ошибками. Идеальная ситуация - программа доведена до состояния, когда даже при всех включенных ошибках она не выводит даже Notice в любых случаях. Но даже в этом случае нужно отключать вывод ошибок, когда программа предоставляется пользователям.

С уязвимостями этого типа можно встретиться у не слишком озабоченных безопасностью хостинг-провайдеров. И скорее всего, вам не дадут это исправить, так как администратором системы будете не вы. Что тогда делать? Менять хостера. Просто и понятно.