4 – Навігатор, в даній області розміщуються номери завдань тестового блоку. Слід зауважити, що червоним виділяються ті завдання, які користувач ще не проходив, синім – відповідь на дане завдання була зафіксована. Існує можливість змінити відповідь на будь-яке завдання в будь-який момент часу. 5 – Область відображення завдання і його структури.

Рисунок 3.14 – Сторінка із тестовим завданням (Простий вибір)

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

Рисунок 3.15 – Форма по результатам проходження тестування

3.5 Реалізація алгоритмів автоматизованої системи

Реалізація алгоритмів системи (точніше написання програмного коду) – найважливіша задача, від її вирішення залежить досягнення поставленої мети. Для грамотного написання програмного коду, необхідно досконало вивчити можливості вибраних засобів, а також по можливості використовувати готові доробки інших розробників.

Однією із проблем при реалізації системи є механізм розділення роботи користувачів із системою. Як було зазначено в першому розділі протокол HTTP не підтримує інформацію про стан конкретного клієнта, тому для вирішення цієї задачі необхідно разом із іншими даними відправляти на клієнтську машину деяку службову інформацію. В термінах мережі Інтернет (а точніше взагалі в термінах клієнт/серверного програмного забезпечення) весь цей механізм називається механізмом управління сеансами, тому детально розглянемо принцип управління сеансами роботи користувачів.

3.5.1 Управління сеансами

Сеанс – це послідовність HTTP-запитів, зроблених протягом визначеного інтервалу часу одним і тим же користувачем з одного і того ж комп’ютера до однієї і тієї ж web-програми.

Методологія підтримки сеансів базується на наступному. При першому запиті користувача генерується новий сеанс, а всі наступні запити розглядаються як частина цього сеансу, якщо вони згенеровані в рамках заданого інтервалу часу. Основним елементом сеансу є його ідентифікатор (session identifier), який однозначно визначає сеанс. Кожний сеанс може існувати одночасно із сотнями сеансів інших користувачів. Згненерований і відправлений ідентифікатор сеансу (ID сеансу) повинен бути унікальним і в той же час достатньо захищеним, щоб зловмисник не міг легко його підробити. Наприклад, хоча послідовність цілих чисел 1, 2, 3, 4 відповідає вимогам унікальності, але вона не гарантує захищеності сеансів. Справа в тому, що користувач з 3-тім номером сеансу може легко змінити його на номер 4 і отримати доступ до сеансу іншого користувача.

Зберігання сеансу. Після генерації ідентифікатора сеансу, необхідно забезпечити зберігання даного ідентифікатора при подальших запитах. Існує два способи вирішення цієї проблеми: модифікація URL і cookie дані. Розглянемо спочатку принципи реалізації цих підходів.

Модифікація URL. Це найпростіший спосіб збереження сеансу. При його використанні ідентифікатор сеансу включається в якості параметра методів GET і POST при кожному зверненні за посиланням, при передачі даних форми або при виконанні функцій JavaScript.

Хоча метод модифікації URL теоретично є найпростішим, використання даних cookie ще простіше, оскільки потребує меншої зміни програмного коду, а то й взагалі можна обійтись без змін. Дані cookie – це невеликі фрагменти інформації, які відправлені програмі навігатору web-сервером разом із результатами запиту. Клієнтська програма записує цю інформацію і надає її при наступних запитах тому ж web-серверу. Як і змінні дані cookie мають ім’я і значення. Деякі з них включають час і область дії (для яких серверів вони призначені). При кожному запиті до web-сервера клієнтська програма надає імена і значення cookie змінних, які мають відношення до відповідного вузла. Прострочені дані автоматично видаляються клієнтською програмою, web-сервер також може видаляти cookie з пам’яті клієнтської програми.

Безпека сеансу. Чи дійсно ідентифікатор сеансу є безпечним. Існує декілька ризиків, пов’язаних з використанням ідентифікатора сеансу для визначення зареєстрованого користувача, однак деякі заходи дозволяють мінімізувати ці ризики.

Якщо недобросовісний відвідувач вузла якимось чином дістане коректний ідентифікатор сеансу, він зможе виконувати будь-які дії від імені власника сеансу. Якщо користувач А використовує ідентифікатор сеансу Х, а недобросовісний користувач Б виконує запит із таким же ідентифікатором сеансу, то web-сервер вважатиме, що користувач Б є користувачем А і може мати доступ до будь-якої інформації, яка доступна для користувача А, в тому числі і до конфіденціальної. Для реалізації цього сценарію потенційному хакеру необхідно підібрати коректний ідентифікатор сеансу. При використанні мови РНР ідентифікатор сеансу це 32-розрядний набір символів a…z, 0…9, тобто загальна можлива кількість комбінацій ідентифікатора – 3632. Для забезпечення ще більш надійного захисту в [5] пропонується використовувати інтервали очікування. Інтервал очікування це окремий параметр. Використання інтервалів очікування передбачає реєстрацію часової мітки кожного запиту і оцінювання часу між наступними запитами в період існування сеансу. При закінченні часу очікування (5 або 10 хвилин) строго рекомендується переривати сеанс і вимагати повторної реєстрації користувача. Це достатньо ефективний засіб. Багато з описаних вище атак передбачають використання ідентифікатора сеансу одразу після його закінчення. Зменшуючи інтервал часу між запитами до декількох хвилин тим самим знижується ефективність даних атак. Взагалі розглянути в межах даної роботи всі можливі проблеми неможливо.

3.5.2 Підсистема адміністрування

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