?

Log in

No account? Create an account

Previous Entry Поделиться Next Entry
Безопасность сайтов… с лирическими отступлениями
ne_medved wrote in rbcsoft

Недавно я писал для одного заказчика обзорный документ по безопасности веб-приложений, после чего подумал, что было бы неплохо выложить его на общее обозрение.

Статья написана для непрофессионалов, поэтому, дабы сделать ее более интересной для притязательных пользователей, я разбавил текст некоторыми случаями из жизни.

В данном документе перечислены основные уязвимости веб-приложений и способы их профилактики, причем все уязвимости классифицированы по категориям:

  • Организационная — основой уязвимости является человеческий фактор. Устраняется при помощи определенных правил работы с сайтом или за счет специального программного обеспечения.
  • Проектирование — уязвимость непосредственно приложения. Устраняется путем учета возможности атаки при разработке (на уровне базового функционала, что позволяет минимизировать человеческий фактор).
  • Эксплуатационная — атака может быть произведена на уровне сервера или инфраструктуры, устраняется администраторами сайтов.

Аутентификация и доступ к сайту

Нестойкие пароли

Категория: организационная.

Использование простых паролей (qwerty, password, дата рождения, номер телефона) позволяет получить доступ к управлению сайтом путем перебора паролей или социальной инженерии.

В общем случае желательно использовать автоматически сгенерированные пароли, но только если есть уверенность, что человек сможет его запомнить, а не запишет на листке и повесит на монитор. В противном случае следует использовать сложные мнемонические пароли: первые буквы стихов или песен в другой раскладке клавиатуры, с изменением некоторых букв на цифры или спецсимволы.

Есть еще любимая тема оставлять пароли по умолчанию, типа root/ничего или admin/admin (в Йотовском яйце), и думать, что об этом никто не узнает. Лучше всего принудительно заставлять менять «временные» пароли при первом входе.

Перехват пароля

Категория: организационная, эксплуатационная.

Перехват пароля может быть осуществлен при передаче его от пользователя к серверу, это решается обязательным использованием защищенного соединения (https, ftps) при работе с сервером.

Я помню, Сергей Рыжиков, выступая на Хайлоаде или РИТе (точно не помню), спросил кто из присутствующих ходит на админки через защищенное соединение. В ответ было поднято не так уж много рук. Из чего можно сделать вывод, что прогулка по какой-нибудь конференции с вайфай-сниффером может немного преобразить рунет.

Кроме того, возможна кража с использованием так называемого «фишингового» сайта, т.е. сайт в браузере пользователя подменяется на идентичный, после ввода данных в форму входа, пароль попадает к злоумышленнику, в данном случае важно иметь «подписанный сертификат сайта». При использовании такого сертификата специальная компания (например verisign.com), подтверждает, что это действительно тот сайт, который предполагается. Кроме того, подписанный сертификат, удостоверяет то же самое и пользователю сайта (что важно, например при оплате). Данная услуга стоит порядка $800 в год (на стоимость влияет уровень защиты и авторитетность компании, поставщика услуги)

Меня все время удивляют организации, которые ленятся сделать нормальный сертификат, особенно в этом плане умиляет WebMoney. Слава богу, сейчас они уже сподобились это сделать (правда периодически сертификат перестает работать), но еще месяц назад меня передергивало от того, что браузер ругается на сайт, где я, между прочим, деньги держу. Ко всему прочему самоподписанные сертификаты могут вызывать разные мелкие баги: например с ними отказывается работать связка IE+Flash. Я убил довольно много времени, выясняя, почему перестал работать на продакшене мультизагрузчик, который в тот же самый момент спокойно работал себе на тестовом сервере.

Кража пароля

Категория: организационная.

Кража пароля осуществляется при помощи социальной инженерии или вредоносного ПО.
Правила профилактики довольно банальны:

  • не хранить и не передавать пароль в открытом виде, т.е. не высылать пароль на почту или через ICQ, Skype и т.д. (важно помнить, что если вы передали пароль, то он с большой вероятностью сохранится в архиве почты или хистори месенджера);
  • не запоминать пароли в браузере или FTP-клиенте (распространены вирусы, которые вставляют вредоносный код на сайт, используя сохраненные FTP-пароли);
  • использовать антивирусное ПО;
  • регулярно менять пароли.

Отдельной строкой следует заметить, что каждый человек, имеющий доступ к сайту, должен иметь свой отдельный логин и пароль, что в дальнейшем поможет выявить причину взлома и обезопасить себя в случае увольнения сотрудника.

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

Наиболее простым и элегантным способом является перенос авторизации на сервер студии, т.е. в админку сайта можно войти с OpenID (не любого, а относящегося к студийному домену). Таким образом, каждый разработчик знает только свой пароль, а разрешения на вход даются централизованно. Кроме того, решается проблема с журналом системы, в котором наконец-то видно, кто именно удалил новость, в отличие от классического случая, когда все делается от имени какого-нибудь «самого главного администратора», который является всеми и одновременно никем.

Проактивная защита

Категория: проектирование.

Определенные меры следует предпринять на уровне архитектуры сайта, они позволят частично обезопасить себя при утере пароля.

Ограничение по IP

Доступ в административный интерфейс должен быть ограничен по IP, т.е. вход возможен только из внутренней сети компании. Все прочие случаи (работа из дома, работа в командировке и т.п.) должны вводиться в виде исключений: явно указывается в какой период, в какое время (странно, когда кто-то заходит с неофисного IP в рабочее время), с какого IP (если это возможно) и какой пользователь может работать с сайтом.

Вообще-то неплохо сразу сказать «до свидания» далеким странам и анонимным прокси (если вы конечно не сайт «Кавказ-центр» разрабатываете).

CAPTCHA

 

CAPTCHA (символы с картинки) в форме авторизации позволит снизить риск того, что в административный интерфейс войдет вирус или другая вредоносная программа.

Бедой многих каптч, кстати, является неверие разработчиков в то, что пустая строка равна пустой строке, зачастую удалив сессию или почистив какое-нибудь скрытое поле, вы с удивлением обнаруживаете, что умная машина сравнила ничто с ничем, и пропустила вас дальше.

Одноразовые пароли

Также эффективным и недорогим средством является введение дополнительного «временного» пароля: для каждого пользователя генерируется матрица из случайных чисел, и при входе или выполнении критичной операции требуется ввести 2 или более числа, расположенных в заданной колонке и столбце.

В нижеприведенной схеме для входа предлагается ввести, например, число из 1-й колонки 2-й строки и 3-й колонки 1-й строки, т.е. 34 и 323 соответственно.

12

43

323

34

23

77

348

948

293

657

904

44

Данное решение позволяет сделать перехват пароля менее опасным, так как злоумышленник знает только часть матрицы.

Клиентские сертификаты

Возможно ограничение доступа только пользователям, имеющим клиентский сертификат (т.е. все запросы на сервер подписываются ЭЦП). Мы в ответе за тех, кого приручили — следя за своими персональными данными, не забывайте о персональных данных пользователей.

Выключайте автоматическое заполнение полей, в которые посетитель вводит личные данные. Меня всегда умиляет трогательная забота агрегаторов платежей за кредитки, которые оставляют autocomplete в полях номер карты и CVV2. Спасибо вам ребята, выглядит это очень мило, когда хочешь что-то оплатить с чужого компьютера.

Вообще пользовательские данные могут быть засвечены в самых неожиданных местах, несколько лет назад читалка RSS Yandex’а показывала список лент, на которые подписан пользователь, при том, что лента авторизованного в ЖЖ пользователя содержала в себе логин и пароль (http://bugtraq.ru/review/archive/2007/01-03-07.html).

Кстати, данные пользователей лучше не хранить там же, где и данные сайты, так например сайт оргкомитета Олимпиады 2014, некоторое время назад любил выводить в списке последних новостей письма от соискателей вакансий — забавное, доложу вам, чтение.

Уязвимости приложения

В данном разделе приводятся основные возможные уязвимости в коде приложения, а также методы их устранения и минимизации «человеческого фактора» при разработке.

SQL injection

Категория: проектирование.

Данная уязвимость позволяет злоумышленнику изменить запрос к базе данных, используя введенные данные. Пользуясь данной уязвимостью, взломщик может выбрать из базы данные, не предусмотренные разработчиком (что позволит, например, войти в административный интерфейс, не зная пароль) или подменить данные в БД (например, удалить таблицу или заменить тесты).

Как правило, данная уязвимость устраняется экранированием данных при сборке запроса. В данном разрезе крайне желательно изначально убрать возможность обращаться к базе напрямую из кода, а работать с БД исключительно через специальную библиотеку, автоматически выполняющую необходимые преобразования.

Не удержусь и пущу небольшой луч ненависти. Однажды к нашему сайту одна сторонняя контора приворачивала свой сервис, эти славные ребята прислали нам письмо, в котором просили дать им доступ в БД, дабы сделать общую авторизацию. На это предложение мы ответили гневным отказом и схемой авторизации, снабженной надлежащими редиректами и ЭЦП. В ответ они пожаловались нашему начальству, на то, какие мы все-таки параноики и саботажники, в результате чего интеграцию пользователей перенесли на «когда-нибудь» и решили запустить это все дело «пока так». Каково же было мое удивление, когда вбив в поле «пароль» одинарную кавычку на подсайте, сделанном этими «рыцарями без страха и упрека», я получил радостное сообщение о SQL-ошибке.

Особую пикантность придавал тот факт, что система периодически выдавала в случае ошибки красиво отформатированные куски кода, в одном из которых был найден комментарий «Коля WTF».

Code injection

Категория: проектирование.

Происходит в случае, если какой-либо исполняемый код подключается или формируется на основе данных, введенных пользователем. Устраняется за счет введения дополнительных проверок, экранирования и использования специализированных библиотек.

Если вы думаете, что code injection ограничивается хрестоматийным багом “include $_GET[‘file’]”, хочу вас немного расстроить:

  • выполнить между делом код может парсер текста или формул (проверьте лишний раз, как у вас заменятся {%username%});
  • шаблонизатор может пройтись несколько раз по шаблону и выполнить данные (вы уверены, что когда-то не сделали два прохода, чтобы выполнить какой-то подшаблон?);
  • регулярные выражения выполняются, и в них тоже можно сделать code injection.

Если вы увлекаетесь мета-программированием, и ваш контроллер автоматически вызывает методы на оснований запроса, удостоверьтесь, что нельзя вызвать какой-либо «не тот» метод (подобную дырку я как-то однажды сам пропустил — контроллер можно было вогнать в бесконечную рекурсию).

Межсайтовое выполнение сценария

Категория: проектирование.

Внедрение злоумышленником html- или JavaScript-кода на сайт из-за недостаточной проверки и преобразования введенных данных. Позволяет изменить внешний вид сайта и в некоторых случаях «украсть авторизацию» (попасть в административный или пользовательский интерфейс без ввода пароля).

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

XSS — это второе «наше все», тут можно посоветовать следовать принципу: «запрещено все, что не разрешено», который работает гораздо лучше принципа «разрешено все, что не запрещено», методов внедрения XSS придумано сто тысяч миллионов и кто знает, сколько их еще не придумано.

Часто людей подводит избыточное доверие к вводимым данным, особенно это хорошо выглядит, когда после проверки ссылки (например для постраничной навигации) данные собираются тупо из запроса. Забывается, например, немаловажный факт, что строка “1аааа”, во многих языках спокойно приводиться к циферке «1», а вместо “aaa” можно поставить что-то и похуже.

Отдельно хочу упомянуть настройку цветовой гаммы сайтов. Я как-то столкнулся с системой создания скинов, автор которой был совершенно не в курсе милой способности IE выполнять JavaScript-код прописанный в exspression.

Нельзя забывать и о том, что code injection можно делать и в JavaScript. Так один фотосайт, сделавший возможность вставлять комментарии к участку фотографии, совершенно не озаботился тем, чтобы этот комментарий экранировать, в результате чего с уютной страницы фоточки можно было сделать очень много интересного.

Еще много забавных случаев связано с веб-мастерами, симпатизирующими разным порталам, и позволяющими вставлять ссылку на свой профиль, при этом ЖЖ-ник они зачастую проверяют не достаточно тщательно, так что при желании туда можно вписать что-то вроде “http://myseosite.com/?” и тем самым немного поправить себе ТИЦ и PR.

CSRF. Межсайтовые запросы

Категория: проектирование.

 
Данная атака направлено на то, что пользователь совершает какие-то действия незаметно для себя. Самый простой пример: на сайте злоумышленника находится картинка, адрес которой совпадает с адресом удаления раздела. Когда вы заходите на эту страницу, ваш браузер запрашивает URL картинки, и, если вы авторизованы в системе, вы сами незаметно для себя удаляете этот раздел.

Данная проблема решается введением механизма подтверждения, т.е. вы можете совершить определенное действия только при переходе с определенной страницы. На этой странице формируется ссылка с уникальным временным кодом, валидность которого проверяется страницей, на которой совершается непосредственно действие.

У нас на одном проекте пользователи стали частенько самоудаляться из сообществ, проблема оказалась в злостном iframe’e, который вел на страницу суицида.

Доступ к скрытым файлам

Категория: проектирование.

Позволяет атакующему, специальным образом сформировав запрос, прочитать произвольный файл на сервере. Решается проверкой корректности имени файла при запросе.

Выполнение загружаемых файлов

Категория: эксплуатационная.

Файлы, загружаемые на сервер, могут быть выполнены. Это позволяет злоумышленнику, имеющему доступ в администраторский интерфейс, получить полный доступ к системе.

Меры предосторожности (на уровне администратора сервера):

  • разрешение записи только в определенные директории на сервере;
  • запрет выполнения скриптов в данной директории.

Отдельно следует заметить, что проверять надо и при загрузке, но лучше сразу запретить выполнение всего, а отдавать каким-нибудь nginx. При загрузке следует озаботиться как сутью файла, так и его именем, так как зловредный код можно вставить и в картинку.
Кстати зловредный код можно вставить и в .htaccess, там есть волшебная директива php_value auto_prepend_file, которая может подключить php файл.

Раскрытие кода

Категория: эксплуатационная, проктирование.

Доступ к служебным и разработческим скриптам, а также к исходному коду может дать злоумышленнику дополнительную информацию для взлома:

  • расположение отладочных, системных и разработческих скриптов в открытом доступе;
  • расположение служебных скриптов в отрытом доступе: программы, выполняемые с определенной периодичностью (по крону), могут быть запущены извне, что дает возможность создать большую нагрузку для вывода сайта из строя;
  • исходный код доступен для просмотра: данная уязвимость может быть вызвана неправильной настройкой системы контроля версий.

Несколько месяцев назад, благодаря папочке svn одни любознательные товарищи узнали много нового о ведущих сайтах рунета, о чем кстати и написали на Хабре.

Переполнение диска

Категория: проектирование.

 
Из-за недостаточной проверки входных данных или неверно организованного кэширования злоумышленник может забить базу данных или диск ненужной информацией, что замедлит работу и может вызвать (если закончится место) неработоспособность системы.

  • Бесполезные запросы — данный метод является частным случаем DDOS-атаки. Злоумышленник размещает на сайте (своем или используя XSS) код, отправляющий форму обратной связи/голосование, или банально автоматически обращается к данному URL. В результате данной атаки БД сайта или жесткий диск заполняется данными (что ко всему прочему нивелирует достоверность опроса и дезорганизует службу поддержки). Решается включением меток или, в тяжелых случаях, CAPTCHA (можно включать автоматически, если запросы идут очень часто).
  • Разрастание кэша. Результат сложных выборок, как правило, кэшируется (сохраняется на диске или в памяти, чтобы сэкономить ресурсы), при этом кэш формируется на основе входного запроса, если проверка входных данных недостаточна, можно вводя дополнительные параметры, создавать аналогичные кэши. Это, с одной стороны, забивает диск и память, а с другой — нивелирует положительный эффект кэширования (т.е. может расцениваться как частный случай DOS). Проблема решается за счет более строгой проверки данных перед кэшированием или запросом кэша.

Если вы любите идентифицировать кэш по строке запроса, будьте готовы к тому, что поставляя какие-нибудь дурацкие параметры, кто-то очень нехороший, сможет загадить ваш кэш, а между делом и поDOSить.

Частным случаем, является ранее описанное недостаточное приведение к целому, так как «001» и «1», это одинаковые циферки, но разные строчки, так что /\d+/ регексп так себе, а вот /^[1-9]\d*$/-- хороший, годный регексп.

Кроме того, начиная читать что-нибудь, необходимо удостовериться, что вы сможете это прочитать. С этой проблемой как-то столкнулась компания mail.ru начав проверять архивы на вирусы. Дело в том что с виду маленький архив, совершенно случайно может содержать несколько терабайт ноликов (возможно это байка, однако повод для раздумий есть).

А сайт «Вконтакте» как-то решил похулиганить, и сделал на своей странице невидимый iframe, ведущий на сайт премии рунета, отчего премии немного поплохело. По сути, этот милый поступок ближе к DDOSу, но упоминания заслуживает.

Псевдокриптография

Очень многие считают, что случайное число и md5 хэш и есть криптография. На самом деле это не так, md5 уже давно скомпрометирован и для целей безопасности его лучше не использовать.

Что касается случайных последовательностей, то они часто оказываются не совсем случайными, что автоматически означает — их нельзя использовать, например для карт оплаты. В частности псевдослучайными является GUID, генерируемый MS SQL сервером, о чем подробно и с выражением написано на RSDN.

Также интересны случаи изобретения собственных систем шифрования и вытекающая из этого распространенная практика что-то зашифровать и, не ходя далеко, также расшифровать (как вариант — подписать что-нибудь открытым ключом)

Конфигурация сервера

Категория: эксплуатация.

Важным вопросом является правильная конфигурация сервера и периодическое обновление программного обеспечения. Администраторам следует отслеживать сообщения об уязвимости (bagtraq) и обновление ПО (веб сервера, сервера БД и т.п.), так как постоянно обнаруживаются новые ошибки и уязвимости.

Однажды я столкнулся с одной организацией, которая блюла себя настолько, что сервер у них стоял за семью замками, а для того чтобы обновить сайт, надо было ехать туда с архивом на CD диске. При этом все ПО у них было поставлено 4 года назад и с тех пор не обновлялось, потому что страшно и лень.

DDOS

Категория: эксплуатационная, проектирование.

Одна из наиболее сложных в плане предотвращения атак. Суть заключается в том, что на сервер идет поток запросов (flood), отчего банально заканчиваются ресурсы, и сервер не может справиться с нагрузкой. Как правило, DOS-атака является распределенной и осуществляется при помощи ботнета: сети из зараженных вирусом компьютеров.

Следует понимать, что атака осуществляется специальными программами, которые при желании можно модифицировать под конкретную задачу, т.е. большую часть ухищрений по защите злоумышленник при желании может обойти.

DDOS-атака является объектом купли-продажи, т.е. злоумышленником может быть любой, кто в состоянии заплатить владельцу ботнета.

Стоимость аренды ботнета довольна расплывчата, если раньше она оценивалась в несколько тысяч USD, то сейчас цены сильно упали и есть предложение и в $100–150 за день атаки (правда, это подразумевает предоплату, что в подобном высокоморальном бизнесе означает, что шансы просто потратить деньги, довольно высоки). DDOS-атаки разделяются по степени грубости:

Переполнение канала.

Количество запросов настолько велико, что исчерпываются ресурсы сетевого подключения.
Решения:

  • покупка более широкого канала (скорости 10 GBps должно вполне хватить), кроме того необходимо иметь резервный канал;
  • непосредственно ресурсы сервера ограждаются путем фильтрации по порту при помощи аппаратного решения.

SYN-флуд

Смысл в том, что на особый TCP-пакет c флагом SYN сервер должен ответить пакетом SYN+ACK, после чего ожидать ответа. В случае DOS-атаки ответа не поступает, между тем, сервер занят ожиданием.
В данном случае может быть использована и SYS-reflection-атака, когда SYN пакет посылается третьему серверу с указанием поддельного IP-адреса: сути это не меняет, но будет приходить SYN/ACK-пакет с периодичностью в несколько минут, что следует учитывать при блокировании по IP.
Решения:

  • использование SYN-COOKIE;
  • установка быстрого (желательно аппаратного) фронтенда, который будет заниматься обработкой подобных запросов, не «отвлекая» сервер приложений;
  • ограничение времени ожидания ответа и увеличение количества одновременных подключений (в разумных пределах);
  • вычисление о запрет проблемных IP-адресов.

HTTP-флуд.


В этом случае основную нагрузку принимает на себя сервис приложений, как следствие, мы имеем большую нагрузку.
Решения:

  • отделение реальных пользователей от «ботов»: установка COOKIE, установка флагов средствами JavaScript или Flash, CAPTCHA. Последнее не очень приятно для пользователя, хотя даже Google и Yandex этим не брезгуют.
    Используя собственные хитрости, следует учесть что:
    а) помимо DOS-роботов на сайт заходят пауки поисковых систем, которых как раз отсекать не надо.
    б) боты могут быть спрограммированы так, чтобы обходить средства защиты (cookie защищает от самых простых, а наиболее сложные могут выполнять JavaScript), так что эти решения призваны скорее поднимать стоимость атаки.
    в) нагрузка от средств защиты должна быть меньше, чем в случае, если робот преодолел ее (в первую очередь имеется в виду оптимизация CAPTCHA).
  • Специализированные программные и аппаратные средства для отслеживания аномалий трафика.
  • Сервисы по очистке трафика — сторонние ресурсы (http://ddef.ru/defence/, http://highloadlab.ru/services/service_8.html), которые отсеивают вредные запросы. Некоторые из них (highloadlab) бесплатны.
    Необходимо заметить, что все эти сервисы строго следят за репутацией охраняемых сайтов, и могут отказать, если проект является подозрительным.

Про DDOS уже написано много и большей частью грустного — боты умнеют, их все больше, Гондор не выстоит и т.п. На самом деле, при серьезном подходе он не так уж страшен (вот lib.rus.ec досят безостановочно и хоть бы хны), но всегда надо быть готовым к худшему, и сделать сплеш-страницу: «На нас напали и DDOSят, пока мы тут бьемся в кровь, посмотрите ролик на youtube про наши новые сервисы».


  • 1
Какой ты умный. Завидую.

  • 1