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

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

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

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

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

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

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

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

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

Кроме того, возможна кража с использованием так называемого «фишингового» сайта, т.е. сайт в браузере пользователя подменяется на идентичный, после ввода данных в форму входа, пароль попадает к злоумышленнику, в данном случае важно иметь «подписанный сертификат сайта». При использовании такого сертификата специальная компания (например http://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

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

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

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

Мы в ответе за тех кого приручили—следя за своими персональными данными, не забывайте о персональных данных пользователей.
Выключайте автоматическое заполнение полей, в которые посетитель вводит личные данные. Меня всегда умиляет трогательная забота агрегаторов платежей за кредитки, которые оставляют autocomlete в полях номер карты и 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 одни любознательные товарищи узнали много нового о ведущих сайтах рунета, о чем кстати и написали на хабре.

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

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

1. Бесполезные запросы—данный метод является часным случаем DDOS атаки, злоумышленник размещает на сайте (своем или используя XSS) код, отправляющий форму обратной связи/голосование, или банально сам автоматически обращается к данному URL. В результате данной атаки БД сайта или жесткий диск заполняется данными (что ко всему прочему нивелирует достоверность опроса и дезорганизует службу поддержки). Решается включением меток или, в тяжелых случаях, captcha (можно включать автоматически, если запросы идут очень часто).
   
2. Разрастание кэша. Результат сложных выборок, как правило, кэшируется (сохраняется на диске или в памяти, чтобы сэкономить ресурсы), при этом кэш формируется на основе входного запроса, если проверка входных данных недостаточна, можно вводя дополнительные параметры, создавать аналогичные кэши. Это, с одной стороны, забивает диск и память, а с другой — нивелирует положительный эффект кэширования (т.е. может расцениваться как частный случай 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 атаки разделяются по степени грубости:

1. Переполнение канала— количество запросов настолько велико, что исчерпываются ресурсы сетевого подключения.
   Решения:
   • покупка более широкого канала (скорости 10GBps должно вполне хватить), кроме того необходимо иметь резервный канал.
   • непосредственно ресурсы сервера ограждаются путем фильтрации по порту при помощи аппаратного решения.
2. SYN-флуд.
   Смысл в том, что на особый TCP пакет c флагом SYN сервер должен ответить пакетом SYN+ACK, после чего ожидать ответа. В случае DOS атаки ответа не поступает, между тем, сервер занят ожиданием.
   В данном случае может быть использована и ‘SYS-reflection` атака, когда SYN пакет посылается третьему серверу с указанием поддельного IP адреса: сути это не меняет, но будет приходить SYN/ACK пакет и с периодичностью в несколько минут, что следует учитывать при блокировании по IP.
   Решения:
   • Использование SYN-COOKIE
   • Установка быстрого (желательно аппаратного) фронтенда, который будет заниматься обработкой подобных запросов, не «отвлекая» сервер приложений
   • Ограничение времени ожидания ответа и увеличение количества одновременных подключений (в разумных пределах)
   • Вычисление о запрет проблемных IP адресов.
3. HTTP-флуд.
   В этом случае основную нагрузку принимает на себя сервис приложений, как следствие, мы имеем большую нагрузку.
   Решения:
   • Отделение реальных пользователей от «ботов»: установка COOKIE, установка флагов средствами javascript или flash, captchа. Последнее не очень приятно для пользователя, хотя даже Google и Yandex этим не брезгуют.
     Используя собственные хитрости, следует учесть что:
     а) помимо DOS роботов на сайт заходят пауки поисковых систем, которых как раз отсекать не надо
     б) боты могут быть спрограммированы так, чтобы обходить средства защиты (cookie защищает от самых простых, а наиболее сложные могут выполнять javascript), так что эти решения призваны скорее поднимать стоимость атаки
     в) нагрузка от средств защиты должна быть меньше, чем в случае, если робот преодолел ее (в первую очередь имеется в виду оптимизация captcha)
   • Специализированные програмные и аппаратные средства для отслеживания аномалий трафика
   • Сервисы по очистке трафика— сторонние ресурсы (http://ddef.ru/defence/, http://highloadlab.ru/services/service_8.html), которые отсеивают вредные запросы. Некоторые из них (highloadlab) бесплатны.
     Необходимо заметить, что все эти сервисы строго следят за репутацией охранямых сайтов, и могут отказать, если проект является подозрительным.

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