Пишу, по большей части, про историю, свою жизнь и немного про программирование.

Автообновление CMS

У Бирмана встретил на сайте его движка блогов «e2»:

Рекламируют автообновление:

Если смотреть на систему непредвзято — она действительно хороша. Первое, чем она вас встретит — это автоматические обновления: пожалуй, уникальное свойство в мире CMS. Она сама скачивает с сайта разработчика заплатки и новые функции и сама же на себя их устанавливает.

Я действительно гений. После того, как я это сделал в 2004 году, это стало появляться и в других веб-приложениях.

в 2003-м появилась TimeLabs CMS, хорошая система для тех лет, с контекстным меню, автообновлением, модулем, позволяющим создавать произвольные типы данных (причём более гибко, чем в «Битриксе» даже сейчас), безопасным логином (через JavaScript SHA1), гибкой системой прав, системой контекстной помощи, PHP cron, AJAX-модулем общения админов (админка была расчитана на IE) и так далее — интересных особенностей там была куча.

Система прав, локализатор и модуль файла конфигурации сейчас используется в Lixil CMS, а миниязык блокировки по IP — в проекте KVNru.ru. Так что часть системы жива и сейчас, не говоря уже о том, что до сих пор существуют сайты на этой CMS (скриншот взят с одного из таких сайтов).

14 комментариев
tserbis (BresSergey.com) 2008

безопасным логином (через JavaScript SHA1)

Это об отсылке по HTTP при авторизации не пароля as is, а его hash’а, если включён JavaScript?

Евгений Степанищев (bolknote.ru) 2008

Комментарий для bressergey.com:

Отсылается пара sha1(pass + salt) и ID salt в базе. Включен ли JS меня не волновало — он должен быть включен, иначе с админкой работать просто не получится.

tserbis (BresSergey.com) 2008

Комментарий для Евгения Степанищева:

А, ну это о том, о чём я подумал.
Спасибо (думал что-то упустил).

parpalak (written.ru) 2008

Комментарий для Евгения Степанищева:

А salt генерится каждый раз при загрузке формы с логином и паролем?

Насколько хорош (или плох) вариант, когда отсылается пара md5(md5(pass) + salt) и salt, причем salt действителен в течение N часов, а в таблице хранятся md5(pass)?

Евгений Степанищев (bolknote.ru) 2008

Комментарий для written.ru:

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

Salt в окрытом виде чуть более секурно, чем plain password, причём величина этого «чуть» зависит от популярности проекта.

parpalak (written.ru) 2008

Комментарий для Евгения Степанищева:

В любом случае, salt нигде не передаётся в открытом виде.

А как тогда javascript сгенерит sha1(pass + salt)?

И еще, после того, как пользователь залогинился, в запросах (или через cookies) нужно что-либо передавать (salt или его ID)? Или проверять ip, с которого идут запросы?

Евгений Степанищев (bolknote.ru) 2008

Комментарий для written.ru:

Salt содержится в данных от сервера.

Евгений Степанищев (bolknote.ru) 2008

Комментарий для written.ru:

В запросах передаётся идентификатор сессии, больше ничего. Если вы расчитываете, что закрытой части будут обращаться пользователи с dialup, то IP лучше не контролировать, я использую данные браузера (user-agent, te и так далее).

Я тут обнаружил, что ответил не на тот вопрос, который вы задали, а на то, что было у меня в голове. Salt надо удалять из базы сразу, как только был произведён login или по timeout. Причём важно, чтобы система проверяла — есть ли salt на момент логина в базе.

Сам salt передаётся с сервера, обратно я возвращаю только ID salt в базе и sha1(pass + salt). Это усложняет атаку, так как нужно сопоставлять пришедший с сервера salt и его ID в данных от клиента и слушать трафик в обе стороны.

parpalak (written.ru) 2008

Комментарий для Евгения Степанищева:

Теперь понятно. Я примерно так и делал. За исключением одной детали — у меня salt совпадает с идентификатором сессии. В общем, подумаю на досуге, что там можно переделать.

Евгений Степанищев (bolknote.ru) 2008

Комментарий для written.ru:

Переделывать особо нечего — можно поместить salt в сессию, делов-то.

parpalak (written.ru) 2008

Комментарий для Евгения Степанищева:

Мне сначала надо понять смысл этих изменений, что я и постараюсь сделать на досуге :)

Пока мне непонятно вот что.

1) Если злоумышленник будет просматривать мой трафик, когда я залогинился в CMS, то ему будет достаточно перехваченного идентификатора сессии, чтобы совершить какие-либо действия в моем сеансе.

2) Если будут перехвачены данные, отправленные из формы, когда я залогинился, из них всё равно пароль (или его хеш для используемого мной md5(md5(pass) + salt) и salt) достать не удастся.

Учитывая эти два факта, зачем нужно обеспечивать защиту salt’а и не передавать его назад на сервер в открытом виде?

Евгений Степанищев (bolknote.ru) 2008

Комментарий для written.ru:

1) защита от задачи зависит. вариантов несколько: например, можно смотреть не работают ли одновременно два IP с одного логина (у меня так и было), если да — оба отрубаются. если не расчитывать на dialup, можно контролировать IP. Ну и конроль характеристик браузера немаловажен.

2) чем сложнее, тем лучше. выше вероятность, что возиться не будут, это я знаю по себе.

Кстати, что я вспомнил. У меня salt ещё и к IP привязывалась.

saetov.com 2008

оо, старые знакомые)) как люди, так и сиэмэс

Евгений Степанищев (bolknote.ru) 2008

Комментарий для saetov.com:

Всех знаешь? :)