SEOSERVISE - Защита информации.

 
   
 

Главная


 


Java ; удаленное выполнение команд В начале своего развития Web -технологии были очень простыми и позволяли ис­ пользовать лишь наиболее примитивные возможности протокола HTTP и языка HTML . Однако по мере роста потребностей в динамическом содержимом Web тради­ ционные языки и протоколы Internet становились все менее эффективными. Начали развиваться новые технологии, призванные логически расширить HTTP и HTML . Первым событием в повышении динамичности содержимого Web стало появление CGI ( Common Gateway Interface — интерфейс общего шлюза). Как уже упоминалось в главе 1, CGI -програм.мы в основном разрабатываются на языках С, C++ и Perl . Именно они и стали предвестником того, что должно было появиться чуть позже. Эволюция Web -приложений от статических и простых порталов до динамичных и красочных хранилищ информации открыла новые горизонты как для конечного поль­ зователя, так и для взломщика. В то время практически все программы были плохо написаны и содержали изъяны даже в самых общих процедурах защиты, используе­ мых в процессе получения и обработки пользовательских данных. В результате CGI - программы содержали многочисленные ошибки, которые можно было использовать для получения нсавторизованного доступа к файловой системе и базам данных. Ино­ гда можно было получить даже интерактивный доступ к удаленной командной обо­ лочке. Причинами наличия таких уязвимых мест были сценарии, в которых не вы­ полнялась проверка входных данных и которые имели несовершенные механизмы ау­ тентификации и слабую интеграцию с другими частями системы. Эволюция динамического содержимого представлена в табл. 12.1. CGI - cueiiapmi были не очень эффективны и с трудом поддавались масштабируе­ мости. Каждый раз при выполнении CGl -сценаркя или программы в системе созда­ вался новый процесс. Для преодоления этих узких мест и создания новой, более за­щищенной архитектуры различные производители приступили к разработке новых технологий. Независимо друг от друга такие компании, как Microsoft , Allaire и Sun , предложили новые архитектуры, в которых учитывались современные требования к производительности и безопасности. Однако на каждой фазе эволюции архитектуры в ней появлялись новые недостатки. Сервер IIS и технология ASP компании Microsoft оказались уязвимыми к атакам, связанным с переполнением буфера, получением исходного кода, просмотром ката­ логов и удаленным выполнением команд. Система ColdFusion от компании Allaire со­ держала архитектурные изъяны, которые привели к возможности реализации атак DoS и получения исходного кода. В других технологиях, разработанных, например, компанией Netscape , использовались так называемые надстройки. Эти модули позво­ ляли добавлять новые функции и интегрировать их с Web -сервером. В этой архитек­ туре на Web -сервере можно было использовать различные языки сценариев, такие, как ASP , PHP и CFM (более полная информация об этих технологиях содержится в главе 1). С каждым из этих серверных ресурсов были связаны свои расширения, та­ кие, как . asp , . php и . cfm . Если клиенты Web обращались к этим ресурсам, то их за­ просы обрабатывались дополнительными модулями. При этом для обмена информа­ цией использовался протокол HTTP . Для облегчения программирования дополни­ тельные модули поддерживали специальные дескрипторы, которые можно было использовать в коде самой HTML -страницы. В то время как появлялись и развивались новые технологии, например ASP , Cold ­ Fusion , PHP и т.д., компания Sun Microsystems решила расширить технологию Java и адаптировать ее для использования в Web . Так появились технологии, основанные на языке Java . Таблица 12.1, Эволюция динамического содержимого Этап Архитектура Причина появления • Простые HTTP - серверы Необходимость односторонней передачи содержимого • HTTP + CGI - лрограммы Появление интерфейса CGI обусловлено необходимостью поддержки динамического взаимодействия сервера и клиента . Каждая операция ввода - вывода порождает отдельный процесс • HTTP + простые языки Синтаксический анализ и обработка сценариев для каждого клиент - сценариев ского запроса порождает новый процесс • HTTP + предварительно Вместо порождения нового процесса на уровне операционной систе - откомпилированные про - мы сервер с многопоточной архитектурой способен обрабатывать ка - граммы ждый клиентский запрос в отдельном потоке

 

 

 

 

 

 
 

1 |2 |3 |4 |5 |6 |7 |8 |9 |10 |11 |12 |13 |14 |15 |16 |17 |18 |19 |20 |21 |22 |23 |24 |25 |26 |27 |28 |29 |30 |31 |32 |33 |34 |35 |36 |37 |38 |39 |40 |41 |42 |43 |44 |45 |46 |47 |48 |49 |50 |51 |52 |53 |54 |55 |56 |57 |58 |59 |60 |61 |62 |63 |64 |65 |66 |67 |68 |69 |70 |71 |72 |73 |74 |75 |76 |77 |78 |79 |80 |81 |82 |83 |84 |85 |86 |87 |88 |89 |90 |91 |92 |93 |94 |95 |96 |97 |98 |99 |100 |