новое    архив    фото    Харьковские сети    login   


дата   09-09-2009 19:44:20



Безопасность веб-сайтов и окружающие эту безопасность вопросы постоянно возникают при обсуждении CMS. (CMS – это система управления контентом: программный комплекс, исполняющийся большей частью на сервере и обеспечивающий публикацию материалов на сайте, а также удобное управление этими публикациями из веб-интерфейса.) Безопасность, как “сигнальный объект”, вообще очень популярна. И, конечно, “референсы” на “безопасность” используют при продвижении тех или иных CMS (которые, кстати, бывают коммерческие и бесплатные). Что тут нужно иметь в виду конечному потребителю, не желающему стать лёгкой добычей маркетологов? Оказывается, достаточно составить хоть и весьма общее, но строгое представление об этих самых вопросах безопасности и их связи с CMS. Скажем, конечному пользователю весьма важно понимать, насколько “безопасный” (тут это несколько условный термин, понятно) веб-сайт ему нужен. Потому что одно дело – корпоративный сайт крупного банка, а другое – личная веб-страничка, посвящённая разведению сазанов в домашнем аквариуме. Да, безопасность, конечно, на первом месте. Но нужно понимать, что безопасность строится на оценках рисков, и верно эти самые риски оценивать для банка и для странички про сазанов. Дело даже не в наличии уязвимостей в конкретной CMS, а в том, интересен ли сайт профессионалам-взломщикам и сколь велик будет ущерб от нарушения работы сайта. При составлении собственного представления о безопасности использования конкретной CMS нужно учитывать её отношения с уязвимостями. Тут есть свои важные моменты. Например, то, что сайты под некоторой CMS “Имярек” “за отчётный период” не были взломаны, никоим образом не означает, что “Имярек” сколь-нибудь надёжна и безопасна. Почему? Потому что отсутствие взломов сайтов ничего нам не говорит о безопасности CMS. Понятно, что сайты под “Имярек” могли быть просто не интересны хакерам. Понятно, что внутри CMS “Имярек” может присутствовать шикарная уязвимость, которую обнаружат завтра. А послезавтра для этой уязвимости хакерская группа напишет бота, и через два дня все сайты под “Имярек” будут взломаны в одном потоке, автоматически. То есть оценить безопасность “Имярека” на основании “полного отсутствия взломов” – невозможно. А если нельзя оценить безопасность, то нельзя и прогнозировать риски. И если отсутствие сведений о взломах не позволяет оценить безопасность, то информация об успешно залатанных уязвимостях (в том числе, что важно, использованных на практике для взломов) позволяет приступить к оценке безопасности CMS. Такой “парадокс”. Ведь если уязвимости обнаруживают, используют и латают, то это уже свидетельствует, по крайней мере, о том, что кто-то занимается аудитом безопасности данной CMS (хоть бы и хакеры), что CMS поработала в условиях “интереса взломщиков” и что CMS развивается. Конечно, плохо, если новые критические уязвимости обнаруживаются в CMS по нескольку штук в месяц, но ещё хуже, если об уязвимостях вообще нет сведений. Вообще говоря, более-менее надёжную оценку “уровня безопасности” CMS может дать её аудит, заказанный специалистам. Но это недешёвый и трудоёмкий процесс. Впрочем, он как раз актуален для банков и вряд ли важен для “аквариумных страничек”. Есть расхожее заблуждение, что можно “вслепую” использовать уникальную “проприетарную CMS”, разработанную специально для данного сайта небольшой дизайн-студией. Мол, “секретность” и “уникальность” внутреннего устройства такой CMS обеспечивает безопасность. В реальности же разработчики подобной CMS обычно наступают на все широко известные в кругах специалистов по взлому (и по безопасности) грабли, допуская шаблонные ошибки в архитектуре продукта. Эти самые шаблонные ошибки и станут отличным фундаментом для проведения атак даже без изучения исходного кода. Мало того, секретность исходного кода вряд ли можно обеспечить на практике: при малейшей необходимости исходники утекут. Есть много путей для такой утечки: “через хостинг”, через дыры в других программных системах, после “шаблонного взлома”. Или, скажем, исходники просто распространит создатель продукта. Главное правило таково: секретность исходного кода вообще не добавляет безопасности системе. Можно предположить, что CMS с открытым исходным кодом сильно безопаснее. Однако это не так. Действительно, открытый код доступен для изучения всем и вся. Вопрос тут лишь в том, как оценить квалификацию специалистов, изучавших этот код. Одно верно: сама по себе открытость исходного кода не может снижать безопасность CMS. Важный момент: из соображений дальнейшего сопровождения CMS, из соображений развития сайта необходимо выбирать продукт только с открытым исходным кодом (пусть хотя бы этот исходный код открывают не неопределённому кругу лиц, а только экспертам), подробное обоснование – в одной из следующих заметок. Часто приходится слышать, что коммерческие CMS якобы более безопасные, так как в коммерческих компаниях дорожат имиджем и строго следят за безопасностью. Это неверное обоснование. Да, ничто не мешает коммерческой компании делать безопасный продукт и нанимать специалистов-архитекторов ПО высокой квалификации. Однако на практике коммерческие компании старательно ограждают себя условиями лицензирования от ответственности и используют низкоквалифицированных программистов (а архитекторов не используют вовсе), потому что такое поведение позволяет максимизировать прибыль при обычно небольшом числе инсталляций коммерческой CMS. Бесплатные CMS также имеют свой имидж, которым дорожат лидеры групп разработчиков. И при этом нет никаких оснований считать, что те же программисты, приложившие руку к той или иной бесплатной CMS, не работают в коммерческих компаниях над платными продуктами. Выбирая бесплатную CMS, следует посмотреть, насколько ровно и планомерно она развивается. Нельзя использовать CMS (платную или бесплатную), которую разработчики забросили три года назад. Интересно, что при этом нельзя и надеяться на то, что коммерческая CMS не будет заброшена компанией-владельцем: коммерческие компании тоже успешно исчезают с рынка по самым разным бизнес-причинам.

добавить отзыв

дата   09-09-2009 19:46:34



Кстати, особенностей CMS касается вот какой момент. CMS, в подавляющем большинстве случаев, служат для управления веб-сайтом, который предназначен для публикации (то есть распространения) данных через Интернет – всё это очевидно. Так что “дыра”, уязвимость в CMS годится не только для того, чтобы просто “взломать сайт”. Как показывает практика, нынче уязвимость CMS оказывается более востребованной в качестве инструмента рассаживания червей и вирусов с добропорядочного сайта. Работает инструмент так: получив достаточно прав по управлению сайтом, злоумышленник скрытно размещает на нём зловредный программный код, таким образом, что он будет загружаться к посетителям сайта. Расчёт, понятно, делается на то, что посетители сайту доверяют и без лишних сомнений присланный сайтом вирус активируют. Если удачно использованная злыми хакерами уязвимость в операционной системе настольного компьютера рядового клерка компании приводит к тому, что этот компьютер начинает рассылать спам и вирусы, то это небольшая имиджевая потеря для компании. Если вирусы и зловреды начинает раздавать корпоративный сайт компании, то это уже совсем другое дело, более масштабное в смысле удара по имиджу. Более того, с рассылкой вирусов компьютером клерка админы локальных сетей могут эффективно побороться – всё ж это нетипичная активность для пользователя-клерка, легко обнаруживаемая сетевыми мониторами. В случае сайта, который специально предназначен для рассылки информации во внешнюю сеть, всё бывает не так уж и просто, обнаружить “лишний модуль” могут не сразу. А при этом механизмы автоматического обновления всё популярнее у создателей CMS. Есть “самообновляющиеся” коммерческие CMS. Для планирования рисков, связанных с корпоративным сайтом, хорошо бы знать, откуда и как получают свои обновления эти системы? Насколько надёжен канал? Когда его захватят злоумышленники, чтобы успешно рассадить трояны по многим сайтам? Всё это хитрые вопросы. Ответы на которые ещё сложнее отыскать, если используется CMS с “закрытым кодом”, работающая неясным способом и “обложенная” изнутри какими-то якобы “защитными модулями”.

добавить отзыв

дата   09-09-2009 22:46:57



Вчера пришла в голову утопическая идея: представьте, если бы женскую свойственность сплетничать (вот только не надо обвинять меня в дискриминации прекрасного пола - хотите, читайте "мужскую свойственность сплетничать") поставить на более глобальный уровень. Определенней: создается такая глобальная база данных, доступ в которую имеют только женщины, девушки, девочки. В этой базе хранятся досье на всех мужчин, у которых были какие-либо отношения с женщинами. т.е. у женщины был какой-то роман, а она бац и занесла информацию о своем партнере в базу (кем прикидывался, что говорил, его способности и т.д.). Ну так вот, представьте теперь, что Вы (мужчина) знакомитесь с девушкой, а она сразу в базу лезет - проверять как Вы относились к другим девушкам и на что способны. Это же вообще писец какой-то был бы! Ужас! А главное, что это ведь технически очень легко осуществить! Вот и приветствуй после этого технологический прогрес!

добавить отзыв

0.001384973526001