Насколько я понял, любимые ухищрения хацкеров, это sql инъекция в запрос sql и XSS атака, что собой являет отображение в браузер какого то исполняемого кода, который может добавить сам сторонний пользователь. Для того, чтобы защитить SQL использовал функцию mysql_real_escape_string в запросе. А вот не совсем дошло до меня, что именно она делает. Подскажите, в самой базе, данные останутся без изменений, как и в случае неиспользования этой функции? Если я перекидываю данные из одной БД в другую скриптом, мне также нужно использовать mysql_real_escape_string?

И второй вопросик)) Возможно ли проведение атаки XSS если все что записывается в бд и потом выводится в браузер пропускается через функцию strip_tags, кроме удаления HTML тэгов <br><b>, а также регулярка убирает все что соответствует шаблону <script.../script>

Она, например, экранирует символы-ограничители строки. Если в столбец stolb нужно вставить значение o'henry и в запросе образуется кусок типа stolb = 'o'henry', то будет синтаксическая ошибка. Если написано stolb = 'o\'henry', то все будет хорошо. Ну и разумеется, не экранируя строки можно добиться более интересных вещей, чем синтаксические ошибки: если речь о вставке, то вставить такую запись, какую хотите вы, а не какую формирует php скрипт(например, зарегить пользователя со статусом админ, если структуры данных позволяют). При селектах - сделать заведомо выполнимое условие, добавить limit - и получить любую строку таблицы. Вот.
В базу, разумеется, данные попадают как есть. Экранирование не изменяет сами данные, оно их преобразует так, чтобы спецсимволы, которые в них присутсвуют, трактовались как обычные символы и теряли свои спец-способности.

Смотря, каким скриптом. Если sql скриптом типа insert select или create table as select, то не нужно. Если скрипт работает не в самой субд, а является для нее клиентом, то нужно экранировать.

В общем, избавит, но вырезание тэгов может быть не желательно. Может, я реально хочу написать Вам "<b><b><b><b>". Есть htmlentities.

А она учитывает, что после того, как убирается все что соответствует шаблону <script.../script>, то то, что получится, тоже может стать соответствовать шаблону <script.../script> ?)
шаблону <scri<script.../script>pt>realscript/script>

Кроме того я еще от себя добавлю вопрос: А учитывает ли ваш фильтр конструкции вида <b onclick="alert('XSS!');">

скрипты по типу такие же как и при добавлении в БД извне, просто источник данных другой sql запрос, предназначенный для выборки данных. Это и требовалось узнать. Значит остальные скрипты, не будет лишним экранировать при помощи mysql_real_escape_string.
Ну если рассматривать конкретно этот случай, то мне достаточно того, что остаются b и br тэги. Для более серьезной вещи действительно полезно будет освоить возможности htmlentities

Если честно, я в ступоре. Разумеется, в моем случае, регулярка уберет правильные тэги, тем самым склеив огрызки и на выходе останется зловред. Уже понял, что не зря создал тему, только потому, что узнал о такой возможности (самому в голову никогда ничего подобного не приходило). Это нужно будет осмыслить более глубоко.

Конструкция свободно проскочила. В браузере при клике вылезает окно алерта. На форуме античата читал, в образовательных целях, как организовать XSS атаку. Первое, что предлагается, при поиске уязвимостей, это попытаться сделать вывод этой конструкции в браузер. Дальше говорилось, про кражу кук каким то перенаправлением - полность осмыслить все не смог. Ну да ладно. Пока не столь важно. Интересно, как с этим бороться?! Первое что приходит на ум, если совсем никакого желания писать это в БД, для фильтрации тэга <b>(акцент на мой случай, потому что пропускается всего пара тэгов <b> и <br>)