Автообновление CMS
У Бирмана встретил на сайте его движка блогов «e2»:
Рекламируют автообновление:
Если смотреть на систему непредвзято — она действительно хороша. Первое, чем она вас встретит — это автоматические обновления: пожалуй, уникальное свойство в мире CMS. Она сама скачивает с сайта разработчика заплатки и новые функции и сама же на себя их устанавливает.
Я действительно гений. После того, как я это сделал в 2004 году, это стало появляться и в других веб-приложениях.
в 2003-м появилась TimeLabs CMS, хорошая система для тех лет, с контекстным меню, автообновлением, модулем, позволяющим создавать произвольные типы данных (причём более гибко, чем в «Битриксе» даже сейчас), безопасным логином (через JavaScript SHA1), гибкой системой прав, системой контекстной помощи, PHP cron, AJAX-модулем общения админов (админка была расчитана на IE) и так далее — интересных особенностей там была куча.
Система прав, локализатор и модуль файла конфигурации сейчас используется в Lixil CMS, а миниязык блокировки по IP — в проекте KVNru.ru. Так что часть системы жива и сейчас, не говоря уже о том, что до сих пор существуют сайты на этой CMS (скриншот взят с одного из таких сайтов).
Это об отсылке по HTTP при авторизации не пароля as is, а его hash’а, если включён JavaScript?
Комментарий для bressergey.com:
Отсылается пара sha1(pass + salt) и ID salt в базе. Включен ли JS меня не волновало — он должен быть включен, иначе с админкой работать просто не получится.
Комментарий для Евгения Степанищева:
А, ну это о том, о чём я подумал.
Спасибо (думал что-то упустил).
Комментарий для Евгения Степанищева:
А salt генерится каждый раз при загрузке формы с логином и паролем?
Насколько хорош (или плох) вариант, когда отсылается пара md5(md5(pass) + salt) и salt, причем salt действителен в течение N часов, а в таблице хранятся md5(pass)?
Комментарий для written.ru:
salt генерится каждый раз, а назад (в данных формы) приходи не salt, а идентификатор salt в базе (или salt кладётся в сессию). В любом случае, salt нигде не передаётся в открытом виде.
Salt в окрытом виде чуть более секурно, чем plain password, причём величина этого «чуть» зависит от популярности проекта.
Комментарий для Евгения Степанищева:
А как тогда javascript сгенерит sha1(pass + salt)?
И еще, после того, как пользователь залогинился, в запросах (или через cookies) нужно что-либо передавать (salt или его ID)? Или проверять ip, с которого идут запросы?
Комментарий для written.ru:
Salt содержится в данных от сервера.
Комментарий для written.ru:
В запросах передаётся идентификатор сессии, больше ничего. Если вы расчитываете, что закрытой части будут обращаться пользователи с dialup, то IP лучше не контролировать, я использую данные браузера (user-agent, te и так далее).
Я тут обнаружил, что ответил не на тот вопрос, который вы задали, а на то, что было у меня в голове. Salt надо удалять из базы сразу, как только был произведён login или по timeout. Причём важно, чтобы система проверяла — есть ли salt на момент логина в базе.
Сам salt передаётся с сервера, обратно я возвращаю только ID salt в базе и sha1(pass + salt). Это усложняет атаку, так как нужно сопоставлять пришедший с сервера salt и его ID в данных от клиента и слушать трафик в обе стороны.
Комментарий для Евгения Степанищева:
Теперь понятно. Я примерно так и делал. За исключением одной детали — у меня salt совпадает с идентификатором сессии. В общем, подумаю на досуге, что там можно переделать.
Комментарий для written.ru:
Переделывать особо нечего — можно поместить salt в сессию, делов-то.
Комментарий для Евгения Степанищева:
Мне сначала надо понять смысл этих изменений, что я и постараюсь сделать на досуге :)
Пока мне непонятно вот что.
1) Если злоумышленник будет просматривать мой трафик, когда я залогинился в CMS, то ему будет достаточно перехваченного идентификатора сессии, чтобы совершить какие-либо действия в моем сеансе.
2) Если будут перехвачены данные, отправленные из формы, когда я залогинился, из них всё равно пароль (или его хеш для используемого мной md5(md5(pass) + salt) и salt) достать не удастся.
Учитывая эти два факта, зачем нужно обеспечивать защиту salt’а и не передавать его назад на сервер в открытом виде?
Комментарий для written.ru:
1) защита от задачи зависит. вариантов несколько: например, можно смотреть не работают ли одновременно два IP с одного логина (у меня так и было), если да — оба отрубаются. если не расчитывать на dialup, можно контролировать IP. Ну и конроль характеристик браузера немаловажен.
2) чем сложнее, тем лучше. выше вероятность, что возиться не будут, это я знаю по себе.
Кстати, что я вспомнил. У меня salt ещё и к IP привязывалась.
оо, старые знакомые)) как люди, так и сиэмэс
Комментарий для saetov.com:
Всех знаешь? :)