Table Of ContentМИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РФ
ФГБОУ ВО
«ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ»
А. В. СКРЫПНИКОВ, Д. В. АРАПОВ,
В. В. ДЕНИСЕНКО, Т. Д. ГЕРАСИМОВА
ЗАЩИТА WEB-ПРИЛОЖЕНИЙ
УЧЕБНОЕ ПОСОБИЕ
ВОРОНЕЖ
2020
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РФ
ФГБОУ ВО
«ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ
УНИВЕРСИТЕТ ИНЖЕНЕРНЫХ ТЕХНОЛОГИЙ»
А. В. СКРЫПНИКОВ, Д. В. АРАПОВ,
В. В. ДЕНИСЕНКО, Т. Д. ГЕРАСИМОВА
ЗАЩИТА WEB-ПРИЛОЖЕНИЙ
Утверждено
редакционно-издательским советом университета
в качестве учебного пособия
ВОРОНЕЖ
2020
УДК 004.056.53
ББК З973.2-018я7
З-40
Научный редактор профессор И. А. ХАУСТОВ
Р е ц е н з е н т ы:
кафедра вычислительной техники и информационных систем
Воронежского государственного лесотехнического университета
им. Г. Ф. Морозова;
д-р техн. наук А. Д. ДАНИЛОВ
(Воронежский государственный технический университет)
Печатается по решению
редакционно-издательского совета
Воронежского государственного университета инженерных технологий
Защита Web-приложений [Текст] : учеб. пособие /А. В.
З-40 Скрыпников, Д. В. Арапов, В. В. Денисенко, Т. Д. Герасимова;
Воронеж. гос. ун-т инж. технол. - Воронеж: ВГУИТ, 2020. – 75 с.
ISBN 978-5-00032-469-1
Учебное пособие разработано в соответствии с требованиями ФГОС ВО подготовки
выпускников по специальности 10.05.03 - «Информационная безопасность
автоматизированных систем», направлениям 09.03.03 - «Прикладная информатика» и
09.03.02 - «Информационные системы и технологии». Оно предназначено для закрепления
теоретических знаний дисциплин цикла Б1. В пособии приведены теоретические сведения
по информационной безопасности Wеb-приложений и примеры кода на языках HTML, CSS
и JavaScript.
1602090000-15 УДК 004.056.53
З Без объявл. ББК З973.2-018я7
ОК2(03) – 2020
ISBN 978-5-00032-469-1
© Скрыпников А. В., Арапов Д. В,
Денисенко В. В., Герасимова Т. Д.,
2020
© ФГБОУ ВО «Воронеж. гос. ун-т
инж. технол.», 2020
Оригинал-макет данного издания является собственностью Воронежского
государственного университета инженерных технологий, его репродуцирование
(воспроизведение) любым способом без согласия университета запрещается.
1. ОБЩИЕ ПОЛОЖЕНИЯ ОБЕСПЕЧЕНИЯ
БЕЗОПАСНОСТИ
Без хорошего плана обеспечения безопасности хакеры с
легкостью получат доступ к приложению и создадут для вас
всевозможные проблемы. На данном этапе необходимо
понять, что данные вашего приложения или пользователей,
работающих с ним, - это самый важный ресурс, который
необходимо защищать. Поэтому в центре внимания
безопасности не хакеры, приложения, сети или что-то еще, но
в центре внимания – данные. Ваше приложение будет
обмениваться данными с различными онлайн-источниками и
будет использовать сторонние программные решения, что
может как положительно, так и отрицательно сказаться на
безопасности.
Для начала необходимо решить, как ваше приложение
взаимодействует с данными. Оно может выполнять только
четыре операции с данными, независимо от того, насколько
невероятно сложным может стать приложение. Вы можете
определить эти операции с помощью аббревиатуры CRUD:
·Create – Создать;
·Read – Читать;
·Update – Обновить;
·Delete – Удалить.
Взаимодействие с данными напрямую зависит от среды
приложения. Обеспечение безопасности ваших данных
означает понимание среды приложения и, следовательно,
угроз для данных, которыми управляет приложение.
Целью программного обеспечения является
взаимодействие с данными. Тем не менее, само программное
обеспечение является своего рода тоже данными.
Фактически, данные поступают во многих формах и их
влияние гораздо шире, чем вы обычно думаете. Благодаря
«Интернету вещей», данные теперь могут иметь как
абстрактные, так и физические эффекты, которые никто не
мог представить даже несколько лет назад. Хакер, получив
доступ к нужному приложению, может, например, повредить
3
электрическую сеть или отравить водную систему. В другом
случае хакер может поднять температуру вашего дома до
какого-то ужасающего уровня, выключить все огни или
шпионить за вами через web-камеру, это лишь несколько
примеров.
Сейчас многие используют такое понятие как Software
Security Assurance (SSA) (обеспечение безопасности
программного обеспечения). Суть SSA заключается в том, что
программное обеспечение нуждается в каком-либо типе
регулирования, чтобы гарантировать, что оно не приведет к
потере, неточности, изменению, недоступности или
неправильному использованию данных и ресурсов, которые
оно использует, контролирует и защищает. Это требование
появляется как часть SSA. В настоящее время SSA не
является стандартом. Это концепция, которую многие
организации начинают документировать для своих
приложений. Вы можете увидеть, как SSA влияет на многие
организации, такие как Oracle и Microsoft, просмотрев их
онлайн-документацию по SSA. Фактически, многие крупные
организации в настоящее время имеют определенную форму
SSA для своих программных продуктов. Более подробно мы
рассмотрим обеспечение безопасности приложений далее, для
начала нам необходимо рассмотреть основные угрозы.
1.1. Определение угроз Web-приложений
Списки угроз для Web-приложений можно найти на
просторах интернета, но только вы должны решить какие
именно для вас являются главными, а какие
второстепенными, и в зависимости от этого разрабатывать
план безопасности. Вам нужно получить представление о
том, что нужно проверить, и представленный далее список
будет хорошей отправной точкой. Тем не менее, вы всегда
должны рассматривать актуальные данные по угрозам для
вашего приложения. Кроме того, не полагайтесь только на
один список - используйте несколько списков, чтобы лучше
охватить угрозы, которые могут угрожать вашему
4
приложению. Учитывая это, вот список наиболее
распространенных угроз, с которыми вы можете столкнуться
при Web-разработке.
Переполнение буфера (Buffer overflow):
злоумышленнику удается отправить достаточно данных во
входной или выходной буфер, чтобы его переполнить. В
результате данные, не попавшие в буфер, теряются.
Некоторые формы переполнения буфера позволяют
злоумышленнику выполнять, казалось бы, невозможные
задачи, потому что в буферной памяти может содержаться
исполняемый код. Лучший способ преодолеть эту проблему –
выполнить проверку диапазона и размера любых данных,
входных или выходных, которые обрабатывает ваше
приложение.
Внедрение кода (Code injection): злоумышленник
добавляет код в поток данных, проходящий между сервером и
клиентом (например, браузером) способом атаки «человек
посередине». Цель атаки часто рассматривает добавленный
код как часть исходной страницы, но она может содержать
что угодно. Введенный код может скрываться в фоновом
режиме, готовый вызвать всевозможные проблемы для
вашего приложения. Хороший способ преодолеть эту атаку -
убедиться, что вы используете зашифрованные потоки
данных, протокол HTTPS и проверку кода (когда это
возможно). Также можно воспользоваться обеспечением
механизма обратной связи с клиентом. Внедрение кода
происходит чаще, чем вы думаете, даже ваш провайдер может
внедрить JavaScript-код для отображения рекламы у вас в
браузере.
Межсайтовый скриптинг (XSS- Cross-site scripting):
злоумышленник внедряет JavaScript или другой исполняемый
код в поток вывода вашего приложения. Получатель видит
ваше приложение как источник заражения. В большинстве
случаев вам бы не хотелось, чтобы пользователи могли
отправлять данные напрямую друг другу через ваше
приложение без строгой проверки. Модерируемый формат
для приложений, таких как блоги, является обязательным
5
условием, чтобы гарантировать, что ваше приложение не
будет пересылать вирусы или что-то еще хуже вместе с,
казалось бы, полезными данными.
Загрузка файлов (File uploads): каждая загрузка файла,
даже та, которая кажется безобидной, должна
восприниматься с подозрением. Хакеры иногда загружают
бэкдоры (backdoor— дефект алгоритма, который намеренно
встраивается в него и позволяет получить
несанкционированный доступ к данным или удалённому
управлению приложением, операционной системой и
компьютером в целом), используя возможности загрузки
файлов вашего сервера, поэтому файл может содержать
вирус. Если возможно, запретите загрузку файлов на ваш
сервер. Конечно, не всегда возможно обеспечить такой
уровень безопасности, поэтому вам нужно разрешить только
определенные типы файлов, а затем сканировать файл на
наличие проблем. Аутентификация файла в максимально
возможной степени всегда хорошая идея. Например,
некоторые файлы, в начале содержат подпись, которую вы
можете использовать для проверки подлинности файла.
Не полагайтесь только на исключение расширений файлов -
хакеры часто делают один файл похожим на другой тип,
чтобы обойти защиту сервера.
Жестко закодированная аутентификация (Hardcoded
authentication): разработчики часто помещают информацию
аутентификации в файлы инициализации приложения в целях
тестирования. Важно удалить эти жестко
запрограммированные записи аутентификации и вместо этого
полагаться на централизованное хранилище данных для
получения информации о безопасности. Нахождение
хранилища данных в безопасном месте вне сервера,
используемого для Web-приложений, необходимо для того,
чтобы хакеры не могли легко получить доступ к учетным
данным, используемым для доступа к приложению. Если вам
нужны файлы инициализации для приложения, убедитесь, что
эти файлы находятся за пределами каталога webroot
6
(корневой каталог Web-приложения по умолчанию), чтобы
хакеры не могли обнаружить их случайно.
Скрытое или ограниченное обнаружение файлов /
каталогов (Hidden or restricted file/directory discovery): когда
ваше приложение позволяет вводить специальные символы,
такие как косая черта (/) или обратная косая черта (\), хакер
может обнаружить скрытые или запрещенные файлы и
каталоги. Они могут содержать всю информацию,
необходимую хакеру для атаки на вашу систему. Запрещайте
использование специальных символов всегда, когда это
возможно. Кроме того, храните важные файлы вне каталога
webroot в местах, которые операционная система может
напрямую контролировать.
Отсутствующая или неверная аутентификация
(Missing or incorrect authentication): важно знать, с кем вы
имеете дело, особенно при работе с конфиденциальными
данными. Многие Web-приложения используют общие
учетные записи для выполнения некоторых задач, при этом
невозможно узнать, кто получил доступ к учетной записи.
Избегайте использования гостевых учетных записей для
любых целей и назначьте каждому пользователю
определенную учетную запись.
Отсутствующая или неверная авторизация (Missing or
incorrect authorization): даже если вы знаете человека, с
которым имеете дело, важно предоставлять только
необходимый для выполнения определенной задачи уровень
авторизации. Кроме того, авторизация должна отражать
метод доступа пользователя. Настольная система для доступа
к приложению из локальной сети, вероятно, более безопасна,
чем смартфон, получающий доступ к приложению из местной
кофейни. Все, что вы можете сделать, чтобы уменьшить
количество действий, разрешенных пользователю, помогает
поддерживать безопасность.
Отсутствующее или неверное шифрование (Missing or
incorrect encryption): используйте шифрование для передачи
данных любого рода между двумя конечными точками, чтобы
не дать хакерам перехватить ваши данные. Важно следить за
7
новейшими методами шифрования и полагаться на лучшие из
них, которые поддерживаются на стороне пользователя.
Например, стандарт тройного шифрования данных (3DES)
больше не защищен, однако некоторые организации
продолжают его использовать.
Внедрение команд операционной системы (Operating
system command injection): злоумышленник изменяет команду
операционной системы, которую ваше приложение
использует для выполнения определенных задач. Скорее
всего, ваше Web-приложение не должно использовать вызовы
операционной системы. Однако если вам абсолютно
необходимо выполнять вызовы операционной системы,
убедитесь, что приложение работает в песочнице (sandbox —
специально выделенная среда для безопасного исполнения
компьютерных программ).
Управление параметрами (Parameter manipulation):
хакеры могут экспериментировать с параметрами,
переданными как часть заголовка запроса или URL.
Например, при работе с Google, вы можете изменить URL-
адрес и результаты поиска. Убедитесь, что вы шифруете
любые параметры, которые вы передаете между браузером и
сервером. Кроме того, при передаче параметров используйте
безопасные протоколы Web-страниц, такие как HTTPS. Также
важно тщательно определить диапазоны значений параметров
и типы данных, чтобы уменьшить потенциальные проблемы,
связанные с этой атакой.
Дистанционное присоединение кода (Remote code
inclusion): большинство Web-приложений сегодня полагаются
на включенные библиотеки, фреймворки и API. Во многих
случаях оператор include содержит относительный путь или
использует переменную, содержащую жестко заданный путь,
чтобы впоследствии было проще изменить местоположение
удаленного кода. Когда хакер может получить доступ к
информации о пути и изменить ее, у него появляется
возможность указать удаленное включение любого кода. Тем
самым вы предоставите хакеру полный доступ к приложению.
Лучший способ избежать этой проблемы – использовать,
8
когда это возможно, жестко закодированные полные пути,
хотя это и усложнит дальнейшую поддержку кода
приложения.
Угон сессии (Session hijacking): при входе на Web-
сервер, он создает пользователю уникальный сеанс. Угонщик
сеанса подключается к сеансу и перехватывает данные,
передаваемые между пользователем и сервером. Три самых
распространенных места, где хакеры ищут информацию о
сессиях, используемую для захвата сеанса: cookies,
перезапись URL и скрытые поля. Сохраняя зашифрованную
информацию о сеансе, вы можете снизить риск ее перехвата.
Например, убедитесь, что вы используете протокол HTTPS
для входа в систему. Вы также должны избегать таких вещей,
как предсказуемые идентификаторы сеансов.
SQL инъекция (SQL injection): злоумышленник изменяет
запрос, который ваше приложение создает в результате
пользовательского или другого ввода. Во многих случаях
приложение запрашивает входные данные запроса, но вместо
этого получает элементы SQL. Другие формы атаки SQL
инъекций включают использование «escape» или других
неожиданных символов или последовательностей символов.
Хороший способ избежать атак с использованием SQL
инъекций - избегать динамически генерируемых запросов.
На первый взгляд может показаться, что мы
рассмотрели множество различных угроз, но если вы
продолжите искать в Интернете, вы можете легко утроить
размер этого списка даже не начав разбираться с тем, как
хакер может навредить вашему приложению. Но, не
беспокойтесь, в большинстве случаев исправления
заканчиваются здравым смыслом, и одно исправление может
решить более одной проблемы. Например, просмотрите
список еще раз, и вы обнаружите, что простое использование
HTTPS решает ряд этих проблем.
9
