Текст книги "Создание сайтов"

Риски и возможности

Глава 19. Уязвимости на сайте: семь раз отмерь, семь раз зашей

Вы прошли огонь, воду и «игру со шрифтами»: сайт готов. Не исключено, что – надеемся, благодаря нашим советам! – логика его интерфейсов безупречна, он красив и быстр, живет на выделенном сервере у прекрасного хостинг-провайдера. В общем, идиллия. Однако над молодым многообещающим веб-проектом могут сгуститься тучи, как полагается в голливудских фильмах. Перефразируя английского мыслителя Джона Донна, констатируем: сайт не остров. Он существует в мире, где бал правят люди. А люди бывают всякие. У вас, скорее всего, есть конкуренты или просто недоброжелатели, которым ваши успехи в Сети что острый нож. Кроме того, водятся в Вебе и те, кто любит проверять на прочность все, что подвернется им под руку в цифровом пространстве, и имя им легион. Пугать вас не станем, примите как данность: ваш сайт может подвергнуться атаке. Через день после открытия, через месяц, через пять лет – и еще большой вопрос, когда хуже.

Обычно на старте у вредителей нет доступа к управлению вашим интернет-ресурсом. Разве что вы пригрели на груди змею, но для предотвращения таких проблем лучше купить другую книгу – по психологии отношений. Если в коде сайта нет лазеек, то взять первый барьер обороны злонамеренным личностям будет трудно. Но на деле подобные уязвимости обнаруживаются с печальной частотой. В зоне особого риска – CMS, тем паче бесплатные из разряда не самых популярных. Насколько же часто случается так: в системе управления сайтом находят ошибки, разработчики выпускают ее новую, «заплатанную» версию, и тем не менее сотни нерадивых веб-мастеров не обновляют ядро CMS, на которой сделаны поддерживаемые ими сайты. Да и в дополнениях, плагинах к движкам критически опасные бреши то и дело попадаются.

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

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

• Подмена главной страницы сайта. На хакерском сленге – «дефейс» (от англ. deface – «портить», «обезображивать»). Один из беспроигрышных вариантов подмочить репутацию компании. «Раз ее корпоративный сайт был взломан, то какая ей вера?» – думает средний пользователь. Самый заметный, но часто наиболее безобидный в долгосрочной перспективе вид взлома. Грязно, однако не смертельно. Зачастую вандалу хочется лишь громко заявить о себе и он не преследует корыстных целей, вторгаясь в ваше интернет-представительство.

• Подлог или уничтожение информации и функциональных элементов. Гораздо менее безобидный вариант враждебных манипуляций с сайтом. Периодически используется в конкурентной борьбе. Но чаще взломщики изначально атакуют фактически наобум, прощупывая все подвернувшиеся сайты подряд в надежде, что у какого-нибудь окажется «мягкое подбрюшье». Берет киберпреступник (а как его еще прикажете называть?) и подменяет ваши платежные реквизиты своими, принадлежащими подставному лицу. Если у вас через Интернет проводится много сделок по безналичному расчету, а товара, допустим, заказчик ждет в течение недели-двух, то, пока вы хватитесь, злоумышленники могут умыкнуть немаленькие суммы, предназначавшиеся вам.

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

• Удаление сайта. Со всеми его каталогами и контентом. Самый грубый прием. Но иногда он бывает нокаутом. Водятся еще веб-мастера и администраторы, которые пренебрегают регулярным резервным копированием сайтов (см. далее по тексту).

• Заражение вирусами. «Зловреды», как их еще называют в Рунете, селятся на сайте и стараются потихоньку внедриться на компьютеры его ни о чем не подозревающих посетителей, если браузеры у тех «дырявые», а антивирусная защита устарела. Успешно инфицировав чей-то ПК, такая вредоносная программа может выполнять самые разные действия: от похищения персональных данных, включая коды доступа к банковским картам и их реквизиты, до выполнения команд от владельца ботнета – целой сети зараженных компьютеров (см. следующий пункт).

• Создание чрезмерно высокой нагрузки на сайт. Необязательно «зачумлять» сам сайт, чтобы парализовать его работу. Удручающе часто бывает достаточно сделать площадку не доступной никому – на час, день, неделю. Редкий интернет-ресурс рассчитан на по-настоящему высокую посещаемость: многие дислоцируются на виртуальном хостинге (см. главу 7 «Домен и хостинг: паспорт, прописка, жилье»), у иных толком нет постоянного администратора. Значит, чтобы «свалить» сайт, можно пустить на него шквальный поток аудитории. А проще симулировать такой ажиотаж: будто сотни и тысячи человек одновременно пытаются зайти на сайт. Такой печально известный способ обрушения сайтов называется DDoS.

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

• Рассылка спама через интернет-ресурс. Отправка нежелательной, мусорной корреспонденции до сих пор остается прибыльным делом. Однако спамеров никто не любит. И нет лучше способа оказаться на обочине Интернета, чем быть уличенным в массовом распространении рекламных писем. Говорите, ваш сайт заразили? Тем, кто занесет его в черные списки, безразличны оправдания. Да и со стороны поисковиков ничего хорошего сайт, рассылающий спам пусть даже поневоле, не ждет. Из-за предупреждения вида «Сайт представляет угрозу» (рис. 39) в выдаче поисковика посещаемость площадки гарантированно снижается, подчас в десять и более раз, о чем на конференции CyberMarketing 2012 рассказал руководитель службы безопасного поиска «Яндекса» Александр Сидоров.

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

• Захват администраторских логина и пароля не через сам сайт. Действительно, чем подбирать ключи к двери, бывает проще стянуть их с пояса у смотрителя. Способов сделать это уйма: взломать почту администратора сайта, или запустить на его рабочий компьютер «троян», который передает своему «заводчику» информацию о происходящем на инфицированном ПК, или, как ни смешно, подсмотреть из-за сутулого вебмастерского плеча.

^{Рис. 39. «Яндекс» сигнализирует в своей выдаче о подозрении на заражение сайта}

• SQL-инъекции. Название очень меткое. Часто сайты активно задействуют базы данных (собственно, SQL – язык для оперирования БД) и для формирования страниц используют вводимую посетителями информацию. Через подобный SQL-запрос, замаскированный под пользовательские данные, при наличии уязвимости взломщику, бывает, удается «впрыснуть» вредоносный код – и далее тот выполняется на веб-сервере.

• XSS-уязвимости. Cross-site scripting, или «межсайтовый скриптинг». Первую букву аббревиатуры заменили на X во избежание путаницы с CSS – каскадными таблицами стилей, о которых мы говорили в предыдущих главах. Это способ внедрить в страницу, формируемую веб-сервером, фрагмент кода извне за счет неоптимальной работы с пользовательскими переменными на сайте. В простых выражениях – злоумышленник не совершает нападение на сервер, а идет в обход: пытается выхватить (cookies, связку «пароль – логин» и т. д.) критически важные авторизационные данные пользователя площадки, а то и самого администратора. XSS многолик и широко используется в целях так называемого фишинга.

• LFI (local file include) – не закрытая, как полагается, возможность внедрения локального файла на веб-сервер. Например, если в форме для загрузки пользовательских фотографий или аватарок программистами не была реализована проверка расширений файлов, то хакер располагает возможностью «просунуть» через эту лазейку свой коварный скрипт. Последствия бывают самыми плачевными.

• CSRF (cross site request forgery) – буквально «подделка межсайтовых запросов». Пользователь заходит на сайт и вводит свои личные данные. Например, аутентифицирующие его с целью отправки платежа. Однако из-за того, что HTTP-запросы к серверу недостаточно тщательно проверяются, эта лакомая информация может утечь за пределы ресурса – прямо в руки к лихоимцу (чтобы удерживаться от более крепких выражений, мы вынуждены употреблять галантные синонимы).

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

• Перво-наперво сайт должен быть спроектирован с учетом нужд безопасности. Если его писал на коленке школьник, испытавший головокружение от первых успехов в освоении PHP, то код будет дырявым как решето. Нужно, чтобы веб-проект создавал человек, ставящий информационную безопасность во главу угла. Например, понимающий, как важно тщательно проверять cookies авторизующегося пользователя, контролировать HTTP– и GET-запросы и т. д.

Пусть одним из критериев выбора веб-разработчиков для вас будет их компетентность в вопросах интернет-безопасности. А если вы намерены создать крупный веб-проект, тем более интенсивно работающий с персональными данными пользователей (не говоря уж о финансовых онлайн-сервисах), резонно будет обратиться за консультацией в компанию с высокой концентрацией экспертов по инфозащите. Например, Positive Technologies (http://www.ptsecurity.ru).

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

• Бдительно относитесь к паролям. Ключи доступа к администраторской зоне сайта, FTP-серверу, панели хостинга должны быть достаточно сложными и длинными, не менее 11–12 символов, и чем разнообразнее по составу символов, тем лучше; отдельные слова из общей лексики не годятся. Понятное дело, совершенно немыслимы связки «логин – пароль», используемые во многих системах по умолчанию, например классическое admin для обоих полей. Грубая ошибка – использовать один пароль на все случаи жизни. Еще грубее – не менять пароли несколько раз в год (лучше со строго заданной периодичностью, чтобы это вошло в привычку).

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

• Будьте вдвойне осторожны при использовании сторонней CMS. Многое зависит от того, насколько она популярна и кем курируется. Следует регулярно обновлять движок. Кстати, желательно скрыть от посторонних глаз упоминание о версии системы и ее плагинов: многие взломщики, особенно начинающие, последовательно выискивают CMS конкретных редакций, поскольку знают, что в них еще не закрыты определенные уязвимости.

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

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

При работе со многими CMS (особенно WordPress и Joomla) нелишним будет убрать страницу входа в административную зону со стандартного места.

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

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

• Закрывайте любые соединения после того как они перестают быть вам нужны. Чаще всего, вероятно, вы будете иметь дело с загрузкой файлов на сервере по протоколу FTP. Так вот, «залили» документ – отсоединились. Лишние, не используемые вами в работе соединения закройте через настройки файервола и сетевую инфраструктуру.

• Используйте защищенные протоколы SFTP и SSH.

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

• Следите за конфигурацией программного обеспечения на веб-сервере. В случае с Apache повышенное внимание уделяйте. htaccess (см. блок «Полезно знать»).

• Анализируйте лог-файлы, ведущиеся на сервере. По ним, обладая определенными навыками, легко отслеживать попытки взлома.

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

• Используйте сервисы – сканеры уязвимостей. Metasploit Framework (http://www.metasploit.com), Tenable Nessus (http://www.tenable.com/products/nessus), XSpider (http://www.ptsecurity.ru/xs7/concept/), Zed Atack Proxy (https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) – в числе самых известных из них. Часть из них сравнительно проста в эксплуатации, часть же, например Metasploit Framework, проявит всю свою мощь только под присмотром красных программистских глаз.

• Проверяйте файлы сайта на вирусы. Например, с помощью следующих систем: www.unmaskparasites.com, http://vms.drweb.com/online/, www.2ip.ru/site-virus-scaner/, www.antivirus-alarm.ru/proverka/.

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

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

• Регулярно проверяйте сайт на вшивость сами, с помощью своих технических специалистов. Кроме того, совершенно оправданно привлечение сторонних тестировщиков на платной основе, в первую очередь перед полноценным запуском сайта. Целые орды желающих «попинать Веб» бродят, скажем, на forum.antichat.ru. Немало их и на Fl.ru (ранее Free-lance.ru). В данном случае тройное внимание уделяйте отзывам о работе таких специалистов, их реноме. Гораздо лучше, если вам лично, по сарафанному радио, порекомендуют одного такого умельца или даже команду.

Не забывайте о тестировщиках, единожды воспользовавшись их услугами. Уверяем, они вам еще понадобятся. Даже если вы будете годами развивать один только сайт, его регулярно потребуется шерстить на предмет уязвимостей. Пусть у вас в Skype или другом средстве электронной коммуникации будет создана отдельная группа – «Тестировщики» (рис. 40).

^{Рис. 40. Рядовой диалог с тестировщиками в Skype}

• Проштудируйте раздел «Как защитить сайт от заражения?» в справке службы «Яндекс. Вебмастер». И возьмите на вооружение все рекомендации из нее. Таким образом вы убережете себя от многих опасностей.

• Непременно подключите сайт к «Яндекс. Вебмастеру». Когда «Яндекс» обнаруживает признаки заражения на ресурсе, он оперативно подает сигнал. Вычистив вредоносный код, вы сможете воспользоваться функцией «Перепроверить», чтобы удостовериться в успехе санитарного мероприятия.

«Как сделать сайт безопасным и почему это важно для продвижения»: http://seopult.tv/programs/conference/yandex_kak_sdelat_sayt_bezopasnym/

Справка службы «Яндекс. Вебмастер» (см. раздел «Безопасность сайта»): http://help.yandex.ru/webmaster/

Портал о компьютерной безопасности SecurityLab: http://www.securitylab.ru

«Стандарты безопасности при разработке интернет-сайтов и веб-приложений (OWASP)»: http://www.siteprojects.ru/blog/?p=1391

Open Web Application Security Project (стандарты веб-безопасности): https://www.owasp.org

«Профилактика SQL-инъекций»: http://habrahabr.ru/post/87872/

«Типы XSS-уязвимостей»: http://wiki.auditory.ru/Типы_уязвимости_XSS

«Попытка номер раз создать почти идеальный. htaccess»: http://habrahabr.ru/post/154643/

«Рассылка SeoPult. Выпуск № 85: пути решения проблем с вредоносным кодом на сайте»: http://seopult.ru/subscribe.html?id=85

«Как вылечить зараженный сайт» («Яндекс. Помощь»): http://help.yandex.ru/webmaster/?id=1116613

Глава 20. Высокие нагрузки и защита от DDoS-атак: стелем солому и роем окопы

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

К сожалению, когда именно не рассчитанный на большое количество посетителей портал «ляжет» под возросшей нагрузкой, предсказать проблематично. Невозможно предугадать действие всех внутренних и внешних факторов. Вдруг ваш интернет-магазин пряжи благодаря сарафанному радио станет лидером в своей категории, хотя до сих пор звезд с неба не хватал? Или давно лелеемый вами онлайн-сервис по составлению резюме в виде инфографики засветится во всех отраслевых медиа лишь потому, что такие продукты наконец вошли в моду? Какие-то проекты амбициозны хотя бы в силу своего замысла, каким-то изначально предначертано нишевое существование: сравните международный сервис знакомств с блогом о ежиках. Пусть так, но любому веб-мастеру и сайтовладельцу надлежит иметь план с заголовком «Что сделать, чтобы мой сайт был готов к серьезному устойчивому росту посещаемости». Кому более, кому менее подробный. Нет нужды становиться экспертом в сфере высоких нагрузок (highload), но следует быть в курсе того, что это такое и как реагировать, когда в твою дверь толпой ломятся долгожданные или нежданные гости.