Теоретически возможно ли взломать такой скрипт:

$a=$_POST['a'];
echo $a;

Теоретически даже <?php ?> можно взломать. Проверяй регулярными выражениями, приводи к типам. Вообще научись задавать правильно вопросы

awers, ты прав, вопросы формулирую я фигово.

Переформулирую: Что нужно учесть при работе с переменными.

На что нужно их проверять, в том числе при работе с базами данных.

m1kle, зависит от того, что происходит с этой переменной.

• SQL-запрос: предусмотреть, чтобы переданные в этой переменной символы не могли изменить исходный вид SQL-запроса.
• Запись в файл: если файл впоследствии подключается, проверять чтобы не было возможности записать в файл произвольный PHP-код.
• Отображение в HTML-коде: удалять теги, способные нарушить верстку или внедрить скрипты в HTML-код страницы.

Зависит от конкретной задачи. Сначала переменная приводится к типу, с которым работает приложение(например $var всегда int), а потом проверяется на возможное вхождение неправильных символов.
Обычно, для всяких идентификаторов достаточно (int)$variable.

Canarat, пункт два, вообще-то, если под словом "подключается" имеется в виду include, вообще не имеет смысла. В том плане, что если не должно быть РНР кода, то и подключать ничего не нужно. 
Пункт один лучше переформулировать по-другому. Ни за какими символами следить не надо. А надо выполнять два правила
1. Переданные скрипту данные оформлять в соответствии с синаксисом SQL
2. В случае, если динамически формируются управляющие конструкции запроса, то подставлять их только из заранее прописанных в скрипте.

m1kle, вопрос все еще "фигово сформулирован", увы.
"При работе с переменными" ничего учитывать не надо. Сами по себе переменные никакой угрозы не несут. 
В каждом конкретном случае защита осуществляется по-разному.
Про SQL я уже написал. подробнее можно прочесть здесь PHP FAQ:  \"Кавычки \". Cоставление запросов, слеши, SQL Injection
если передается что-то, что будет использоваться в качестве имени файла, следует использовать регулярное выражение или функцию basename()

Feldmarschall, собственно про SQL, я все-таки склоняюсь к более абстрактному и общему взгляду на этот пункт. Неправильно сформулировал:
Никакие посторонние данные не имеют возможности изменить вид SQL-запроса

А насчет подключения, я лично правил скрипт где был подобный код:

и я не думаю, что это какой-то особый случай у начинающих PHP-программистов.

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

Sannis, по-хорошему, шаблонизатор не должан использоать eval.

Canarat, "более абстрактный и общий взгляд" не дает никаких практических рекомендаций по защите, и даже намеков на них. И, следовательно - бесполезен.

По поводу же приведенного кода, опять же - надо исправлять причину, а не следствие. то есть, бить по рукам тому, кто так пишет.

Feldmarschall, каюсь, я привел теорию, но не привел практику. От общего к частному, дедукция, Ватсон.

А насчет этого кода - то что исправлять надо причину это очевидно, но когда есть код в приложении, для которого ты пишешь модуль - сильно не развернёшься.

Ещё раз - существуют ситуации, когда напыщенность типа "я не буду работать с таким паттерном, ибо он не соответствует моим религиозным воззрениям" будет только вредить, и поэтому придется подстраиваться.

ошибки надо не называть паттернами, а исправлять

Feldmarschall, если кому-то не нравится Singleton или Factory - их надо удалить? Здесь я подразумевал именно паттерны, и субъективное отношение к ним.

а если мы, допустим закачиваем файлик (статью уже в готовом html-е), а затем подключаем её?

Не понял смысла вопроса.
Ты спрашиваешь, можно ли вывести в браузер файл, не используя оператор include?

нет, допустим контентщик составляет страничку у себя, потом её закачивает через <input type="file", а страничка затем инклудится.
что-то типа ленты новостей, но более красочно (замена скриптам, типа fckeditor)

по факту такая система существует, всё равно же надо проверять, здесь код php может быть введён напрямую без всяких ухищрений

Я не погу понять.
То ли ты думаешь, что include интерпретирует HTML код, то ли не знаешь о функции fopen или readfile

такая система делается либо через шаблонизатор более высокого уровня(к примеру, Smarty). Переданные данные сохраняются, а потом вставляются в нужное место шаблона. Либо же через readfile и иже с ним, что побыстрее, но негибко с точки зрения контентщика(либо же программисту-создателю придется продумать кучу вариантов и предоставить контентщику кучу параметров). В любом случае, максимум, чем грозит такой подход - XSS и прочие проблемы безопасности на стороне клиента(связанные с опасностью для целосности дизайна и приватной информации конечного пользователя). PHP не инклюдится.
да и в отношении HTML-кода и связанных с его использованием уязвимостей - существуют и применяются решения:
1. контентщик использует код, который контроллируемо транслируется в HTML(BBCode, к примеру). HTML-код преобразуется в сущности.
2. содержимое, которое будет вставляться, заранее разбито на блоки. контентщик вводит разные блоки без указания форматирования. затем при выдаче, разные блоки имеют разный дизайн. часто, кстати, используется при высокой формализации содержимого(например, объявления на доске, состоящие из заранее определенного количества полей). HTML-код преобразуется в сущности.
3. strip_tags gjpdjkzпозвказать список тегов, которые удаляться не будут. таким образом можно обработать HTML-текст, выбросив из него все, кроме <b> и <i>(к примеру). впрочем, способ тупой, потому как не удаляет аттрибуты у разрешенных тегов, потому в них(в атрибуты) вполне можно вставить javascript-код. упомянул только потому, что пару раз сам использовал и хотел бы предостеречь от такого варианта.