Мы будем Вам признательны, если Вы поддержите проект Open SLAED и используя Ваши возможности, разместите наш пресс-релиз на страницах своих сайтов, проектов, форумов, блогов. Текст пресс-релиза, возможно, видоизменить под Ваш формат, не искажая смысл. Пресс-релиз можно взять на данной странице.
В связи с участившимися вопросами на форуме проекта связанными с безопасностью системы считаю необходимым прояснить ситуацию и разъяснить нашим пользователям основные нюансы. Как уже писалось в анонсе версии SLAED CMS 2.1 Lite и 2 Pro, система отличается от своих предшественников повышенной безопасностью панели администратора. Даже в случае получения Cookies администратора, то есть его "Хеша" пароля и логина в зашифровонном виде, злоумышленник не сможет войти в панель администрации. На это есть ряд причин с которыми можно ознакомится при подробном просмотре.
Дополнительная защита администратора
Сохраняется последний сеанс администратора, его IP адрес в базе данных системы. Если он не совпадает, что произойдёт в случае украденных Cookies, то система потребует авторезироваться заново. Это значит что злоумышленник, не зная пароля и логина в расшифровонном виде, не сможет войти и получить доступ в панель управления.
Метод шифрования паролей, который используется в системе, является одним из самым безопасных и оптимальных на сегодняшний день. Метод называется MD 5 и является алгоритмом, который не имеет возможности расшифровки и предназначит для зашифровки информации в одну сторону без возможности её расшифровки.
Дополнительная защита пользователя
То же самое как на примере с администратором, происходит с зарегистрированными пользователями системы. За исключением того, что для пользователей можно отключить принуждение повторной авторизации в случае смены IP адреса, со дня последней авторизации пользователя в системе. Данные настройки можно изменит в отделе пользователей панели управления системой.
Ко всему этому, в системе существует возможность смены названия Cookies администраторов и пользователей, которая исключает возможность определения их принадлежности при посещения вами или вашими пользователями сайтов, где установлены скрипты-шпионы.
Общая информация о защите системы
Если вы внимательно читали рекомендации по безопасности, то сменили название файла администратора, а это значит, не зная его названия, злоумышленник даже не сможет попытаться войти в панель администрации.
Если вы внимательно читали рекомендации по безопасности, то установили доступ в систему безопасности только по определённому IP адресу, что исключает доступ злоумышленника. Узнать IP адрес администратора, а тем более подделать его почти не реально.
Если вы внимательно читали рекомендации по безопасности, то установили дополнительные пароль и логин в панель администратора системы которые защищают вас и ваш проект на серверном уровне. Этот метод паролирования директорий является одним из самых оптимальных на данный момент.
Ну и наконец, сама система безопасности защищает ваш сайт от любого рода SQL инъекций, XSS инъекций, загрузки файлов, проникновение через Cookies которые могут быть выполнены со стороны злоумышленника.
Начиная с версии 2 Pro и 2.1 Lite система исключает возможность использования HTML кода на стороне клиента и таким образом исключает все возможные попытки интеграции и внедрения нежелательного кода, инъекций, шпионов в систему.
В системе учтены все возможные и известные на сегодняшний день виды возможных атак, и приняты меры по их предотвращению.
Боле подробную информацию по упомянутым Выше темам можно получить по указанным ниже ссылкам.
Кстати, про сессии дельный совет. Т.к. я сегодня добрый, то предложу схему авторизции.
*пользователь авторизуется
*скрипт проверяет логин и пароль по бд, в случае совпадения стартует сессию, в которую пишет хеш логина и пароля + ip
*при следующих обращениях сравнивается ip с тем, что в сессии, если они разные, то просит авторизации
Плюсы: В случае кражи кукисов хакер не получает хешей и не может войти, отсутствует один запрос к бд - изменение ip.
Если же ip не меняется, то у пользователей с дин. IP проблемы
Из статьи понял, что для взлома нужно:
1 С помощью XSS получить админские куки
2 Забрутфорсить логин и пароль по MD5 хешу
3 Спокойно идти в админку, вводить полученные логин и пароль :)
Всё верно написано, за исключением не совсем корректной фразы
...защищает ваш сайт от любого рода SQL инъе.............грузки файлов, проникновениЙ через Cookies - так, наверное, по-русски. А получается что через них и надо проникать
Спасибо за Slaed.
iSage, не путайте и не переводите стрелки. Не нужно прикручивать пятое колесо к машине, в Вашем случае это сессии. Хотите продолжить дискуссию? Переходите на форум проекта.
P.S.: Иногда бывает полезно признать свою ошибку, а не упрямо спорить и доказывать необходимость пятого колеса.
Не отвечаю на технические вопросы по средствам личных сообщений
теперь понятно почему у вас так странно все написано...
делайте как хотите...
З.Ы.: по поводу только для администратора. у вас вот в статье, если прочитаете, черным по белому написано
получаеться ВЫ не знаете свою собственную систему? смешно...
Как уже говарил, Вы не знаете системы или что то путаете, запрос был есть и будет в любом случае. К тому же только для администратора. Может быть предложите сохранить Пароль и Логин админа, так же в сессиях?
Не отвечаю на технические вопросы по средствам личных сообщений
1)никто не мешает вам сессии пересоздавать.
2)на время-да, на кол-во хранимых переменных-нет
3)давайте утрировать не будем. я не предлагаю хранить все в сессиях, т.б. это бред, и нереально. я просто предложил вариант избавления от абсолютно ненужного запроса.
Не знал, что сессии обладают такими «Мега» возможностями. «Ошибочно» думал, что они имеют ограничения на время работы о количество сохраняемой информации установленных в конфигурациях сервера. Так зачем же нам тогда нужна база данных вообще? Давайте хранить всю информацию в сессиях
Не отвечаю на технические вопросы по средствам личных сообщений
22.12.2006 21:04
