31 мая 2010 в 16:49
Доброго времени суток!
Решил создать эту тему, потому что как правило темы создаются когда сайт уже ломанули и владельцы пытаются выяснить как.
У мну тут же немного другой интерес, есть сайт X, например, смотрим его html, и по коду обнаруживаем, что сделан он на Drupal... и тут начинается самое интересное.
По опыту - владельцы сайтов, заказывающих разработку на Drupal, в упор не хотят осознавать, что кроме разработки так же требуется последующее квалифицированное сопровождение сайта. По аналогии с автомобилем, купил машину - ганяй на СТО на обслуживание, нет - гарантия снимается, за поломки отвечаешь сам. Ясно, что от этого машина меньше ламаться не будет, но в случае серьезных поломок есть куда предъявить претензии. Так и здесь, заходишь иногда в админку сайта, на страницу обновления и... ядро версий 3-5 назад обновить надо было бы, то же с модулями, вся страница рябит красными предупреждениями. Ну с этим все ясно, google в помощь и ищешь последние уязвимости и методы их применения.
А как обстоит дело со взломом свежих разработок или сайтов, владельцы которых следят за обновлениями? С чего стоит начинать? Есть определенные алгоритмы применительно именно к Drupal? Если есть интересные ссылки на материалы, поделитесь плз. Я как-то давно встречал книгу на эту тему по Drupal, но думаю она уже устарела...
Заранее благодарен!
PS Понимаю, что взлом сайтов - вещь мало привязанная к конкретному движку, можно задать вопрос по другому - слабые места в Drupal?
Комментарии
Вы случайно не перепутали сайты?
Может вам на хакер ру?
Случайно и не случайно не перепутал. Если я буду знать как сломать свои сайты на Drupal, я буду так же знать как их защитить, что и Вам рекомендую, это второе, а первое это то, что я с большим удовольствим попробую сломать сайт одной конторы, которая по моему мнению, мягко скажем, публикует в интернет неправдивую информацию. Если сказать точнее, то и Вам потом захочется это сделать))))
"Cлабые места в Drupal?"
"Жадный заказчик" + "студент-разработчик" + "скромный бюджет" + "сжатые сроки" = "самое слабое место у Друпала" X)))
Я бы сюда добавил - "и на старуху бывает проруха", но хотелось бы чего-то более конкретного.
Ага.
Плюс логин: admin и пасс:admin или flvby.
Это универсальный кейген)))
У сайта на Друпале запросто могут быть дыры в безопасности, когда программист по незнанию или невнимательности неправильно определяет права доступа в своем коде, также если забывает фильтровать данные перед выводом и т.д. и т.п. Также если в коде нет защиты от подделки межсайтовых запросов...
А еще часто встречаются владельцы сайтов (причем даже серьезных), которые не меняют пароль админа (или фтп) после создания сайта. Т.е. пароль остается, например, таким лажовым как "1234567" или "admin". И логин для админа почти у всех имеет название "admin", как-будто нельзя назвать как-нибудь по-другому, например, "Администратор самого классного сайта". Да и доступ к странице user/1 почти никто не закрывает.
О, вот это разговор посерьезнее.
Если программер неправильно определяет права доступа в своем коде... т.е если сайт спроектирован на скажем так широко распространенных модулях с drupal.org, то тут ничего не светит.
поменять admin на что-то другое - не уверен, если взломщику(т.е нам) не составит труда прочитать хеш пароля, что сложного в том, что бы прочитать незашифрованное имя юзера-1
Я тоже как-то отдельно не закрываю доступ к user/1, набрал адрес, на всех сайтах 403. Напрашивается вопрос: зачем закрывать и как?
"Cлабые места в Drupal?"
Правильнее было бы сказать так: "Слабые места разработчиков сайтов на Друпал"... И от этого плясать...
Какая нахрен разница, какой логин?
Правильнее было бы правильнее сформулировать вопрос. Например: "Методы защиты сайтов на друпал от взлома". И от этого плясать. Просто формулировка конкретно про взлом, несколько настораживает
Ничего личного, но обычно методы просты. Есть соответствующие сайты, где публикуется список уязвимостей тех или иных систем, в общем-то, вся война сводится к тому, кто быстрее: взломщик, который использует эту уязвимость или системный администратор, который поставит фикс. Обычно взломщик успевает.
Не стоит так же забывать про то , что друпал не работает сам по себе, а использует обычно связку apache(куча уязвимостей)+php(туда же)+mysql(то же самое).
Все вышеперечисленное относится к системам, которые не имеют постоянного мониторинга и фиксов выявленных уязвимостей.
Я бы не упирался в формулирование вопроса, суть остается та же. Это вопрос из области: скальпель хирурга спасает жизни, но может стать и орудием убийства, или все та же сага о хакерах, это взломщик или компьютерщик-специалист с глубокими знаниями... а так как все на форуме в основном увлечены глубоким познанием Drupal(поправьте если я не прав), все зависит от конкретного применения этих знаний.
Или например Вы качнули нуленный Битрикс, для того что бы разобраться в алгоритмах программы, фактически это нарушение прав интеллектуальной собственности, но если это Вам необходимо для создания модуля или расширения функционала....... по большому счету на Вас в этом случае всем наплевать, это Ваше дело. Кстати 1С уже дошел до понимания того, что надо открывать API для создания модулей сторонними разработчиками, глядишь скоро и код официально откроют;).
Короче, для тех кто воспитывался на классике советского кинематографа, и Юрий Деточкин положительный герой, угрызения совести останутся на заднем плане))
Понятно, с уязвимостями Drupal это да, по уязвимостям LAMP тоже уже обзавелся литературой...
Хотя по Drupal есть вопросы: каждая разработка имеет определенный набор модулей. Допустим глупо искать уязвимости модуля views, если этот модуль не установлен и не использовался в разработке.
Как я понимаю в таком случае нужно более-менее выяснить структуру системы, какие модули используются. Если не включена агрегация css и js, кое-что можно увидеть в html, некоторые модули например транслитерация, pathauto можно определить проанализировав урлы сайта. Кое-какие модули можно определить просто исходя из функционала сайта.
Какие еще подходы применимы для определения структуры?
и второй вопрос, выше прозвучало, если разработчик неправильно дает разрешения... какие есть методы определения этой уязвимости?
Наоборот, по-моему, здесь риск больше.
Как вариант, через
hook_menu_alterизменить колбек доступа, прописанный в модуле user.Так вам и рассказали.....
Не надо давать такой информации...
с чтения УК РФ
здравая мысль
народ, у вас паранойя, сами читайте свой УК РФ, на нашей территории он не действует
если бы жили в белоруссии или в китае, вообще бы в интернет боялись бы заходить?
С хромого качаются?
пасиб, Толь, посмотрю, обещают, что можно ) Я думал что-то удалённое хитрожопое ) Это локально, не страшно )
Ребят, из тех, кто юзает Комод, какие впечатления? Есть минусы и плюсы, сори, что не по теме ресурса и вообще не в той теме спрашиваю.
О программке. Она собирает только те пароли, которые юзер сохраняет в браузере?
Хочу сделать скриптик, который бы проверял, что юзер не сохраняет свой пароль в браузере. Иначе ругать...
ололо, кулхацкеры наступают
Да тут постоянно, то хакеры, то специалисты по информационной безопасности
Странно. Нечего сказать - пройди мимо. Думаю кроме Вас специалисты еще есть.
поддакивающим и соболезнующим: есть вопрос, который как не формулируй, но касается косвенно всех.
Глубокие мысли типа "ололо"... даже не хочется продолжать...
А те, кому реально есть что сказать, и без вашего "ололо" разберутся. Тем более перед этим порыл в поиске, взлом Drupal-сайтов не такая уж и экзотика. Axel даже предлагал Drupal.ru сломать....
я даже подозреваю, что когда то созданный поддомен xaker.drupal.ru именно для этих целей и предназначался
какая-то странная тема. ну забили заказчики на секьюрити апдейты, ну поимели закономерный результат. что обсуждать-то??
а если есть желание ломать чужие сайты, то в этом случае более актуальна тема -- как сломать чужой сайт, не сломав, при этом, себе обе ноги.
А что странного? тема безопасности, только не со стороны владельца сайта, а с другой...
не очень понимаю про ноги, но очевидно если имелось ввиду "замести следы", это одно, про это тоже есть что почитать, а если это намек на ответственность, то я выше писал, этот вопрос не сильно беспокоит.
И такой еще момент интересует, при использовании(создании) тем в html шаблонах добавляются php скрипты, насколько реально найти бреши на этом участке?
А еще тут куча троллей и спецов, которые кроме вьюсов о Друпале почти ничего и не знают...
Ну, я имел в виду, что разработчик по ошибке может дать расширенные права для обычных пользователей...
По-моему, чем сложнее и навороченнее сайт, тем больше шансов, что есть какие-то недостатки, т.к. срабатывает человеческий фактор, когда даже опытные разработчики могут допускать ошибки. Ведь если писать километры кода, то всегда найдутся ошибки. Тут от тестировщиков многое зависит...
А если сайт простой как валенок, то, конечно, там и риска меньше, ибо функционал стандартный, проверенный временем.
Не-не-не, я против тебя ничего не имею. (Брату не рассказывай ничего!!!)
Я вьюс не знаю... *плачу*
ололо
Как правило, в шаблонах ничего кроме вывода переменных не должно быть. Но можно, например, забыть очистить переменную перед выводом.
Например, переменные объектов $node, $user ($node->title, $user->name и т.п.) нужно пропускать через check_plain, что кто-то запросто может забыть сделать...