Все новости от 27 августа 2001 г.

Безопасность нужно создавать, а не рисовать

Джоди Патилья

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

Последним звеном в цепи подобных неприятностей стало недавнее появление червяка Code Red, вихрем пронесшегося по Интернету и поразившего тысячи систем на основе Web-сервера Microsoft IIS, где не были установлены нужные заплаты. Пострадал даже узел обновления самой Microsoft. Но это лишь капля в море инцидентов, порожденных ошибками коммерческого Web-серверного ПО.

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

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

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

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

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

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

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

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

Медицинские страховые компании и поставщики медицинских услуг видят в Интернете в первую очередь средство охвата наибольшего числа клиентов, снижения затрат и времени между получением и исполнением заказа. А банки и кредитные организации хотят обеспечить наилучшее обслуживание при минимуме кассиров. Теоретически все это очень хорошо, но на практике часто получается совсем не так, как хотелось бы.

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

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

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

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

Джоди Патилья — консультант фирмы Metases (Шарлотт, шт. Сев. Каролина). Связаться с ней можно по адресу: jody.patilla@metagroup.com.