Захист Java і ActiveX

Аніта Карвен, Lan Magazine

Коди Java і ActiveX виконуються локально, на машинах кінцевих користувачів, піддаючи ці машини небезпеки нападу. Тим важливіше знати, яким чином подібні атаки можна запобігти.

Зміст

Звернемося до JAVA
Весь світ в пісочниці
Світ за пісочницею
Придивімося до ACTIVEX
Пильнуй!

Нехороші аплети
Захист JAVA

Отже, будь-який користувач браузера Web – будь то Netscape Navigator або Internet Explorer корпорації Microsoft – стає рядовим зростаючої армії користувачів Java. При цьому неважливо навіть, що такий користувач може зовсім не вміти програмувати і не претендує на звання розробника ПЗ, що знає алгоритмічні мови вздовж і впоперек і здатного з закритими очима знайти помилку в коді C або C + +. Варто тільки людині запустити один із самих популярних браузерів – і він вже користувач Java, подобається йому це чи ні.

Немає нічого простішого, ніж заглянути в чарівний світ Java – кожен, хто хоч раз бачив якесь переливаються всіма кольорами веселки, що обертається назву у вікні браузера, може вважати, що вже побував там. Корпорація Microsoft, не бажаючи відстати від Sun Microsystems, запропонувала свій власний виконуваний код, відомий як ActiveX. Це середовище дозволяє розробникам створювати елементи управління, засновані на програмної архітектурі Component Object Model (COM). Остання служить для підтримки створення додатків на таких мовах, як C і C + +. Аплети Java широко застосовуються зараз на вузлах Web, при цьому поки тільки деякі використовують ActiveX.

На жаль, не всі користувачі знають, що і Java, і ActiveX посилають код на клієнтський комп'ютер, де цей код і виконується. Усі так звані мобільні або переносяться програми потрапляють безпосередньо в клієнтську систему і роблять там те, для чого вони написані. Це відбувається незалежно від бажання користувача, якщо в установках захисту немає відповідної заборони.

Неважко здогадатися, що сама думка про те, що якийсь невідомий і "неблагонадійний" код проникає з віддаленого сервера на робочу станцію або мережевий шлюз, викликає занепокоєння в кінцевих користувачів та адміністраторів мережі. У самому справі ніхто ж не знає, що за людина писала ось цей шматок програми і що було при цьому в нього на думці!

Мабуть, всякий "ходив по Мережі" хоч раз та читав повідомлення про мобільних програмах, що роблять на настільних комп'ютерах всякі капості. (Більш докладно вони описані в урізанні "Гарний, поганий, злий".) Правда в тому, що більшість представників преси, так само як і розробників, не має цілісної картини можливу небезпеку, яку несуть Java і ActiveX.

У цій статті ми хотіли б дати загальне уявлення про мобільні кодах, в тому числі про їх важливість для кожного, хто займається бізнесом, особливо використовуючи для цієї мети Internet. Крім того, тут розглянуті моделі забезпечення безпеки як для Java, так і для ActiveX. Стаття також познайомить читачів з тими заходами, які можна прийняти, щоб не стати жертвою зловмисних програм.

Звернемося до JAVA

Коли на початку 1995 року Sun представила Java, розробникам і виробникам здалося, що у них в руках опинилася чарівна паличка. У них були всі підстави радіти: Java обіцяв зробити Web реально придатним для комерції і давав добрі шанси вирватися вперед і перемогти конкурентів. Аплети Java – маленькі порції стерпного виконуваного коду, що працює на всіх, хто має доступ до Web машинах, надавали перевагу тим компаніям, які хотіли б вийти на неосяжний інтерактивний ринок.

Спочатку аплети застосовувалися в основному для реклами в Web. Виробники заповнили вузли блискучими і крутяться, заставками для залучення уваги дозвільних "мандрівників". Навіть у цих самих ранніх аплетах код, породжувала їх, передавався на клієнтську машину, де і виконувався підтримує Java браузером. Вже тоді доводилося тільки гадати, хто ж був автором цього коду, і перед користувачем стояла альтернатива: відмовитися від насолоди красою Web або ризикувати цілісністю своєї системи.

Час йшов, Web "дорослішала", з'являлися нові способи застосування Java. З іграшки, придатної лише для створення рухомих картинок, мова перетворилася на засіб реалізації технології примусового розповсюдження програмного забезпечення і навіть електронної комерції.

Зачаровані такою силою і міццю, клієнти стали все частіше запитувати серйозні питання щодо того, що ж насправді може і чого не може Java зробити з їхніми комп'ютерами. Так що вкрай корисно отримати хоча б

загальне уявлення про те, як Java працює і як середовище Java реалізована

в Web. Перш за все розробники пишуть вихідний код на мові програмування Java. Компілятор перетворює цей код в байт-код Java. Байт-код у формі аплету розміщується на сторінці Web, доступ до якої здійснюється за допомогою браузера, розрахованого на роботу з Java. Браузер перевіряє код, після чого віртуальна машина Java (Java Virtual Machine, JVM) здійснює виконання аплета на клієнтській машині.

Навіть з такого побіжного опису стає ясно, що до того, як код Java виявляється в небезпечній близькості від комп'ютера користувача, він піддається якимось процедур, метою яких є запобігання попадання в систему шкідливих кодів. Цій меті служать, наприклад, механізм перевірки легітимності коду і його виконання в обмеженій області браузера. Деякі запобіжні заходи будуть далі описані більш детально.

Незабаром після того, як Java набув широкого поширення, фахівці і рядові користувачі стали виявляти прогалини в забезпеченні безпеки комплекту розробника Java Developers Kit (JDK). JDK складається з кількох компонентів (включаючи мову для перетворення команд в байт-код і JVM для виконання байт-коду на різноманітних платформах). По суті він надає базову технологію для створення і виконання кодів Java.

"Дірки в захисті – зараз вони ліквідовані – мали різне походження: деякі виникли через простих помилок реалізації, інші мали принциповий характер", – пояснив Гері Макгро, дослідник з Reliable Software Technologies, що вивчає питання безпеки Java з перших днів існування технології.

Він додав, що кожна нова реалізація JDK (на початку 1998 року почнуться масові поставки версії 1.2) породжувала нові проблеми з безпекою, проте знайдені помилки незмінно швидко усувалися. "Чим більше складність, тим більша ймовірність помилки, – визнав дослідник. – Я впевнений, знайдеться ще маса недоліків". На думку Макгрея, через ажіотажний попиту компанії Кремнієвої долини квапляться з випуском коду, так що безпека відходить на другий план.

Весь світ в пісочниці

Java з самого початку була задумана як технологія, за допомогою якої одного разу написана програма могла виконуватися на будь-якій платформі. І так як Java може працювати в системі практично будь-якого типу, і оскільки аплети Java з віддаленого сервера виконуються на клієнтській машині, JavaSoft, підрозділ корпорації Sun, доклало чимало зусиль до того, щоб вирішити питання захисту на рівні мови програмування. Багато виробників люблять повторювати, що безпека Java – це не що інше, як оксюморон, але творці мови з самого початку знали, що питання захисту будуть мати вирішальне значення для долі запропонованої технології.

Вся система безпеки Java будується навколо так званої моделі безпеки Sandbox (цей термін можна приблизно перекласти як "пожежний ящик з піском"). Ця ідея реалізована вже в ранніх версіях JDK 1.0.x. Sandbox передбачає обмежену середовище для виконання аплетів Java, неблагонадійних віддалених кодів. Суть принципу Sandbox полягає в тому, що локальні коди вважаються надійними, і в їхнє розпорядження надаються файли та інші системні ресурси, а файли видалені коди – ні. Їм відкривається доступ тільки до певних ресурсів у межах Sandbox.

У рамках цієї моделі Java отримує кілька додаткових функцій забезпечення безпеки, що гарантують захищеність систем, що допускають коди всередину. Кожен з компонентів повинен розміщуватися в певному місці і функціонувати належним чином, інакше не буде працювати вся модель.

Так, наприклад, засіб перевірки байт-коду повинна гарантувати виконання на клієнті тільки легітимного коду Java. Коли код досягає клієнтської робочої станції, Верифікатор перевіряє кожен фрагмент на предмет дотримання обмежень доступу та його цілісності.

Ще один з компонентів захисту Java – це завантажувач класів, який визначає, за яких обставин аплету дозволено додавати класи. Результати компіляції вихідного коду Java поміщаються у файли класів, що містять найрізноманітніші дані, наприклад налагоджувальну інформацію або відомості про клас. Як правило, завантажувач класів поставляється з браузером.

Є і третій захисник – це диспетчер захисту Java, що обмежує діяльність нелегітимного коду. Це засіб допускає настройку і, крім своїх інших численних обов'язків, передбачає, наприклад, запобігання установки нових завантажувачів класів, контроль над операціями з файлами, такими як читання і запис, суворий нагляд за доступом до локальних файлів і контроль над створенням і доступом до системних програмам і процесам.

Якість захисту Java залежить від того, наскільки добре ці компоненти справляються з кодами, які надходять з віддаленого сервера. Зрозуміло, будь-які недоліки можуть зробити даремною всю цю струнку систему захисту, тому так важливо бути в курсі змін ПО браузерів.

СВІТ ЗА ПІСОЧНИЦІ

JavaSoft постійно працює над JDK, і, звичайно, ця робота полягає не тільки в латання дірок, а й у вдосконаленні самої технології.

У JDK 1.1.x компанія вперше запропонувала можливість підписувати аплети. Це означає, що або творець коду, або незалежна компанія, готова поручитися за розробника, проставляє на аплеті цифровий підпис, який є додатковою гарантією легітимності коду, що надходить з віддаленого вузла.

Цифровий підпис Java заснована на технології шифрування з відкритим ключем. Принцип шифрування відкритим ключем припускає, що інформація, зашифрована однією стороною, може бути розшифрована другою стороною відомим тільки їй особистим ключем, пов'язаним з першим якоїсь математичної функцією.

Завдяки технології цифрових підписів, розробник може застосувати свій особистий ключ до фрагмента коду Java, а потім завізувати його в авторизованого з видачі сертифікатів (Certificate Authority, CA). Остання підпис засвідчує особистість власника пари ключів. Приймаюча сторона перевіряє сертифікат уповноваженого, а також те, що інформація про відправника коду не застаріла і не була відкликана.

В опціях захисту і Navigator, і Internet Explorer передбачена можливість відбору заслуговують довіри сертифікатів CA. Цей список можна редагувати, видаляючи всіх уповноважених, яким користувач не довіряє.

У моделі захисту JDK 1.1.x тільки код, чий сертифікат визнається клієнтом, може розглядатися як локальний; відповідно до прийнятої політикою щодо підписів. Усі інші "потрапляють" в Sandbox з дуже обмеженими правами доступу.

У JDK 1.2 розробники вийшли за рамки традиційної моделі Sandbox і запропонували більш гнучку схему. У новій версії, на думку Лі Гонг, фахівця з архітектури захисту в JavaSoft, інструментарій JDK дає користувачеві більш досконалі методи контролю доступу. "У JDK 1.2 система не заганяє всі аплети в Sandbox, а надає користувачеві можливість вибору", – пояснив він.

Крім того, в JDK 1.2 всі локальні коди не вважаються завідомо яким Ви довіряєте, всі вони – видалені або локальні – піддаються однаковою перевірці. Які дії дозволені того чи іншого фрагменту коду, визначає політика кінцевого користувача у відношенні захисту. Так, деякі типи кодів будуть поміщені в Sandbox, в той час як інші отримають більш широкі можливості доступу (Див. Малюнок 2).

З точки зору галузевих експертів, новий підхід до організації захисту може виявитися палицею з двома кінцями. Гнучкість JDK 1.2, безумовно, представляє великий інтерес, оскільки дає кінцевим користувачам і адміністраторам мереж можливість управляти ступенем доступу до Sandbox в залежності від того, хто підписав або поручився за достовірність аплету. Наприклад, апплетам, підписаним А, буде дозволено читати файли, аплети ж, підписані В, будуть поміщені в Sandbox. Виборчий характер контролю означає, крім усього іншого, що хтось повинен налаштувати політику захисту на клієнта відповідно з тим, хто поручився за достовірність аплету, якими ресурсами аплету дозволено користуватися і які на нього накладено обмеження.

"Виробити дієву та несуперечливу стратегію непросто, – попереджає Макгро. – Щось подібне відбувається і з брандмауерами. Багато хто купує їх, виходячи з прейскуранта, і перебувають в повній впевненості, що тепер надійно захищені. Головною ж завжди залишається вироблення правил і коректна їх налаштування ".

Макгро додає, що вся робота по конфігурації і налаштуванні правил захисту потребує втручання професіонала в області захисту, але невеликі компанії не мають в штаті таких співробітників, і вся тягар цієї роботи лягає на плечі і без того завантажені мережевих адміністраторів. "Робота мережевого адміністратора стала значно важче, оскільки доводиться враховувати вимоги численних користувачів. Це тим більш непросто на рівні аплета ", – поскаржився Макгро.

Придивімося до ACTIVEX

До цих пір нашу розповідь стосувалося виключно Java. Це не дивно, якщо врахувати, як багато розробників і користувачів взяли на озброєння цю мову програмування компанії Sun і, відповідно, як багатьох користувачів турбує його безпеку і характер потенційної загрози.

Технологія ActiveX корпорації Microsoft до цих пір не отримала такого широкого поширення, як Java, можливо, через те, що вона не є крос-платформенний. Аплети Java пишуться тільки один раз, після чого без змін виконуються на будь-якому комп'ютері, де є JVM. Елементи управління ActiveX, навпаки, створюються окремо для кожної операційної системи.

І ActiveX, і Java – це завантажуваний, що виконується інформаційне наповнення, і, при всій схожості, вони разюче відрізняються один від одного в тому, що стосується забезпечення захисту. Java має цілий ряд вбудованих засобів, що гарантують безпеку, в той час як в ActiveX їх украй мало. У багатьох компаніях рішуче не довіряють захист ActiveX і забороняють використовувати цю технологію в своїх мережах.

В елементах управління ActiveX використовується "рідний" код, отже, вони можуть робити все те ж, що і програми Windows, в тому числі читати і записувати файли, а також отримувати будь-яку інформацію про систему, де працюють, – тобто все, що тільки забажає програміст, який створив такий елемент.

ActiveX підтримує якесь засіб під назвою Authenticode, що дозволяє розробнику візувати компоненти ActiveX за допомогою цифрового підпису. Так що при зустрічі з таким елементом в Web користувач має можливість отримати уявлення про автора і вирішити, наскільки він заслуговує довіри. Більшість компаній, які допускають ActiveX до своїх мереж, користуються виключно підписаними компонентами. Життєва мудрість говорить, що непідписаних елементів треба цуратися, як чорт ладану. У випадку з не підписаними аплетами Java, які б підозри вони ні викликали у користувачів, модель захисту Sandbox і засіб перевірки байт-кода значно знижують ризик зловмисних дій при виконанні програм.

Ви можете зробити і інші заходи, щоб захиститися від потенційно небезпечних елементів керування ActiveX. Наприклад, повністю блокувати ActiveX з браузера Internet Explorer. Користувачам Navigator доведеться завантажити для цього модуль розширення. Інша міра – перевірка благонадійності самого розробника або поручився за нього уповноваженого з видачі сертифікатів.

Однак що не кажи, а Microsoft доведеться додавати в ActiveX функції, аналогічні Sandbox. Компанія не робила з цього приводу ніяких заяв, але їй слід доповнити ActiveX чимось подібним, якщо вона хоче, щоб її технологія могла претендувати на такий же успіх, як Java. Поки ж тим, кому конче потрібно виконувати непідписані коди, нічого не залишається, як користуватися Java.

Пильнуй!

Отже, прогалини у забезпеченні безпеки є і у Java, і у ActiveX, однак у більшості випадків компаніям, які належать до мобільних кодами розумно і які вживають запобіжних заходів, боятися нічого.

Перш за все стратегія компанії в області інформаційної захисту повинна бути детально пророблена. Тим, у кого немає штатного фахівця із захисту, слід проконсультуватися з експертом у цій області.

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

Однією з перших продукт такого роду на ринок поставила Finjan. Компанія пропонує системи, які аналізують інформаційне наповнення, що містить Java і ActiveX, на рівні шлюзу Internet та на настільному комп'ютері (докладніше див в статті Олександра Авдуевского "Серфінг за щитом" в грудневому номері журналу LAN за минулий рік).

Компанія Digitivity розробила AppRouter, який розпізнає приходять аплети і потім завантажує фіктивний аплет замість оригінального. Цей аплет зв'язується з виробленим цією ж компанією сервером CageServer, на якому і виконуються оригінальні аплети Java. Таким

чином, який би аплет користувач ні завантажив з Web, код спрямовується на спеціальний сервер, а не до користувача. Аплет виконується на цьому сервері-посереднику, а результат відображається в браузері. Таким чином, код не взаємодіє ні з одним мережевим ресурсом, крім спеціального сервера.

Ще одна компанія, Security-7 Software, поставляє продукт під назвою SafeGate, здійснює аналіз Java і ActiveX в режимі реального часу.

Ці продукти, а також вбудовані функції останніх версій браузерів дають користувачеві можливість повністю блокувати всі мобільні коди на своєму сайті. Втім, чи варто ховати голову в пісок? Java і ActiveX вкрай важливі для компаній, що працюють у Internet, і прагнення самоусунутися від них зараз може призвести до непереборному відставання в майбутньому.

Зрозуміло, мобільні коди можуть служити знаряддям зловмисників. Але ці – не такі численні – випадки повинні не відлякати, а спонукати більш поглиблено вивчати технологію. Тоді компанії отримають вигоду від її застосування, а їх мережеві ресурси залишаться в цілості й схоронності.

Аніта Карвен – помічник редактора Network Magazine. З нею можна зв'язатися за адресою: akarve@mfi.com.

Нехороші аплети

Хороший, поганий, злий

Хоча відомо лише кілька випадків, коли аплети Java завдавали шкоди обчислювальної системі, завжди повчально знати, яку небезпеку вони в собі несуть.

Так звані ворожі аплети можуть мати кілька різновидів. Перша, здатна принести максимальний шкоду, називається іноді "атакуючим аплетом". Творці таких програм використовують "Дірки" у захисті Java, попереджає Гері Макгро, дослідник компанії Reliable Software Technologies, довгий час вивчав технологію Java.

На щастя, атакуючих аплетів до цих пір не зареєстровано в мережі, але вони дійсно існують. "Їм не вдалося покинути лабораторії; дослідники виявили їх існування раніше зловмисників", – Говорить Макгро.

Ці аплети здатні викликати великі руйнування, особливо на машинах, де не працюють новітні версії браузерів. Однією з найбільш небезпечних атак є спроба аплету звернутися до інших мережевих пристроям. Так як аплет був допущений на машину і тепер ініціює атаку зсередини, брандмауер тут безсилий.

За іншим сценарієм код Java, допущений на одну машину, може спробувати замаскуватися під користується довірою локальний код і таким чином отримати доступ до локального диску. "Фактично атакуючий аплет діє як хакер, який встановлює контроль над машиною користувача та змінює його систему ", – пояснив Макгро.

Атакуючі аплети до цих пір представляють тільки теоретичний інтерес, але ворожий код іншого типу, званий "зловмисний аплет", вже гуляє на волі. Якщо атакуючі аплети за самим своїм призначенням заподіюють шкоду, зловмисні, як правило, діють користувачам на нерви. Вони необов'язково створюються зі злого наміру. У більшості випадків програміст просто чесно пише програми з помилками. Але трапляється і таке, що "певні суб'єкти" пишуть такі аплети спеціально для того, щоб дошкулити користувачам.

У кінцевому підсумку це призводить до неможливості для користувача продовжувати роботу, оскільки аплет вивів з ладу браузер або заблокував всю машину; до порушення конфіденційності, коли аплет збирає такі дані, як IP-адреса комп'ютера, а також до підробки електронної пошти.

"На наше глибоке переконання, 99,5% користувачів Internet – порядні люди, і зловмисні коди фабрикує маленька жменька ізгоїв, – впевнений Енді Бруно, директор з маркетингу компанії Digitivity, що займається розробкою продуктів для захисту корпоративних мереж від ворожих кодів. – Зловмисні коди зустрічаються поки нечасто, тим не менш користувачеві слід регулярно переглядати журнали подій і результати аудиту, щоб мати уявлення про те, що ж, власне, відбувається в мережі ".

При знаходженні проломів у захисті JavaSoft і незалежні дослідники швидко їх ліквідовують, щоб хто-небудь не розробив аплети, які використовують у зловмисних цілях подібні дірки. Однак люди, подібні до тих, хто проник в мейнфрейми Міністерства оборони чи ЦРУ, достатньо кмітливі, щоб виявити нові недоліки захисту Java до того, як вони будуть усунені.

Захист JAVA

Отримати повну інформацію з питань безпеки Java можна, прочитавши книгу Гері Макгрея і Едварда В. Фелт "Захист Java: Ворожі аплети, дірки і протиотрути" ("Java Security: Hostile Applets, Holes, and Antidotes ", Wiley Computer Publishing, 1997).

Відповіді на типові питання щодо захисту Java зібрані за адресою: http://java.sun.com/sfaq.index.html.

Для пошуку інформації про ворожі аплетах та інших питаннях захисту Java зверніться на www.rstcorp.com/~gem/.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*