Використання сучасних Javascript фреймворків для розробки Web-модулів CRM-систем обслуговування авіарейсів

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

<title> Home Page </ title> <meta content="Microsoft Visual Studio 7.0" name="GENERATOR"> <meta content="C#" name="CODE_LANGUAGE"> <meta content = "JavaScript" name = "vs_defaultClientScript" >

Маніпулювати вхідними даними для отримання помилок скриптів

У наступному прикладі ми викривлюємо найбільш очевидну змінну (ItemID) для отримання інформації про оточення web-додатки:

Використовувати сканування TCP / ICMP і сервісів

За допомогою традиційних засобів сканування, таких як Nmap і Queso, або більш нові аналізатори додатків Amap і WebServerFP, тестуючий може отримати більш точну інформацію про використовувану операційну систему і використовуваному програмному оточенні, ніж за допомогою багатьох інших методів. Nmap і Queso використовують перевірку особливостей реалізації TCP / IP на досліджуваному хості для визначення операційної системи і, в деяких випадках, версій ядра і встановлених патчів. Аналізатори додатків использут таку інформацію як серверні HTTP-заголовки для визначення запущених на хості додатків.

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

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

<FORM METHOD="LINK" ACTION="/shop/checkout.htm"> <INPUT TYPE="HIDDEN" name="quoteprice" value="4.25"> Quantity: <INPUT TYPE = "text" NAME = "totalnum" > <INPUT TYPE="submit" VALUE="Checkout"> </ FORM>

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

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

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

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

<INPUT TYPE="SUBMIT" onClick=" if (document.forms['product'].elements['quantity'].value> = 255) {document.forms ['product']. Elements ['quantity']. value =''; alert ('Invalid quantity'); return false;} else {return true;} ">

Це означає, що програма намагається захиститися в обробнику форми від передачі у змінній quantity значень, більших або рівних ніж 255 - максимальне значення для поля з типом tinyint в більшості баз даних.

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

Визначення механізмів аутентифікації

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

Слід уточнити, що під середовищем web-додатків розуміється безліч протоколів, мов та форматів (HTTP, HTTPS, HTML, CSS, JavaScript і т.п.), які використовуються в якості платформи при створенні web-додатків. HTTP забезпечує два види аутентифікації: BASIС і Digest. Вони обидва реалізовані в якості серії HTTP-запитів і відповідей, в рамках якої клієнт запитує ресурс, сервер вимагає аутентифікацію, і клієнт повторює запит, забезпечивши його аутентифікаційних посвідченням (логін + пароль).

Вся різниця між ними полягає в тому, що в разі Basic-аутентифікації інформація передається у відкритому вигляді, а у разі Digest - шифрується за допомогою ключа, згенерованого сервером.

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

З урахуванням цього, тестуючий повинен спробувати встановити як використовуваний механізм аутентифікації, так і те, яким чином цей механізм застосований по відношенні до кожного ресурсу, використовуваному web-додатком. Багато web-системи пропонують засоби підтримки сесій, засновані на збереженні в cookie або Session-ID псевдоунікальной рядки, що характеризує їх статус. Такий підхід може бути уразливий до таки атакам, як прямий перебір, повторна відправка, або спроба відновлення - в тому випадку якщо даний рядок є простим хешем або рядком, складеної з відомих елементів.

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

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

Модуль сумісний з наступними браузерами:

· Internet Explorer 7 +

· Opera 10 +

· Safari 4 +

· Google Chrome 9 +

· FireFox 3 +

Під час тестування сайту були отримані позитивні результати, не було помічено збоїв в роботі, але сумісність з Internet Explorer 6 існує на рівні javascript-коду. Верстка і дизайн відображається некоректно.

Рисунок 3.1 - Тестування web-додатку

Висновок

В ході виконання дипломної роботи було розроблено модуль пошуку та бронювання авіаквитків. Модуль володіє ергономічним і інтуїтивно зрозумілим інтерфейсом, що дозволить користувачам без проблем самостійно знайти і забронювати авіаквиток на потрібну дату і рейс. Було детально досліджено та проаналізовано предметну галузь, що дозволило визначити методи реалізації, також було запропоновано декілька методів вирішення проблеми та обрано можливість створення власного web-додатку, що могло б вирішити проблему централізації потрібної інформації. Проаналізувавши недоліки існуючих аналогів було створено вимоги до програмного продукту. Враховуючи тему та можливості сучасних мов програмування для створення web-додатків було обрано javascript та середовище для розробки Visual Studio 2008.

Після дослідження javascript фреймворків було обрано найдоцільніші та сумісні між собою, і зручними для користувача.

Література

1. Мартин Дж. Организация баз данных в вычислительных системах.-- М.:Мир,1980.

2. Тиори Т., Фрай Дж. Проектирование структур баз данных: В 2-х кн.--М.:Мир, 1985.

3. Четвериков В.Н. и др. Базы и банки данных.-- М.: Высшая школа, 1987.

4. Змитрович А.И. Базы данных.--Минск.: Университетское, 1981.

5. Бойков.В., Савинков В.М. Проектирование баз данных информационных систем. М. Мир 2007.

6. Х.М. Дейтел, П. Дж. Дейтел, С.И. Сантрі Програмування на JavaScript - ДиаСофтЮП, 2010.

7. Герберт Шилтд, Джеймс Холмс, Искусство программирования на JavaScript, М: Вильямс, 331с.

8. Монкур, Майкл Освой самостоятельно JavaScript за 24 часа; М.: Вильямс, 2009. - 320 c.

Размещено на Allbest.ru