Форум PHP

Тема с данным вопросом успешно потонула, а мыслей хоца.
Итак. Условие: форум позволяющей вставлять изображения с тругих сайтов и автоматически опознающий зарегистрированных посететелей.
Как вариант: пишем в куку логин и хеш (пароль+юзерагент). Таким образом, если даже злоумышленник попер куки, то он должен иметь в точности такой же юзерагент.
В случае открытых исходников - сводится на нет. Еще идеи есть?

Если бы безопасность была превыше всего, я бы все изображения закачивал на сервер (попутно, естественно, проверив всячески - на mime-тип, например), и выводил бы уже свои, а не посторонние. Чревато жуткими тормозами.

Ну это хорошо рассуждать сидя на форуме по программированию, а форум, например, по фотографии попросту ляжет:) Или его положат, заставив тянуть к себе и проверять свопы от винды:) Хочется понять что я упустил, если вообще у этой задачки есть решение.

>Хочется понять что я упустил, если вообще у этой задачки
>есть решение.
Абсолютно верного - точно нет:) Просто в силу того, что "Написанное одним человеком может быть понято другим". Перефразируя: как ни защищай, захотят - сломают. И весь вопрос в соотношении усилий и результата.

Все-таки хочется найти хоть какое-то решение: может использовать я его и не стану, но в голове держать буду:)

тогда уж login и хеш(сессионный ключ)
где сессионный ключ=remote_addr+forwarded_for+user_agent+random, считается в момент авторизации.

Если сделать так, то смысла что-то хранить в куках вообще нет, так как по этим данным идентифицировать пользователя можно только в течение сессии. А для этого уже существует механизм сессий.

На самом деле онлайн-сеанс может и превышать время сессии.
Но допустим для простоты, что у нас сеанс=сессии.
Вы же хотите защититься от XSS-перехвата в течение сессии?

Нет. По условиям задачки на форуме - автологин. То есть все необходимые данные для авторизации храняться у куках. Вопрос в том, легко ли эти куки спереть, и как сделать чтобы злоумышленнику их было труднее использовать?

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

Вот и встает вопрос: как опознать конкретную машину?
Ничего точнее юзерагента я пока не придумал...

Ответ: Внутри сессии - по аспектам человека, открывшего сессию. Вне сессии - никак. :( . Уж если IP неуникален, что говорить об UA, который повторяется куда чаще IP

Эх:(
Ладно... пошел ломать форумы:)

Хм... вообще если не лениться, то от любой XSS можно защититься, просто многие разработчики плюют на это дело. Можно так всё обставить, что мышь не проскочит.

хорошо, а как отловить скрипт? Тут подсмотрел варианты обхода фильтров:

<img src=javascript:alert()> <img src=vbscript:AleRt()> <img src=JaVasCriPt:alert()> <img src="   javascript:alert()"> (пробелы до слова javascript)  <img src=&#106&#97&#118&#97&#115&#99&#114&#105&#112&#116:alert()> <img src=javascript&#9:alert()> <img src=javascript&#10:alert()> <img src=javascript&#13:alert()> <img src="javascript    :alert()">  (перед двоеточием - символ табуляции)  <img src="java    scri pt:ale    rt()"> (внутри слова javascript - символ табуляции и возврат каретки)

Пока внятного решения как все это проверить у меня нет...

Пардон.... я так понял, предполагается, что html-код всё ж таки под контролем.

А если конкретней?
Исходная постановка, как я понял, такая.
На сайте стоит автологон - аутентифицирующая информация передается браузером из кукисов - как в этом форуме.
На страницах сайта также нужно формировать <img src=..> ссылки на чужие изображения.
Возможно ли реализовать это без необходимости транслировать траффик изображений через сервер сайта, не подвергая опасности перехвата кукисов серверами источников чужих изображений?

совершенно верно.
проверил на нескольких форумах - конструкция [img]javascript:alert('Превед!')[/img] приводит к желаемому результату.
Судя по всему, придется проверять ссылку на наличие вызова яваскрипта, символов &, % и задавать кодировку документа (к вопросу о следовании стандартам:)

Я вот чего не понимаю, ссылки у нас начинаются с http://, всё что не начинается с http:// от лукавого и работать не будет по нормальному в любом случае, ставим опержающую проверку, равено ли начало ссылки http и с java начинаться у нас уже ссылка уже не может.

ссылка может быть на ftp, maito, nntp а может быть и вообще относительной.

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

>ну для изображений это редкость
Опять судите со своей колокольни - для программистского форума - редкость, для дизайнеров/фотографов/художников - обычное дело.
пока что остановился на проверке наличия строк "javacsript:" и "vbscript:", а так же замене амперсандов... вроде как этого достаточно.

Хм... ну протоколов высокого уровня не так много - можно пребрать начинается ли ссылка с http, ftp, mailto, nntp...

а относительные на что проверять?:)

А че, пользователям нужно ссылаться на ваши ресурсы через относительные пути? =))

для тега [img][/img] можно сделать проверку та тип файла, то есть все кроме jpg, gif ну и чего там для дизайнеров/фотографов/художников - обычное дело.

Для этого файл придется загрузить. Так что этот вариант отпадает.

Хм... можно улучшить анализатор URL, если использовать parse_url(), она значительно облегчает построение защиты...

Зачем загружать, просто когда преобразововать теги img, делать проверку на 3 последних символа, substr($img, "jpg", -3). в таком роде...

lavascript:alert('превед!'); //.jpg

да, не подумал...

я вот чего додумал, в проверку включить кроме substr($img, "jpg", -3), substr($img, "javascript" !== false), и т.д.

Тогда отсекаются URL вида http://www.site.ru/dec/javascript/index.php.

a javascript для запуска сценария должно в начале писаться

>Тогда отсекаются URL вида http://www.site.ru/dec/javascript/index.php.
тогда проверяйте - наличие
1. http://
2. www.
если нет то на первые символы
javascript и тому подобная хрень...

Не согласен.
Идиальной защиты нет, всё что создал человек можно взломать!

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