Русское сообщество fluxbb

hcs

Гость

Повышение уровня безопасности

Суть простая и уже неоднократно озвученная:
Перенос админ-центра в отдельную директорию и закрытие директории через .htaccess
Этот шаг закроет доступ к админ-центру любому, и даже угон куков админа не поможет. Это надёжно.
Но при этом остаются незакрытыми: модерирование (перенос, удаление, закрытие тем); управление пользователями.
Здесь несколько сложнее, поскольку управление пользователями, в отличии от модерирования, в закрытый каталог не положишь. Но и модерирование прятать в каталог слишком накладно.
Поэтому есть мысль кроме проверки рефереров при модерировании, еще проверять ип того кто пытается это сделать. При таком раскладе злоумышленник угнавший куки модератора-администратора, опять не сможет ничего сделать, т.к. ему придется пройти авторизацию.
Остается последняя проблема - ХSS, когда ип остается прежний, куки прежние, но форма отправляемая на сервер - подставная. Здесь основной заслон выполняет проверка реферрера, но теоретически если на форум предварительно закачать нечто специальным образом подготовленное (используя какую-нибудь дыру в какомнибудь моде), то подделка реферера становится делом техники.
Я не хочу сказать, что описанный выше вариант с подделкой рефереров сильно реален, но всё-же это вполне возможно  при неблагоразумии администратора, он может стать жертвой незнания или неумения или идиотизма при сборке форума из модов и конфигурирования сервера. 
Хотелось бы снабдить ядро инструментом, который делает невозможным и этот тип атаки. Есть мнение что этого можно достичь используя уникальный код , добавляемый к формам модераторов, злоумышленник не сможет снабдить свою подставную форму этим кодом и получит при ее отправке отлуп.  Так можно дойти до использования сессий.
Какие есть мнения?

SDTux

Гость

Re: Повышение уровня безопасности

hcs, по пунктам:

Перенос админ-центра в отдельную директорию и закрытие директории через .htaccess

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

есть мысль кроме проверки рефереров при модерировании, еще проверять ип

По-моему, это слишком накладно, да и как ты себе это представляешь на крупном форуме, например, где более 10 модераторов?

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

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

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

artoodetoo

Гость

Re: Повышение уровня безопасности

Есть мнение что этого можно достичь используя уникальный код , добавляемый к формам модераторов, злоумышленник не сможет снабдить свою подставную форму этим кодом и получит при ее отправке отлуп.  Так можно дойти до использования сессий.

Видел такое в ExBB Full Mods. Правда поначалу там постоянно возникали накладки типа "вызов скрипта нелегальным способом". Сейчас вроде все устаканилось. Абсолютно реальный метод, только требует аккуратной реализации. Существующий confirm_referer слабоват. Когда я эксперементирую с ЧПУ, приходится постоянно его править. Код в форме решил бы эту заморочку.

Есть реализации с очень жестким контролем по доп. коду. Например, в админпанели на хостинге peterhost.ru нельзя возвратиться назад по истории - код следующей формы перестает соответствовать. Для возврата на каждой форме есть специальная кнопка "возврат" - тогда следующий код проходит верификацию.

hcs

Гость

Re: Повышение уровня безопасности

По-моему, это слишком накладно, да и как ты себе это представляешь на крупном форуме, например, где более 10 модераторов?

Я не знаю накладно это или нет, а представляю себе так, как это взяли на вооружение, если не ошибаюсь на slaed cms, а именно - дополнительное поле users.last_ip. Изначально ип тот, который был при авторизации. Если модератор производит манипуляции, то сравнивается его текущий ип, с тем что в базе и если ип разные, то предлагается авторизоваться. Вот и вся защита. Ну тут конечно будет очень жаль тех, кто на разных компьютерах работает, с разных адресов. Для таких случаев можно завести лист.
Идея не супер, но хоть что-то.

Добавлено  01.28.2007 16:01:22:

Видел такое в ExBB Full Mods

Ты не мог бы дать ссылочку?

artoodetoo

Гость

Re: Повышение уровня безопасности

http://tvoyweb.ru/forums/index.php?c=3

SDTux

Гость

Re: Повышение уровня безопасности

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

Вот я, например, из дома хожу, с работы и с сотового (у оператора пул ip не маленький).

Я не говорю, что все так плохо и делать такого не надо, но нужно просто и такой вариант учитывать.

Есть реализации с очень жестким контролем по доп. коду. Например, в админпанели на хостинге peterhost.ru нельзя возвратиться назад по истории - код следующей формы перестает соответствовать. Для возврата на каждой форме есть специальная кнопка "возврат" - тогда следующий код проходит верификацию.

А вот это уже интереснее, ИМХО.

artoodetoo

Гость

Re: Повышение уровня безопасности

Перенос админ-центра в отдельную директорию

В версии 1.3 такое заложено. Правда неизвестно когда эта версия станет стабильной. Опять же перенос плагинов...
hcs, ты тестировал свежие версии 1.3dev ? админка там очень интересная

hcs

Гость

Re: Повышение уровня безопасности

Нет, свежие версии не тестировал

S1B

Гость

Re: Повышение уровня безопасности

Поделюсь опытом. Появилась необходимость создать форум, но свой движок ещё не готов, поэтому решил заюзать сторонний. Итак, выбор пал на PunBB, однако так как форум посвящён информационной безопасности - защиту пришлось доработать. Что сделал:

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

2. Вырезал нафиг поддержку SHA в авторизации (для удобства). Оставил только MD5

3. "Засолил" пароли в базе данных. Т.е. пароли хранятся примерно с следующем виде: MD5(соль.пароль). По идее, даже при использовании SQL иньекции и при несанкционированном получении пароля, его расшифровка будет весьма затруднительна (читать невозможна (при незнании соли))

4. Cookies привязал к IP + засолил другой солью. В итоге можно забыть про XSS атаки + даже зная хэш пароял - авторизироваться будет затруднительно.

5. Поставил на админку дополнительную авторизацию.

Всё. Ещё можно:

1. Сделать сверку MD5 сумм всех скриптов форума (запускаему по крону). В случае чего - админу придёт e-mail / sms.

2. Вынести файлы за пределы папки доступной из инета.

Жду комментов )

Добавлено  01.30.2007 12:01:05:
Забыл ссылку: www.forum.secbun.info

artoodetoo

Гость

Re: Повышение уровня безопасности

S1B, вроде все разумно, кроме отказа от SHA - не понял чем оно меshaет.

Меня еще одна вещь смущает: на большинстве форумов и прочих штук с авторизаций форму регистрации делают с галочкой "запомнить меня".
На punbb эта фишка вынесена в профиль пользователя. Как говорится "лучшее - враг хорошего". Если я присел за чужой комп, я наверняка забуду разлогиниться и мои куки останутся на чужом компе! С галочкой в логинизации как-то проще, imho.

hcs

Гость

Re: Повышение уровня безопасности

S1B
Можно пункты 3 и 4 осветить подробнее, включая код?

mrrc

Гость

Re: Повышение уровня безопасности

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

AuthType Basic
AuthName "NeTAMS Administrators Only"
<Files admin_*.php>
Require user admin
</Files>
AuthUserFile /usr/local/etc/passwd

Так ведь тоже можно сделать?
Единственное, у модераторов не будет доступа к некоторым доступным им элементам меню админ-центра, но это можно решить путем указания в значении Require user файла .htaccess  помимо admin-а еще и логинов модераторов, а можно попросту запретить доступ модераторам доступ в админ-центр, либо указать в директиве <Files файла .htaccess только те файлы admin_*.php, которые необходимо запереть ото всех, кроме админа, только какой должен быть там синтаксис при этом, я не понял.

padizar

Гость

Re: Повышение уровня безопасности

Простите за офтоп. А где можно почитать как грамотно перенести админку в отдельную папку?

hcs

Гость

Re: Повышение уровня безопасности

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

artoodetoo

Гость

Re: Повышение уровня безопасности

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

Griffon

Гость

Re: Повышение уровня безопасности

А возможно написать плагин, который будет редактировать .htpassword? )

hcs

Гость

Re: Повышение уровня безопасности

artoodetoo
обычно файл паролей шифруется, я с открытым хранением сталкиваюсь впервые

mrrc

Гость

Re: Повышение уровня безопасности

либо указать в директиве <Files файла .htaccess только те файлы admin_*.php, которые необходимо запереть ото всех, кроме админа, только какой должен быть там синтаксис при этом, я не понял.

Никто не знает, как в .htaccess можно указать сразу несколько файлов подлежащих защите паролем в директиве <Files>?
Чтобы в нашем случае имелась возможность выборочно ограничить доступ к определенным инструментам админ-тула.

Griffon

Гость

Re: Повышение уровня безопасности

а так тебя на устраивает?

<Files ~ "^admin_">

mrrc

Гость

Re: Повышение уровня безопасности

т.е. смысл такой, насколько я понял.

AuthType Basic
AuthName "Authorised User"
<Files ~ "^admin_bans|^admin_categories|^admin_forums|^admin_groups|^admin_loader|^admin_maintenance|^admin_options|^admin_permissions|^admin_prune|^admin_ranks">
Require user admin
</Files>
AuthUserFile /usr/local/etc/passwd

Кстати, а каково предназначение файла admin_loader.php в группе инструментов админ-тула?
Может также имеет смысл использовать .htaccess в папке plugins?

Редактировался mrrc (2007-01-31 16:15:57)

FireFly

Гость

Re: Повышение уровня безопасности

в файле паролей (AuthUserFile) подразумеваются незашифрованные пароли. обнаружил совершенно случайно
закодированный пароль не прокатил - от балды впечатал в файл пароль открытым текстом - сработало

Если я не ошибаюсь, то расшифровка хешей производится средствами сервера. Есть утилиты, позволяющие создавать хеш-файлы с паролями в md5.

Редактировался FireFly (2007-01-31 18:06:23)

artoodetoo

Гость

Re: Повышение уровня безопасности

Инструкция на сайте моего хостера - это для тех, кто совсем не знаком с защитой по паролю.
http://peterhost.ru/instr3_9.shtml
в предпоследнем абзаце есть ссылка на шифратор под Windows. с помощью него создаем файл .htpasswd и сливаем его на Unix-хостинг.
под локальным денвером пароли шифровать не надо

обычно файл паролей шифруется, я с открытым хранением сталкиваюсь впервые

я сам обалдел очевидное невероятное.

S1B

Гость

Re: Повышение уровня безопасности

S1B, вроде все разумно, кроме отказа от SHA - не понял чем оно меshaет. smile

Просто не хочеться возится и делать два алгоритма "засаливания" паролей. Поэтому SHA ввырезал как ненужный геморой. ИМХО его вообще можно из кода исключить, ибо не практично. SHA шифрование всего несколько версий PHP поддерживают.

Можно пункты 3 и 4 осветить подробнее, включая код?

С кодом не могу - я не за своим компом. Да и не помню куда изменения внёс

Суть такая:

В конфиг ложиться две переменных соль первая и вторая. В переменных задаётся что-ибудь типа - "hd3#)#((3KD_27DFVB@^!!!DDA" - чтоб никто не догадался

Далее. Все пароли в БД шифруются по умолчания по принципу MD5(пароль). Мы же делаем MD5(соль1.пароль). Соотвественно вносим в код изменения, чтобы при регистрации автоматически добавлялась соль, а при авторизации чтобы она учитывалась и т.д. Идея надеюсь ясна. При реализации пришлось немного потанцевать с бубном, ибо разработчики тоже там намудрили чёрт знает что... Поэтому пришлось переделать функции так, чтобы при вызове SHA энкодера подсовывался MD5 хэш. Ну а чтоб форум подмены не заметил - там в некоторых местах изменить длинну хэша в проверке пришлось с 40 на 32. Надеюсь поняли.

Чего мы всем этим добились?

1. Вырезали SHA, чтобы не мешал. Надеюсь я убедил Вас в том, что он мешает?
2. Сделали пароли криптоустойчивыми. Т.е. допустим у юзера стоит пароль "12345". По умолчанию, если хэш пароля попадёт не в те руки, пароль можно будет расшифровать за пару секунд. После нашей модификации хэш пароля будет содержать что-то типа "hd3#)#((3KD_27DFVB@^!!!DDA12345". В данном случае, при незнании соли (а чтобы её узнать - нужно иметь доступ к чтению файлов на сервере) хэш можно колоть до скончания веков. Т.е. даже применив SQL иньекцию - сложно чего-либо будет добится.

Что касается привязки к IP - тут всё просто:

При создании куков (читать - при авторизации) мы помимо всякой "ерунды", ложим вторую соль (чтобы было сложно расшифровать куки) + IP адрес посетителя. Далее, вносим измения в функции проверки куков. Нужно выстроить их так, чтобы при провереке куков опеределялся текущий IP пользователя и сравнивался с IP из куков. Чего мы таким образом добъёмся? Мы добъёмся одного - даже при получении cookies (читать - при проведении XSS атаки, либо при выдирании кукисов с компьютера жертвы) злоумышленник ничего не сможет с ними сделать, ибо на его компе кукисы работать не будут (разве что они с одного IP сидят, но ведь коллеге по работе всегда можно дать в нос )

Вообщем так. Куда ещё подробнее я уже не знаю. Удачи в защите форума Если есть вопросы - ICQ #4124477 и e-mail [email protected]

И ещё - добро пожаловать на наш форум: www.forum.secbun.info Всегда рад обсудить вопросы безопасности web-приложений там.

Редактировался S1B (2007-02-01 09:14:14)

artoodetoo

Гость

Re: Повышение уровня безопасности

При создании куков (читать - при авторизации) мы помимо всякой "ерунды", ложим вторую соль (чтобы было сложно расшифровать куки) + IP адрес посетителя. Далее, вносим измения в функции проверки куков. Нужно выстроить их так, чтобы при провереке куков опеределялся текущий IP пользователя и сравнивался с IP из куков. Чего мы таким образом добъёмся? Мы добъёмся одного - даже при получении cookies (читать - при проведении XSS атаки, либо при выдирании кукисов с компьютера жертвы) злоумышленник ничего не сможет с ними сделать, ибо на его компе кукисы работать не будут (разве что они с одного IP сидят, но ведь коллеге по работе всегда можно дать в нос )

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

hcs

Гость

Re: Повышение уровня безопасности

Не вижу смысла в такой привязке ип к кукам, это уже паранойя, любого достанет. Достаточно проверку ип производить при доступе к профилю\админке или отправке данных в профиль. Таким образом если есть 2 компа с которых человек ходит, как например у меня, то можно спокойно отвечать в темах, но смена данных уже будет требовать авторизации. Опять же, можно сделать лист доверенных ип-адресов.