Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Надёжность и защита информации автоматизированных систем. Учебное пособие.pdf
71
Вход
URL.
hostname
Вернуть
результат 0
Выход
Вернуть
результат 1
Подсчет
количества
символов в
URL
Длина URL <
Допустимого
значения?
Да
Нет
Для записи 1..N в
списке допустимых
значений
Сравнение
hostname и
записи
Hostname
найден?
Нет
Получение
допустимого
значения
Да
Рис. 2.14. Алгоритм определения длины URL
72
при изменении которого должно изменяться и допустимое количество символов, т.е. есть прямая зависимость разрешения экрана
и допустимого количества символов в адресной строке, которое
может видеть пользователь. Поэтому предварительно перед реализацией алгоритма для каждого используемого разрешения экрана
подсчитано количество символов, которые видны в адресной
строке. Рекомендуется составлять список «допустимых значений»,
состоящий из имён компьютеров, разрешения экрана, которое
на них настроено, в целях определения допустимого значения символов.
Описание работы алгоритма:
1. На вход подаётся URL, hostname.
2. Для каждой записи в списке допустимых значений
на шаг 2.1, при завершении записей в списке прекратить обработку,
на шаг 8:
2.1. Сравниваем hostname с текущей записью из списка допу-
стимых значений;
2.2. Если hostname найден – на шаг 2.3, иначе – на шаг 2.4;
2.3. Получение допустимого значения, прекратить обработку,
на шаг 4;
2.4. Переход к следующей записи из списка допустимых зна-
чений, на шаг 2.
3. Считаем количество символов в URL.
4. Сравниваем длину URL с допустимым значением.
5. Если длина URL меньше допустимого значения,
то – на шаг 6, иначе – на шаг 7.
6. Вернуть 0.
7. Вернуть 1.
8. Выход.
В результате выполнения алгоритма, если длина URL меньше
допустимого значения, алгоритм возвращает 1, что говорит
о том, что исследуемый ресурс – легитимный, в противном случае
ресурс – подозрительный и возвращается 0.
Алгоритм подсчёта точек в URL. Наличие специальных
символов в URL является следующим индикатором опасности
73
URL. В данном случае речь идёт о точках в доменном имени URL.
Алгоритм (рис. 2.15) подсчитывает количество точек в доменном
имени URL, затем сравнивает полученное значение с допустимым
значением. Нужно отметить, что существует зависимость между
количеством точек в фишинговом домене и доменом верхнего
уровня, но только при условии, что домен верхнего уровня национальный.
Описание работы алгоритма:
1. На вход подаётся URL.
2. Регулярными выражениями URL разбирается на сегменты,
такие как протокол, доменное имя, порт, дополнительно извлекается домен верхнего уровня из доменного имени.
3. Для каждой записи в списке допустимых значений
на шаг 3.1, при завершении записей в списке прекратить обработку,
на шаг 5:
3.1. Сравниваем домен верхнего уровня, извлечённый из ис-
следуемого URL, с записью из списка исключений;
3.2. Если домен совпадает – на шаг 3.3, иначе – на шаг 3.4;
3.3. Допустимое значение извлекается из списка исключений,
прекратить обработку – на шаг 5;
3.4. Использовать допустимое значение «по умолчанию»,
равное пяти.
4. Алгоритмом поиска подстроки в строке ищем точки
в доменном имени и считаем их количество.
5. Если количество точек в домене исследуемого URL меньше
или равно пороговому значению – на шаг 7, иначе – на шаг 6.
6. Вернуть 0.
7. Вернуть 1.
8. Выход.
В результате выполнения алгоритма, если количество точек
в доменном имени URL меньше или равно допустимого значения,
алгоритм возвращает 1, что говорит о том, что исследуемый
ресурс – легитимный, в противном случае ресурс – подозрительный
и возвращается 0.
74
Вход
URL
Вернуть
результат 0
Выход
Вернуть
результат 1
Поиск и подсчет
количества точек в
домене URL
Количество точек >
допустимого
значения?
Нет
Да
Обработка URL
Для записи 1..N
исключений
Сравниваем домен
верхнего уровня с
записью из списка
Домен
совпадает?
Нет
Да
Используем допустимое
значение и з списка
исключений
Используем допустимое
значение «по
умолчанию»
Рис. 2.15. Алгоритм подсчёта точек в URL
75
Алгоритм поиска специального символа «@» в URL. Одной
из возможных реализаций фишингового URL является наличие
символа «@» в нём. В строке вида https://root:password@domain.
com: где, https – это протокол; «root» – логин, «password» – пароль,
«domain.com» – доменное имя ресурса. На легитимных ресурсах
сегодня данный синтаксис практически не встречается. Но злоумышленники могут использовать этот механизм для создания
URL, который будет перенаправлять пользователей на фишинговый ресурс. С целью поиска символа «@» в URL предлагается
использовать данный алгоритм (рис. 2.16). В случае нахождения
одного символа «@» алгоритм отбрасывает чувствительную
информацию (логин и пароль) пользователя из URL вместе
с символом «@», чтобы вернуть URL без чувствительной информации. Например, для https://root:password@domain.com результат
извлечения будет таким: https://domain.com. В дальнейшем,
в случае если URL признан легитимным, именно извлечённая часть
будет разрешённым URL.
Описание работы алгоритма:
1. На вход подаётся URL.
2. Поиск вхождений символа «@» в URL.
3. Если счётчик вхождений больше нуля – на шаг 4, иначе –
на шаг 7.
4. Если счётчик вхождений больше единицы – на шаг 8,
иначе – на шаг 5.
5. Отбрасываем левую часть URL, всё что после протокола,
до символа «@», включая сам символ.
6. Вернуть 0 и легитимный URL.
7. Вернуть 1.
8. Вернуть 0.
В результате выполнения алгоритма URL считается фишинговым: если в URL обнаружен символ «@» более 1 раза, алгоритм
возвращает 0 или если в URL обнаружен символ «@» только 1 раз,
алгоритм возвращает 0, но при этом извлекает чувствительную
информацию пользователя ПАСУ и возвращает URL. В противном
случае алгоритм возвращает 1, что говорит о том, что исследуемый
ресурс – легитимный.
76
Вход
URL
Вернуть
результат 0
Выход
Вернуть
результат 1
Подсчет вхождений @ в
URL
Счетчик
вхождений>0?
Нет
Счетчик
вхождений>1?
Да
Отбрасываем
левую часть
URL
Нет
Да
Вернуть
результат 0,
URL
Рис. 2.16. Алгоритм поиска специального символа «@» в URL
77
Алгоритм поиска специальных символов «Слеши, протокол и порт» в URL. Как было описано ранее, наличие специаль-
ных символов может быть индикатором опасности URL. Например,
для URL-адреса: https://click.sender.yandex.ru/l/7885/8297/2/L/
RERVRklFREU4TnhjckdnWmNKaEExTTE0aEFrWTRLelFQSGtzYl
NVWnpXMXg0UWdjSlJnPT06MzUxNjow/*https://phi.ru/app/?from=e
mail_pushapp фишинговой частью является https://phi.ru/app/?
from=email_pushapp, где есть и второй протокол, и двойные слеши.
URL, в которых использованы более двух слешей после протокольной части, более одной протокольной части в URL-адресе
и более одного порта, можно определить как фишинговые.
Алгоритм (рис. 2.17), предлагается использовать с целью поиска
вышеописанных сочетаний специальных символов. В алгоритме
использован термин «остальная часть», это часть URL, которая
идёт после домена верхнего уровня. Например, для URL
https://phi.ru/app/?from=email_pushapp остальной частью будет
«/app/?from=email_pushapp».
Описание работы алгоритма:
1. На вход подаётся URL.
2. Регулярными выражениями URL разбирается на сегменты,
такие как протокол, доменное имя, порт и остальная часть. Анализируется остальная часть на наличие сочетаний специальных символов.
3. Если в остальной части обнаружено более одного подряд
слеша – переход на шаг 7, иначе – на шаг 5.
4. Если в остальной части обнаружен протокол (http, https, ftp) –
переход на шаг 7, иначе – на шаг 6.
5. Если в остальной части обнаружен порт вида
«: port_number» – переход на шаг 7, иначе – на шаг 8.
6. Вернуть 0.
7. Вернуть 1.
В результате выполнения алгоритма, если сочетание специальных символов не обнаружено, алгоритм возвращает 1, что говорит о том, что исследуемый ресурс – легитимный, в противном
случае, если хотя бы одно из сочетаний обнаружено, ресурс – подозрительный, и возвращается 0.
78
Вход
URL
Вернуть
результат 0
Выход
Вернуть
результат 1
Обработка
остальной
части URL
Найдено более 1
слеша?
Нет
Да
Разбор URL на
сегменты
Найдена
протокольная
часть?
Найден порт?
Да
Да
Нет
Нет
Рис. 2.17. Алгоритм поиска специальных символов в URL
79
Алгоритм оценки доступности URL. Подразделение Web
Accessibility Initiative (WAI) группы World Wide Web Consortsium
(W3C) уже с 1999 года разрабатывает стандарты доступности
WEB-контента, которые называются Web Content Accessibility
Guidelines (WCAG). Основная цель стандартов – обеспечить
доступность содержимого сети Интернет для всех категорий
интернет-пользователей. Выпущено три релиза данных стандартов:
WCAG 1.0 была выпущена 05.05.1995; WCGA 2.0 была выпущена
11.12.2008; WCGA 2.1 был выпущен 05.06.2018. На основе WCAGстандартов разработано множество инструментов и в том числе
онлайн-сервисов оценки доступности URL. Подобные инструменты,
получая на вход URL, проверяют его по внутренним метрикам
на наличие различных ошибок в содержимом кода WEB-страницы.
В результате проверки формируется отчёт, который содержит в себе
количество ошибок по типам: критичные, средней важности, низкой
важности. Такие инструменты использованы в алгоритме (рис. 2.18),
который предлагается использовать в целях получения количества
ошибок, найденных на ресурсе, и дальнейшей их обработки.
Алгоритм состоит из четырёх основных этапов. Первый
этап – проверка URL с помощью онлайн-сервисов и получения количества ошибок, обнаруженных на них. Второй этап – поиск ключевых слов на странице, отправка их в поисковую систему google,
получение ответа от поисковой системы. Третий этап – обработка
ответа от поисковой системы, поиск URL, похожего на исследуемый, и поиск ошибок на обнаруженном URL. Четвёртый этап –
подсчёт оценки доступности исследуемого и обнаруженного URL
и сравнение её с допустимым значением. Здесь за оценку доступности (2.3) выбрано стандартное отклонение количества ошибок
каждого типа и получение среднего показателя среди них.
,
)()(
1
2
,
2
,
N
XXXX
AAC
N
i
avifindavimain
(2.3)
где
imainX,
– количество ошибок N-типа исследуемого URL;
ifindX,
– количество ошибок N-типа обнаруженного URL;
av
X
–
среднее значение всех ошибок; N – количество типов ошибок.
80
Вход
URL
Вернуть
результат 0
Выход
Вернуть
результат 1
Оценка доступности<
допустим ого
значения?
Отправка исследуемого и
обнаруженного URL в
сервис оценки
Нет
Обработка ответа от
сервиса и фиксация
ошибок
Загрузка DOM URL
Отправка ключевых слов в
поисковую систему
Обработка ответа, поиск
схожего URL
Для узла 1..N в
DOM URL
Тэг найден?
Извлекаем текст
Добавляем текст к
основному документу
Нет
Да
Ищем ключевые слова
Основной
документ
сформирован?
Да
Нет
Оценка доступности
исследуемого >
обнаруженного?
Подсчет оценок
доступности
Нет
Да
Да
Рис. 2.18. Алгоритм оценки доступности URL
Описание работы алгоритма:
1. На вход подаётся URL.
2. Загрузка DOM-страницы по исследуемому URL.