Я htmlspecialchars юзаю всегда при вводе в БД там где не надо сохранять код, а только текст, вывод без использования htmlspecialchars так как в базе уже данные прошедшие через эту функциюs. Все GET и даже POST запросы пропускаю через htmlspecialchars причем даже значение переданные через элементы формы такие как кнопка через параметр value, значение которого я сам прописал уже в коде (Возможно это лишнее?).
mysql_real_escape_string - юзаю когда надо сохранить допустим ссылку на сайт, так если с html кодом. Ну вывод ее конечно через htmlspecialchars если визуализовать надо.

Тобишь я все наоборот делаю? Это ошибка?

getimagesize - юзаю только jpg разрешены.

Смотри в логах, мб найдеш как сломали сайт. Давай исходники мож кто найдет что на досуге, че просто так там тыкать

http://phpforum.ru/index.php?showtopic=21213&st=0&

взглянул одним глазком, хочу сказать что htmlspecialchars не помогает от sql inj

fire

Перечитал статейку про безопасность еще раз, хотя читал ее и до того как выкладывать сайт в сеть.
Все о чем пишут реализованно. Единственное отличие что я текстовые данные в которых не нужна разметка (теги) сразу прогоняю через htmlspeserchars, и вывожу потом из базы ни как не обробатывая, т.к. уже обработоны.
Те данные где нужно сохранить разметку прогоняю черз mysql_real_escape_string, вывод их через htmlspeserchars.

Результат то один и тот же на мой взгляд, только при выводе работает быстрее не надо кучу переменных sqlrow['....'] прогонять через htmlspeserchars - идет прямой вывод из бд.
Согласен что вообщемто данные искажены, но какой смысл хранить их в несикаженном виде, если я на 100% знаю, что кроме текста в этих полях ни чего быть не должно и не будет ни когда.

например

var_dump(htmlspecialchars('/*', ENT_QUOTES) === '/*');

;)

НУ как я понял вы хотели показать эквивалентность '/*' этих двух сьрок, обработанных и не обработанных htmlspecialchars?

А в дальнейшем где это можно применить, похоже на начало коммента в php случай где это может навредить? если sql вставлять в большинстве случаев у меня идет так where `idhotel` = ".$p."
Не соображу где эта звездачка может навредить?
и как от этого спасет mysql_real_escape_string чем он отличается от htmlspecialchars только тем что один преобразует кавычки а другой их пропускает но ставит слеш перед ними.

Ха, это еще и коммент в sql тогда понятно.
Как тогда защитится от такой натписи mysql_real_escape_string, наверное тоже не спасет от такой строки?

1. Так как же защитится от таких символов, комментариев или еще каких либо злостных про которые я не знаю.
2. Ниушто Вы все (в большинстве своем) все данные из таблицы выводитет через htmlspeserchars? Это же пипец во что код превратится писать " htmlspecialchars($sqlrow['aaa']) перед каждой переменной. Неушто не легче сразу применить функцию и записать в бд данные обработанные htmlspeserchars которые наверника не должны содержать тегов, например описание объекта, города, текст какой либо?

Xes
Насколько я знаю mysql_real_escape_string обойти нельзя, просто данные вносимые в запросе обрамляй кавычками и не парься.
htmlspecialchars - я лично использую когда html-ный текст сохраняю в базу, так смысл эту функцию постоянно юзать.
а если данные в запрос приходят цельночисловые ставь (int) и не ломай голову

Xes
По-моему вот ТУТ все предельно ясно написано.

Renden
Ну например ты говоришь, как я, htmlspecialchars применяешь чтобы сохранить данные.
Но ты еше говоришь "mysql_real_escape_string обойти нельзя" так как твой запрос выглядит в конечном счете чтото типа того?

Пароль к фтп у вас сперли. Вирус такой есть.

Что вам написали в ваш index? Если там ссылка или ява скрипт который что-то подгружает в браузер, а еще чаще там фрейм, то у вас сперли пароль к фтп и никто вас не ломал ток как вы себе думаете.

Там был полностью заменен index файл. С новой датой создания.

О все наконцецто нашел различеи между mysql_real_escape_string htmlspecialchars

как я и говрил mysql_real_escape_string слешит еще и сам слеш. Просто об этом можно узанть только в английской документации в руской ни где про это не написано.
http://ru2.php.net/mysql_real_escape_string