15.04.2003

ќценка риска защиты »нтернета, „асть 4: сетевые приложени€

Ёта стать€ - четверта€ в серии статей, предназначенных дл€ помощи читател€м оценить риск, которому подвергаютс€ их системы, св€занные с »нтернет. ¬ первой статье мы установили причины, по которым следует производить техническую оценку риска. ¬о второй мы приступили к обсуждению методик, которым мы следуем при выполнении этого вида оценки. ¬ третьей статье эти методики обсуждались более подробно, основное внимание было уделено просмотру у€звимостей и нагл€дности. ¬ этой статье мы обсудим относительно малоизученный аспект безопасности »нтернет - обычные Web приложени€.

Ёта стать€ - четверта€ в серии статей, предназначенных дл€ помощи читател€м оценить риск, которому подвергаютс€ их системы, св€занные с »нтернет. ¬ первой статье мы установили причины, по которым следует производить техническую оценку риска. ¬о второй мы приступили к обсуждению методик, которым мы следуем при выполнении этого вида оценки. ¬ третьей статье эти методики обсуждались более подробно, основное внимание было уделено просмотру у€звимостей и нагл€дности. ¬ этой статье мы обсудим относительно малоизученный аспект безопасности »нтернет - обычные Web приложени€.

јнализ сетевых приложений

††††††††††† »з всех возможных служб »нтернета DNS, e-mail и www наиболее попул€рны. »з них, Web службы - самые сложные и наиболее часто используемые злоумышленниками. »значально €вл€€сь, простой текстовой информационной службой, Web постепенно развилась в очень функциональную диалоговую прикладную платформу, котора€ используетс€ почти во всех приложени€х, как в »нтернете, так и во внутренних сет€х. √лавные продавцы признали силу Web и сделали существенные вклад в развитие ее платформ. —реди них:† Sun (Java), Microsoft, открытое общество (PHP) и другие, например, ColdFusion. Ќа базе этих платформ обычному администратору очень легко развивать сложные приложени€. ¬следствие бурного развити€ Web все, как по мановению волшебной палочки, вдруг стали программистами. Web приложени€ часто развивались неквалифицированными и неопытными разработчиками. ƒаже самые опытные программисты† неосознанно делают ошибки, дающие потенциальным злоумышленникам точное направление, где искать у€звимое место, которое им нужно дл€ проникновени€ в частную сеть. „то же говорить о программистах среднего уровн€ или даже ниже! ѕоскольку эти приложени€ создаютс€ на стандартных платформах, они часто аналогичны и поэтому, как правило, имеют одинаково слабые места в защите.

†††††††††††  ак все более и более значима€ технологи€ в »нтернете, распространенные сетевые приложени€ должны рассматриватьс€ в каждой оценке безопасности. ’от€ имеетс€ проблема: мы знаем, что почти каждый, кто запускает DNS, автоматически запускает †BIND (Berkley Internet Name Domain). “аким образом, если †BIND имеет у€звимость, она затронет каждого. ”€звимость станет известной общественности, а ее подпись, в конечном счете, обнаружитс€ сканерами у€звимости и попадет в базы данных у€звимостей.

††††††††††† ћы можем проверить системы, использу€ такие сканеры и определить у€звимость, котора€ может нас затронуть. ј как же поступать с у€звимост€ми, св€занными с самодельным сайтом какого-нибудь клиента мелкой компании, типа Joe Soap Inc.. ќб€зательно ли включать их в наш сканер у€звимостей? ќтвет: нет, потому что Web приложени€ так часто €вл€ютс€ "самодельными", так что их у€звимости, вр€д ли станут широко известными, так что каждое приложение нужно рассматривать индивидуально, пыта€сь определить ошибки безопасности, возможно сделанные непрофессиональными программистами.

††††††††††† ќценка Web приложений €вл€етс€ новым направлением и представл€ет аналитикам безопасности целый пакет проблем. –анее известные важные предпосылки, методики и инструменты в этой области не применимы и даже ведущие практики, только начинают понимать все возникающие проблемы, св€занные с этими видами систем.

ѕроверка защиты сетевых приложений

††††††††††††††††† Ќаше испытание сетевых приложений главным образом основано на принципе "черного €щика", то есть мы исследуем приложени€ над сетью без доступа к исходной программе.  онечно, не име€ доступа к исходной программе, имеетс€ веро€тность пропустить что-нибудь важное. Ќазовем это "фактором нечеткости". Ќаш собственный план тестировани€ "нечетких" сетевых приложений состоит из двух частей: перва€ часть - это простой список вопросов, на которые нужно ответить в процессе рассмотрени€ приложени€, а втора€ часть - список банальных программных ошибок, наличие которых нужно проверить.

††††††††††††††††† ’от€ каждый программист и, следовательно, каждое приложение уникальны, ошибки, как правило, одни и те же. ћы составили список общих программных† ошибок, наличие которых можно проверить, даже наход€сь над сетью. ƒетально опишем план тестировани€ немного позже, а пока нужно кратко напомнить некоторые основные пон€ти€, которые читателю необходимо понимать.

  • HTML - Hyper Text Markup Language. ѕростой €зык, использующийс€ дл€ описани€, того, как форматировать и показывать web-страницы. HTML использует команды, называющиес€ "тэгами", чтобы объ€снить браузеру, как web-страница должна выгл€деть и как она должна вести себ€. Ќапример, тэг <A HREF> указывает, что последующий текст фактически €вл€етс€ гиперсв€зью с другой страницей; тэг <B>† указывает, что текст должен быть показан жирным шрифтом.
  • HTTP - Hyper Text Transfer Protocol. »спользует TCP-св€зь (обычно на 80 порту), чтобы перемещать данные между сервером сети и браузером. ѕротокол HTTP используетс€ дл€ того, чтобы транспортировать все файлы, используемые в HTML, включа€ текст, графику, звук, видео и активные элементы, типа Shockwave, Flash и Java Script.
  • ‘ормы Ц это специальные типы HTML элементов, которые позвол€ют пользователю отправл€ть данные обратно на web-сайт. ‘орма может состо€ть из любого числа полей различных типов. ¬ невидимом поле содержитс€ значение, которое не показываетс€ браузером (более подробно мы расскажем об этом в п€той статье) и иногда используетс€ программистами дл€ контрол€ над† информацией, о чем пользователь может и не знать. ¬ нормальное входное поле формы пользователь может вводить данные,† которые передаютс€ обратно на web-сайт, извлекаютс€ и обрабатываютс€ приложением сервера, обычно CGI.
  • CGI - Common Gateway Interface. ќписывает дл€ Web серверов стандартный способ передачи информации программам и отправлени€ полученных данных† обратно браузеру дл€ демонстрации. »ме€ CGI, Web разработчик более не ограничен использованием только статических страниц. ¬место этого, можно прин€ть данные от пользовател€, отправить их в работающую программу, а затем отослать результаты браузеру дл€ демонстрации. »нтерфейс CGI Ц очень стара€ технологи€, но, реально, она лишь недавно стала такой, какой €вл€етс€ сейчас. ƒругие технологии типа Microsoft ASP (Active Server Pages) выполн€ют аналогичную функцию.
  • ¬ебсайты, желающие сохран€ть информацию о своих посетител€х, часто используют, так называемые, куки (cookies).†  уки Ц это небольшие объекты, содержащие данные (обычно в виде файла), посланные браузеру, который сохранит их дл€ дальнейшего использовани€. ѕри следующем посещении сайта пользователем, куки автоматически загружают сайт, в соответствии с информацией, записанной там. ¬ы, конечно, видели этот механизм в действии: сайт запоминает ваши предпочтени€ в предыдущее посещение. Ќа самом деле, ваш† браузер использует куки, чтобы напомнить сайту о вас.
  • Script - маленька€ программа, котора€ не компилируетс€ в exe-формат, пока не запуститс€. ¬место этого, кажда€ строчка читаетс€, компилируетс€ и исполн€етс€ трансл€тором при каждом запуске программы. —крипты весьма сильны, потому что они - маленькие, их легко написать и можно запустить на многих платформах без изменени€. ”величиваетс€ количество приложений, написанных на скриптовых €зыках, таких, как ASP, PHP, PERL и Java.
  • SSL - Secure Sockets Layer - протокол, который запускаетс€ Ђповерхї TCP и использует комбинацию из публичного кода и технологии симметричного шифровани€, чтобы гарантировать конфиденциальность, целостность и подлинность дл€ HTTP.  огда вы выбираете web-сайт, адрес которого начинаетс€ с букв "HTTPS://", вы направл€ете ваш браузер к туннелю св€зи с HTTP† по SSL. SSL - очень мощный механизм, но наиболее часто используетс€ только дл€ того, чтобы подтвердить подлинность сервера и засекретить св€зь между браузером и сервером.
  • ODBC - Open Data Base Connectivity протокол - стандартный способ св€зи приложений с базами данных, без необходимости понимани€ особенностей специфического выполнени€ базы данных. ODBC обычно используетс€ дл€ св€зи web-сервера с базами данных. јрхитектура приведена на рис. 1.
  • ѕриложени€ дл€ развити€ окружающей среды - используютс€ дл€ того, чтобы развивать сложные Web приложени€ легче и быстрее. ќбычно они содержат множество элементов, включа€: скриптовый (scripting) €зык, оптимизированный дл€ Web, компоненты многоразового использовани€, образцы и скрипты, генерацию кодов сеансов, св€зь с базой данных, и т.п.

††††††††††††††††† Ќезависимо от используемой платформы, основное большинство приложений имеет подобную основную архитектуру, как изображено ниже:

–ис. 1: “ипична€ архитектура Web †приложени€.

††††††††††††††††† Ќа этом рисунке изображена попул€рна€ сетева€ архитектура дл€ Web †приложений. Web-сервер располагаетс€ в особо защищенной зоне сети, называемой демилитаризированной «оной (DMZ). »спользуютс€ два файрволла: один - чтобы защитить демилитаризованную зону от »нтернета, а другой - чтобы защитить внутреннюю сеть от демилитаризованной зоны. Ёта архитектура - хорошо продумана системой безопасности и создана дл€ минимизации последствий в случае, когда Web сервер будет взломан. ќднако два канала должны быть всегда рабочими в этой архитектуре. ѕользователь всегда должен иметь возможность соединитьс€ с web-сервером из »нтернета, а web-сервер должен иметь возможность соединитьс€ с сервером базы данных. Ёти же два канала использует и нападающий, чтобы получить доступ к внутренней сети.

—етевые приложени€: основные вопросы

††††††††††††††††† “еперь, пон€в основы, мы должны пон€ть, как† оценить сетевые приложени€. ћы также кратко рассмотрели довольно простую, но обычную архитектуру сети. –ассмотрим теперь глубже первую часть плана оценок, о которой говорилось выше. Ќа какие вопросы вы должны ответить, сталкива€сь с изготовленным на заказ сетевым приложением? Ёти вопросы весьма просты, но важны, если мы надеемс€ проникнуть в глубь оцениваемого приложени€:

¬опрос 1:  то эти люди?

††††††††††††††††† ѕроект и архитектура продукта чаще всего отражают стиль и культуру организации, котора€ его создала. » обратно, многое можно пон€ть в проекте и архитектуре приложени€, если вы понимаете стиль и культуру организации. ћы ищем это понимание на двух уровн€х:

ќбщий: — какой группой мы имеем дело?  акой у них основной бизнес?  аков их стиль и культура?

„астный:  то разработал и развивал рассматриваемое приложение?  акие они имеют знани€, квалификацию, каков их стиль?

ќтветы на эти вопросы дадут нам понимание того, как приложение будет построено и где оно может содержать ошибки.

¬опрос 2:  ак приложение работает?

Ќа следующем этапе мы должны пон€ть, как рассматриваемое приложение собрано. ¬ы должны предприн€ть все усили€, чтобы пон€ть механизм работы приложени€. ѕриведем список важных моментов, которые необходимо рассмотреть:

1.ћожет ли приложение работать в диалоговом режиме? ≈сли да, то где расположены диалоговые элементы? Ќе каждый сайт €вл€етс€ диалоговым.  роме того, некоторые сайты более диалоговые, чем другие. ¬ы должны найти диалоговые элементы сайта и определить, насколько они диалоговые в действительности.

2. ак была построена система? ¬спомним прикладные платформы развити€, о которых говорилось выше.  аждый план развити€ имеет свои силы и слабости. ќпределив и пон€в основные компоненты, на которых приложение было построено, мы узнаем, где нужно начинать искать возможную у€звимость.

3.ќткуда приложение получает данные? ƒиалоговое приложение должно получать информацию из каких-то источников. ѕоскольку сетевые приложени€ не имеют "гражданства", необходимо найти место хранени€ данных пользователей. ќпределение места расположени€ конечного источника данных многое даст нам в понимании принципа работы приложени€ и того, как его можно взломать.

4. ак приложени€ получают данные? »так, сайт получает данные из какого-то дополнительного источника. ¬озможно даже с отдаленного сервера.  аким образом? »меетс€ много вариантов, включа€ запросы HTTP,† XML, обычный вход в файл и вечно попул€рный ODBC.  аждый из этих подходов оп€ть имеет сильные и слабые стороны, которые нужно определить.

5. ак они узнают мен€? ћногие сайты позвол€ют работать анонимно, то есть без установлени€ личности, но некоторые сайты предпочитают познакомитьс€ с вами, прежде, чем предоставить вам доступ. ≈сли это так, вам нужно понимать, как происходит установление вашей личности.  акими методами (например, Basic Authentication), и где хран€тс€ данные пользователей (например, в †NT SAM).

6. ак они отслеживают состо€ние?  ак только пользователь определен, не имеющее гражданства приложение должно отслеживать пользовател€. ќтслеживание состо€ни€ также необходимо в сложных процессах, когда результаты, полученные на предыдущем шаге, используютс€, как входные данные на следующем. ¬ каждом случае, отслеживание состо€ни€ - область, крайне склонна€ к ошибкам, и нужно иметь глубокое понимание этого при оценке приложени€.

¬опрос 3: ѕочему они выбрали именно этот способ?

Ќезависимо от ответов на предыдущие вопросы и архитектуры, которую вы узнали, всегда имеютс€ причины того, что система была построена именно тем способом, которым она построена. ≈сли мы сможем пон€ть мотивацию проекта, мы сможем пон€ть у€звимые места системы. ѕриведем список некоторых наиболее распространенных мотиваций.

  • Ћень.† „асто выбираетс€ более дешева€ и легка€ архитектура. Ћенивый проект Ц самый опасный проект.
  • ѕолитика.† „асто технические люди вынуждены придерживатьс€ некоторых технологий из-за стратегических или политических решений высокого уровн€ в данной организации. Ќапример, часто можно встретить организации, чьи стратегии придерживаютс€† компании Microsoft или, реже, открытых источников. ¬ этом случае архитектура, как правило, стандартна и хорошо известна.
  • Ќеопытность.† ћы уже говорили о том, что многие разработчики Web приложений неопытны и неквалифицированны. “акие разработчики имеют тенденцию "заимствовать" и копировать программы с сайтов и других общественных источников, и склонны допускать глупые, любительские ошибки.
  • —верхопытность. †¬ нашей индустрии специалисты высочайшего класса в своей узкой области, часто пытаютс€ переносить свой опыт на другие области. ќпределение† специфического "конька" разработчика подскажет вам, где можно даже не искать у€звимости, а в каких новых дл€ разработчика област€х у€звимости могут находитьс€.

¬опрос 4:  аковы типичные ошибки данной архитектуры?

“еперь, когда вы имеете общий вид оцениваемой системы, вы можете начать искать возможные ошибки безопасности. ¬ы просматриваете пути сквозь защиту разработчика в попытках найти ошибки, которые он, возможно, просмотрел. ¬ п€той и заключительной части этой серии статей мы обсудим некоторые обычные категории ошибок программировани€ и рассмотрим некоторые частные примеры. “еперь, когда мы создали фундамент дл€ понимани€ того, чем €вл€ютс€ сетевые приложени€ и как они работают, мы можем исследовать, как оценивать их† дл€ риска безопасности »нтернета, что будет сделано в следующей (и последней) статье в этой серии.

или введите им€

CAPTCHA