угроза внедрения кода или данных меры защиты
Практика. Создание системы защиты персональных данных
Вне зависимости от того, принадлежит ли компания к большому, малому или среднему бизнесу, состоявшаяся это организация или пока еще стартап — вопрос защиты персональных данных актуален для всех. Эта статья посвящена особенностям и средствам такой защиты, а также рекомендациям, которые помогут упростить эту работу и сделать ее более эффективной.
Кто обеспечивает защиту данных?
Сфера защиты данных юридически регулируется информационным правом (одной из подотраслей административного права), нормы которого прописаны в нескольких законодательных актах. Один из основных — Федеральный закон № от 27.07.2006 «О персональных данных», цель которого заявлена как «общее обеспечение защиты конституционных прав и свобод человека и гражданина при обработке персональных данных», таких как право на неприкосновенность частной жизни, личную и семейную тайну.
Реализация мер по защите персональных данных — это зона ответственности оператора, т. е. субъекта, осуществляющего сбор и обработку данных в информационной системе. Как правило, таким субъектом выступает компания, владеющая базами данных своих сотрудников и клиентов либо сторонняя организация, уполномоченная компанией-владельцем.
При невыполнении мер защиты оператор несет законодательно установленную ответственность. Наблюдением и проверками компаний в данном случае занимается Роскомнадзор. В случае если требования законодательства нарушены, оператор несет административную ответственность и обязан заплатить штраф. С 2019 года его размер повысился до сотен тысяч (для юридических лиц — миллионов) рублей — в соответствии с недавними поправками, внесенными в Кодекс РФ об административных правонарушениях.
Общая сумма штрафов, выписанных по итогам проверок, составила более пяти миллионов за предыдущий год.
Что защищать и от чего?
Начнем с вопроса терминологии. Персональные данные представляют собой любую информацию, относящуюся прямо или косвенно к физическому лицу, который в законе прописан как субъект персональных данных. Наиболее распространенные разновидности такой информации:
точное место жительства;
адрес электронной почты.
Фамилия, имя и отчество сами по себе тоже могут являться персональными данными. Попадание этой информации к любым третьим лицам должно быть исключено.
Кроме того, необходимо понимать, что оператор имеет право на обработку данных лишь в некоторых случаях:
если им получено согласие на обработку (необязательно письменное);
планируется заключение договора с субъектом (даже в случае оферты на веб-сайте);
обрабатываются персональные данные своих сотрудников;
в особых случаях, когда обработка нужна для защиты жизни, здоровья и прочих важных интересов человека.
Если компания-оператор не смогла доказать ни одно из перечисленных оснований обработки, на нее также налагается штраф и сбор данных считается незаконным.
Самый важный пункт здесь — само согласие на обработку. Простейший способ, которым пользуются большинство компаний — реализованная тем или иным образом форма быстрого выражения согласия. Обычно это знакомая многим «галочка» под сопровождающим ее текстом о собственно согласии.
Еще один параметр, который нужно учитывать — не стоит обрабатывать персональную информацию, не имеющую непосредственного отношения к предмету договора (скажем, для классического договора купли-продажи не имеют значения профессия, уровень образования или воинская обязанность покупателя). Излишний интерес может быть истолкован надзорными органами как нарушение.
Поскольку время от времени Роскомнадзор проводит внеплановые проверки (чаще всего, если есть жалобы конкретного лица — бывшего сотрудника, конкурирующей компании или клиента, считающего, что его права нарушены), во избежание претензий компании-оператору нужно удостовериться, что:
Политика в отношении персональных данных задокументирована и находится в публичном доступе.
Форма сбора персональных содержит разъясняющую информацию о том для чего они собираются (когда ввод персональных данных необходим для заключения договора, его текст также обязательно должен быть опубликован).
Уже собранные специальные данные человека, включая биометрические (те сведения, которые характеризуют физиологические и биологические особенности человека, на основании которых может быть установлена его личность) не могут быть переданы заграничным компаниям.
Запросы и требования субъектов персональных данных (в том числе об уточнении, удалении, блокировании) всегда удовлетворяются.
Чаще всего проверки Роскомнадзора выявляет нарушения из этого списка. Другая распространенная претензия — недостаточный внутренний контроль за осуществлением обработки и слабая осведомленность сотрудников, которые за нее отвечают о правилах и требованиях ее проведения.
Когда обработка происходит с использованием информационных систем (а значит, и электронных устройств), появляются новые потенциальные угрозы, которые нужно свести к минимуму, а лучше и вовсе исключить. Рассмотрим их.
Угрозой информации считают возможное влияние или воздействие на автоматизированную систему обработки изнутри или извне, которое влечет за собой любые негативные последствия для субъектов этой информации. Обычно информационные системы становятся особо уязвимыми, когда:
программное обеспечение компании несовершенно, давно не обновлялось и содержит уязвимости;
некоторые процессы системы (в частности, защитные) функционируют не в полную силу;
усложнены условия эксплуатации и хранения информации.
Угрозы принято делить на несколько групп (в основе классификации лежит природа угрозы):
Объективная. Она напрямую зависит от того, насколько грамотно подобрано оборудование для хранения и обработки, работает ли должным образом защитное ПО.
неисправность технических средств,
слабые антивирусы, отсутствие шлюзов безопасности,
невозможность зрительного контроля за серверами и доступом к ним.
Предусмотреть все возможные сбои и неполадки невозможно, но важно знать где и почему они могут потенциально произойти — и подстраховаться.
Случайная. Эта группа включает в себя непредвиденные обстоятельства, различные ЧП и системные сбои. В данном случае важно быть готовыми оперативно их устранить (любые неисправности технических средств на всевозможных уровнях системы, в том числе тех, которые отвечают за контроль доступа, устаревание и износ отдельных микросхем, носителей данных, линейных соединений, неисправность в работе антивирусных, сервисных и прикладных программ).
Субъективная. Как правило, под такими угрозами понимают неправильные действия сотрудников, осуществляющих техническую обработку, хранение и защиту информации. Они могут ошибаться в соблюдении правил безопасности и допускать утечки при загрузке программного обеспечения или в момент активного использования системы, при различных манипуляциях с базами данных, при включении и выключении аппаратуры. Также к этой группе относятся неправомерные действия бывших сотрудников, у которых остался несанкционированный доступ к данным.
Специалисты компании-оператора должны учитывать все типы угроз. Во внимание следует принять критерии, которые помогут понять, какова реальная возможность угрозы того или иного типа (а также вероятность поломки или успешного обхода защитных алгоритмов):
Доступность. Этот критерий демонстрирует, насколько просто злоумышленник может получить доступ к нужной ему информации или к инфраструктуре организации, где хранятся эти данные.
Фатальность. Эта характеристика предполагает оценку степени глубины влияния угрозы на общее функционирование системы и способность специального персонала компании справиться с последствиями от влияния этого фактора.
Количество. Это параметр, подразумевающий собой определение количества потенциально уязвимых деталей системы хранения и обработки данных.
Точный расчет вероятности воздействия той или иной угрозы производится математически — это могут сделать аналитические эксперты компании. Такой самоанализ позволяет объективно оценить риски и предпринять дополнительные меры защиты: закупить более совершенное оборудование, провести дополнительное обучение работников, перераспределить права доступа и т. д.
Существует несколько других, более подробных классификаций внутренних и внешних угроз, которые будут полезны для систематизации всех факторов. Рассмотрим и их.
угроза, вызванная небрежностью сотрудников, работающих с информационной системой;
угроза, инициируемая субъектами извне с целью получения личной выгоды.
искусственная угроза, созданная при участии человека;
природная, неподконтрольная человеку (чаще всего — стихийные бедствия).
Непосредственная причина угрозы:
человек, разглашающий строго конфиденциальные сведения;
природный фактор (вне зависимости от масштаба);
специализированное вредоносное программное обеспечение, нарушающее работу системы;
удаление данных случайным путем из-за отказа техники.
Момент воздействия угрозы на информационные ресурсы:
в момент обработки информации (обычно это происходит из-за рассылок вирусных утилит);
при получении системой новой информации;
независимо от степени активности работы системы (например, при направленном взломе шифров или криптозащиты).
Существуют и другие классификации, учитывающие среди параметров возможность доступа работников к самой системе или ее элементам, способ доступа к основным частям системы и конкретные способы размещения информации.
Значительную часть всех угроз эксперты связывают с объективными внешними факторами и информационным вторжением со стороны конкурентов, злоумышленников и бывших сотрудников. Особую опасность представляют те из них, кто знаком с правилами функционирования конкретной системы, обладает знаниями на уровне разработчика программ и имеет сведения о том или ином уязвимом месте в системе.
Построение системы защиты персональных данных
Классификация уровней защиты
Информационная безопасность подразумевает четыре уровня защиты от угроз:
Первый уровень. Наиболее высокий, предполагает полную защиту специальных персональных данных (национальная и расовая принадлежность, отношение к религии, состояние здоровья и личная жизнь).
Второй уровень. Предполагает защиту биометрических данных (в том числе фотографии, отпечатки пальцев).
Третий уровень. Представляет собой защиту общедоступных данных, то есть тех, к которым полный и неограниченный доступ предоставлен самим человеком.
Четвертый уровень. Это сборная группа, в которую включают все данные, не упомянутые в предыдущих трех пунктах.
Таким образом, все данные, собранные в информационной базе компании, могут быть четко распределены по уровням защиты.
Обеспечение защиты
Защита информации по уровням в каждом случае состоит из цепочки мер.
Четвертый уровень. Означает исключение из помещения, где находится информационное оборудование, посторонних лиц, обеспечение сохранности носителей данных, утверждение четкого списка работников, которые имеют допуск к обработке данных, а также использование специальных средств защиты информации.
Третий уровень. Подразумевает выполнение всех требований, предусмотренных для предыдущего уровня, и назначение ответственного за информационную безопасность должностного лица.
Второй уровень. Помимо выполнения требований предыдущего уровня, включает в себя ограничение доступа к электронному журналу безопасности.
Первый уровень. Кроме всех требований, которым необходимо следовать на втором уровне, включает обеспечение автоматической регистрации в электронном журнале безопасности полномочий сотрудников, имеющих доступ к данным, в случае изменения этих полномочий, а также возложение ответственности за информационную безопасность на специально созданное подразделение.
Должное выполнение прописанных в законодательстве мер защиты персональных данных в соответствии с уровнями обеспечивает максимальную эффективность общей стратегии защиты информации, принятой в компании-операторе.
Средства защиты информации
Подробный список технических и организационных мер по обеспечению безопасности также определен юридически. К ним относятся процедура идентификации и аутентификации субъектов и объектов доступа, цепочка управления доступом, ограничение программной среды, надежная защита машинных носителей информации, антивирусная защита, предотвращение и обнаружение вторжений, аналитика степени защищенности среды наряду с обеспечением доступности данных и выявлением событий, которые потенциально приведут к сбоям в работе системы. Кроме того, закон обязывает в случае технической невозможности реализации каких-либо мер разрабатывать другие, компенсирующие меры по нейтрализации угроз.
Технические средства защиты также имеют отдельную классификацию и должны выбираться в зависимости от требуемого уровня защиты. Средства определены официальным документом, составленным Федеральной службой по техническому и экспортному контролю (орган исполнительной власти, занимающийся защитой информации). Документ доступен на официальном ресурсе службы. Каждый из классов имеет минимальный набор требований по защите.
Криптографические средства защиты информации
Одним из наиболее действенных способов защиты персональных данных является использование средств криптографии. Если упростить, то речь идет о шифровании текста с помощью цифрового кода.
К криптографическим средствам относятся аппаратные, программные и комбинированные устройства и комплексы, способные реализовывать алгоритмы криптографического преобразования информации.
Они предназначены одновременно для защиты информации при передаче по каналам связи и защиты ее от неразрешенного доступа при обработке и хранении. Логика проста: злоумышленник, который не знает кода, не сможет воспользоваться данными, даже если получит к ним доступ, поскольку не прочтет их. Для него они остануться бессмысленным набором как будто случайных цифр.
Регламент использования криптографических средств определяется Федеральной службой безопасности и документирован в соответствующем приказе.
Рекомендации по защите персональных данных
Как видим, поддержание системы информационной безопасности силами отдельной компании представляется довольно трудоемкой задачей. Далеко не каждый бизнес или государственная компания могут позволить себе штат профильных специалистов. Во многих случаях проще отдать эту задачу на аутсорс, нанять сторонних специалистов, которые помогут подобрать и установить подходящее оборудование, проконсультирую персонал, окажут поддержку с написанием политики конфиденциальности и внутренних регламентов по обращению с засекреченной информацией.
Такое сотрудничество всегда требует большой вовлеченности со стороны руководящего звена компании и всех ее сотрудников. Невнимательность и недостаточно серьезное отношение к соблюдению мер защиты могут закончиться кражей данных, крупными штрафами, судебными разбирательствами и репутационными потерями.
Регулярно проводите оценку эффективности выбранных мер защиты, оперативно вносите коррективы, следите за изменениями в законодательстве. Предупредить угрозу в разы проще (и дешевле), чем бороться с ее последствиями.
Книга «Безопасность в PHP» (часть 2). Атаки с внедрением кода
В списке десяти наиболее распространённых видов атак по версии OWASP первые два места занимают атаки с внедрением кода и XSS (межсайтовый скриптинг). Они идут рука об руку, потому что XSS, как и ряд других видов нападений, зависит от успешности атак с внедрением. Под этим названием скрывается целый класс атак, в ходе которых в веб-приложение внедряются данные, чтобы заставить его выполнить или интерпретировать вредоносный код так, как это нужно злоумышленнику. К таким атакам относятся, например, XSS, внедрение SQL, внедрение заголовка, внедрение кода и полное раскрытие путей (Full Path Disclosure). И это лишь малая часть.
Атаки с внедрением — страшилка для всех программистов. Они наиболее распространены и успешны за счёт разнообразия, масштабности и (иногда) сложности защиты от них. Всем приложениям нужно брать откуда-то данные. XSS и UI Redress встречаются особенно часто, поэтому я посвятил им отдельные главы и выделил их из общего класса.
OWASP предлагает следующее определение атак с внедрением:
Возможности внедрения — вроде SQL, OS и LDAP — возникают тогда, когда интерпретатор получает ненадёжные данные в виде части командного запроса. Зловредные данные могут обмануть интерпретатор и заставить его выполнить определённые команды или обратиться к неавторизованным данным.
Внедрение SQL
Внедрение SQL — самая распространённая и чрезвычайно опасная форма атак с внедрением. Трудно переоценить серьёзность этой угрозы, поэтому крайне важно понимать, что влияет на успешность атак и как от них защититься.
Итак, данные внедряются в веб-приложение, а затем используются в SQL-запросах. Обычно они попадают из ненадёжных источников ввода, например из веб-форм. Однако внедрение может выполняться и из других мест, скажем, из самой базы данных. Программисты часто верят в полную безопасность своей базы, не осознавая, что если она была безопасна в одном случае, то это совершенно не значит, что она будет безопасна и впредь. Данные из базы должны считаться ненадёжными до тех пор, пока не доказано обратное, т. е. пока они не прошли проверку.
Если атака прошла успешно, злоумышленник может манипулировать SQL-запросом так, чтобы тот выполнял с базой данных операции, которые не предусмотрены разработчиками.
Посмотрите на этот запрос:
Это три упущения очень часто встречаются в веб-приложениях.
Также уделяйте внимание другому фактору внедрения SQL: постоянное хранилище не всегда нужно держать на сервере. HTML 5 поддерживает использование БД на стороне клиента, куда можно отправлять запросы с помощью SQL и JavaScript. Для этого есть два API: WebSQL и IndexedDB. В 2010 году W3C не рекомендовал выбирать WebSQL; он поддерживается WebKit-браузерами, использующими SQLite в качестве бэкенда. Скорее всего, поддержка сохранится ради обратной совместимости, даже несмотря на рекомендацию W3C. Как следует из его названия, этот API принимает SQL-запросы, а значит, может быть мишенью атак с внедрением. IndexedDB — это более новая альтернатива, база данных NoSQL (не требует использования SQL-запросов).
Примеры внедрения SQL
Манипулирование SQL-запросами может преследовать такие цели:
Защита от внедрения SQL
Защита от внедрения SQL базируется на принципе эшелонирования. Перед использованием данных в запросе надо проверять, что их форма корректна. Также необходимо изолировать данные до включения в запрос либо включать в виде параметра перехода.
Проверка
Я не устаю повторять: все данные, которые не были явным образом созданы в исходном PHP-коде текущего запроса, ненадёжны. Строго проверяйте их и отклоняйте всё, что не прошло проверок. Не пытайтесь «исправить» данные, можно внести лишь лёгкие, косметические изменения в формат.
К частым ошибкам относится проверка данных для дальнейшего текущего использования (например, для отображения на экране или вычислений) и отсутствие проверки полей базы данных, в которой в результате будет сохранена информация.
Экранирование
Чтобы ещё больше усложнить вам жизнь, скажу, что вы не имеете права на ошибку при изолировании вводимых в запрос данных. Один промах — и вы уязвимы для атаки.
Подведём итог. Экранирование — не лучший вариант защиты. К нему стоит прибегать в крайнем случае. Оно может понадобиться, если используемая вами для абстракции библиотека БД допускает настройку голых SQL-запросов или частей запроса без принудительной привязки параметров. В остальных случаях лучше вообще избегать изолирования. Этот подход сложен, провоцирует ошибки и различается в зависимости от расширения базы данных.
Параметризованные запросы (заранее подготовленные выражения)
Параметризация, или привязка параметров, — это рекомендованный способ создания SQL-запросов. Все хорошие библиотеки БД применяют его по умолчанию. Вот пример использования расширения PDO для PHP:
В отличие от ручного изолирования, привязка параметров (или иной другой метод, используемый вашей библиотекой БД) позволит корректно изолировать автоматически привязываемые данные, так что вам не придётся вспоминать, какую функцию применять. Также согласованная привязка параметров гораздо надёжнее, чем попытка не забыть, что нужно изолировать всё вручную.
Реализация принципа наименьших привилегий
Прервать успешное внедрение SQL не менее важно, чем его полностью предотвратить. Когда атакующий получает возможность выполнять SQL-запросы, то он будет это делать как конкретный пользователь БД. Благодаря принципу наименьших привилегий можно удостовериться, что все пользователи имеют лишь те привилегии, которые абсолютно необходимы для выполнения их задач.
Если у пользователя широкие привилегии, то атакующий может удалять таблицы и менять привилегии других пользователей, выполняя от их имени новые внедрения SQL. Чтобы этого не произошло, никогда не обращайтесь к БД из веб-приложения от лица root’а, администратора или иного пользователя с высокими привилегиями.
Другое применение принципа — разделение ролей чтения и записи данных в базу. Выберите одного пользователя с правами только на запись, а другого — с правами только на чтение. Если атака будет направлена на «читающего» пользователя, то у злоумышленника не получится манипулировать данными в таблице или записывать их. Можно ограничивать доступ в ещё более узких рамках, тем самым уменьшая последствия успешных атак с внедрением SQL.
Многие веб-приложения, особенно с открытым кодом, разработаны так, что в них используется только один пользователь БД, уровень привилегий которого почти наверняка никогда не проверяется. Так что не забывайте об этом моменте и не пытайтесь запускать приложения под администраторским аккаунтом.
Внедрение кода (известно как удалённое включение файла, Remote File Inclusion)
Внедрение кода — это любые способы, которые позволяют атакующему добавлять в веб-приложение исходный код с возможностью его интерпретировать и исполнять. При этом речь не идёт о внедрении кода в клиентскую часть, например в JavaScript, здесь применяются уже XSS-атаки.
Можно внедрить исходный код напрямую из ненадёжного источника входных данных либо заставить веб-приложение загрузить его из локальной файловой системы или внешнего ресурса вроде URL. Когда код внедряется в результате включения внешнего источника, то это обычно называют удалённым включением файла (RFI), хотя само по себе RFI всегда предназначено для внедрения кода.
Основные причины внедрения кода:
Последнему пункту уделяйте особое внимание: в этом случае ненадёжные пользователи могут загрузить на сервер любые файлы.
Примеры внедрения кода
В PHP множество целей для внедрения кода, так что этот тип атак возглавляет список наблюдения у любого программиста.
Включение файла
Проверка
Функция PHP eval() принимает к исполнению строку PHP-кода.
Внедрение регулярных выражений
Функция PCRE (регулярное выражение, совместимое с Perl) preg_replace() в PHP допускает использование модификатора e (PREG_REPLACE_EVAL). Это означает замещающую строку, которая после подстановки будет считаться PHP-кодом. И если в этой строке имеются ненадёжные входные данные, то они смогут внедрить исполняемый PHP-код.
Дефектная логика включения файла
Веб-приложения по определению включают в себя файлы, необходимые для обслуживания любых запросов. Если воспользоваться дефектами логики маршрутизации, управления зависимостями, автозагрузки и других процессов, то манипуляция с путём прохождения запроса или его параметрами заставит сервер включить конкретные локальные файлы. Поскольку веб-приложение не рассчитано на обработку таких манипуляций, последствия могут быть непредсказуемыми. Например, приложение невольно засветит маршруты, предназначенные только для использования в командной строке. Или раскроет другие классы, конструкторы которых выполняют задачи (лучше классы так не проектировать, но это всё же встречается). Любой из этих сценариев может помешать операциям бэкенда приложения, что позволит манипулировать данными или провести DOS-атаку на ресурсоёмкие операции, которые не подразумевают прямого доступа.
Задачи внедрения кода
Спектр задач чрезвычайно широк, поскольку этот тип атак позволяет выполнять любой PHP-код на выбор атакующего.
Defenses against Code Injection
Command Injection
Examples of Command Injection
Defenses against Command Injection
Внедрение лога (известно как внедрение лог-файла, Log File Injection)
Многие приложения собирают логи, а авторизованные пользователи часто просматривают их через HTML-интерфейс. Поэтому логи — одна из главных целей злоумышленников, желающих замаскировать другие атаки, обмануть тех, кто просматривает логи, и даже провести затем атаку на пользователей мониторингового приложения, с помощью которого читаются и анализируются логи.
Уязвимость логов зависит от механизмов контроля над записью логов, а также от обращения с данными логов как с ненадёжным источником при просмотре и анализе записей.
А что, если атакующий использует в форме имя «AdminnSuccessful login by Adminn»?
Если эта строка будет вставлена в лог из ненадёжных входных данных, то атакующий успешно замаскирует неудачную попытку авторизации с помощью невинной неудачи ввода админского пароля. Подозрительность данных снизится ещё больше, если добавить успешную попытку авторизации.
Здесь вся суть в том, что атакующий способен добавлять в лог всевозможные записи. Также можно внедрить XSS-вектор и даже символы, затрудняющие чтение в консоли записей лога.
Задачи внедрения лога
Одна из целей внедрения — интерпретаторы формата логов. Если инструмент анализа использует регулярные выражения для парсинга записей в логе, чтобы делить их на части и раскидывать по разным полям, то можно создать и внедрить такую строку, которая заставит регулярные выражения выбирать внедрённые поля вместо правильных. Например, эта запись может стать источником нескольких проблем:
Более изощрённые атаки с внедрением логов базируются на атаках с обходом каталога, чтобы отобразить лог в браузере. При подходящих условиях внедрение PHP-кода в сообщение лога и открытие в браузере файла с записями приведёт к успешному внедрению кода, аккуратно форматированного и выполняемого по желанию злоумышленника. А если дойдёт до исполнения на сервере зловредного PHP, то остаётся надеяться лишь на эффективность эшелонирования защиты, которое может уменьшить ущерб.
Защита от внедрения лога
Проще всего фильтровать все внешние сообщения логов с помощью белого списка. Допустим, ограничить набор символов только цифрами, буквами и пробелами. Сообщения, содержащие неразрешённые символы, считаются повреждёнными. Тогда в журнале появляется запись о потенциальной попытке внедрения лог-файла. Это простой способ защиты для простых текстовых логов, когда нельзя избежать включения в сообщения ненадёжных входных данных.
Второй метод защиты — преобразование порций ненадёжных входных данных с помощью системы наподобие base64, которая поддерживает ограниченный набор символов, при этом позволяя хранить в текстовом виде разнообразную информацию.
Обход пути (известен как обход каталога, Directory Traversal)
Атаки с обходом пути — это попытки повлиять на операции чтения или записи файлов в бэкенде веб-приложения. Делается это с помощью внедрения параметров, которые позволяют манипулировать путями файлов, вовлечённых в операции бэкенда. Так что атаки этого типа облегчают раскрытие информации (Information Disclosure) и локальное/удалённое внедрение файлов.
Такие атаки мы рассмотрим отдельно, но в основе их успешности лежит именно обход пути. Поскольку описанные ниже функции характерны именно для манипулирования путями файлов, имеет смысл упомянуть, что многие PHP-функции не принимают пути к файлам в привычном смысле слова. Вместо этого функции наподобие include() или file() принимают URI.
Выглядит совершенно противоестественно. Но это означает эквивалентность двух следующих вызовов функций, которые используют абсолютные пути (например, не полагаясь на автозагрузку относительных путей).
Дело в том, что относительный путь обрабатывается на стороне (настройка include_path в php.ini и доступных автозагрузчиках). В таких случаях PHP-функции особенно уязвимы для многих форм манипуляций с параметрами, включая подмену схемы URI файла (File URI Scheme Substitution), когда атакующий может внедрить HTTP или FTP URI, если в начало пути файла внедрены ненадёжные данные. Подробнее об этом мы поговорим в разделе, посвящённом атакам с удалённым включением файлов, а пока сосредоточимся на обходах путей файловых систем.
Examples of Path Traversal
Defenses against Path Traversal
Внедрение XML
Несмотря на внедрение JSON в качестве облегчённого средства передачи данных между сервером и клиентом, XML остаётся популярной альтернативой, API веб-сервисов зачастую поддерживает её параллельно с JSON. Также XML применяется для обмена данными, использующими XML-схемы: RSS, Atom, SOAP и RDF и т. д.
XML вездесущ: его можно найти в серверах веб-приложений, в браузерах (в качестве предпочтительного формата для запросов и откликов XMLHttpRequest) и браузерных расширениях. Учитывая его распространённость и обработку по умолчанию таким популярным парсером, как libxml2, используемым PHP в DOM и в расширениях SimpleXML и XMLReader, XML стал целью для атак с внедрением. Когда браузер активно участвует в XML-обмене, необходимо учитывать, что посредством XSS авторизованные пользователи могут передавать XML-запросы, созданные на самом деле злоумышленниками.
Внедрение внешней XML-сущности (XXE)
Давайте, к примеру, определим новую кастомную сущность harmless:
XML-документ с этим определением теперь может ссылаться на сущность &harmless; везде, где вообще разрешены сущности:
Когда XML-парсер вроде PHP DOM будет интерпретировать этот XML, он обработает эту кастомную сущность сразу же, как загрузится документ. Поэтому при запросе соответствующего текста вернёт следующее:
This result is completely harmless
Очевидно, что кастомные сущности имеют преимущество в представлении повторяющегося текста и XML с более короткими именами сущностей. Нередко бывает так, что XML должен следовать определённой грамматике, а кастомные сущности упрощают редактирование. Однако, учитывая наше недоверие к внешним входным данным, необходимо быть очень осторожными со всеми XML, потребляемыми нашим приложением. Например, это вовсе не безопасная разновидность:
В PHP часто встречаются три метода парсинга и использования XML: PHP DOM, SimpleXML и XMLReader. Все они применяют расширение libxml2, поддержка внешних сущностей включена по умолчанию. Как следствие, в PHP по умолчанию есть уязвимость к XXE-атакам, которую очень легко пропустить при рассмотрении безопасности веб-приложения или библиотеки, использующей XML.
Примеры внедрения внешних XML-сущностей
Содержимое файла и раскрытие информации
Выше мы рассмотрели пример раскрытия информации, отметив, что кастомная XML-сущность может ссылаться на внешний файл.
В данном случае кастомная сущность &harmless; будет расширена содержимым файлов. Поскольку все подобные запросы выполняются локально, это позволяет раскрыть содержимое всех файлов, которые может считать приложение. То есть когда расширенная сущность будет включена в исходящие данные приложения, атакующий сможет изучить файлы, находящиеся в закрытом доступе. Правда, в данном случае есть серьёзное ограничение: файлы должны быть либо XML-формата, либо формата, который не приведёт к возникновению ошибки XML-парсера. Но дело в том, что это ограничение можно полностью проигнорировать в PHP:
Это означает, что атакующий может прочитать любой доступный для PHP файл, независимо от текстового формата. Достаточно просто декодировать исходящие из приложения данные, а потом безнаказанно их препарировать. Хотя это не наносит прямого вреда конечным пользователям или бэкенду приложения, зато позволяет атакующим хорошо изучить структуру приложения в попытке найти иные уязвимости. Причём риск, что атакующих обнаружат, минимален.
Обход контроля доступа
Доступ контролируется разными способами. Поскольку XXE-атаки проводятся на бэкенде веб-приложения, использовать сессию текущего пользователя не получится. Но атакующий всё ещё может обойти контроль доступа к бэкенду с помощью запросов от локального сервера. Рассмотрим такой примитивный контроль доступа:
Этот кусок PHP, как и несметное количество ему подобных, ограничивает доступ к определённым PHP-файлам на локальном сервере, т. е. localhost. Однако XXE-атака на фронтенде приложения даёт атакующему точные учётные данные, необходимые для обхода этого контроля доступа, потому что все HTTP-запросы XML-парсера будут делаться из localhost.
Даже если бы просмотр логов был ограничен локальными запросами, атакующий всё равно смог бы получить логи. То же самое касается интерфейсов сопровождения или администрирования, доступ к которым ограничен подобным образом.
DOS-атаки
Для DOS-атак можно использовать почти всё, что диктует потребление серверных ресурсов. С помощью внедрения внешней XML-сущности атакующий получает возможность делать произвольные HTTP-запросы, которые при подходящих условиях истощают серверные ресурсы.
Позднее мы поговорим о других потенциальных DOS-применениях XXE-атак с точки зрения расширения XML-сущностей.
Защита от внедрения внешних XML-сущностей
Это нужно сделать для всех операций, подразумевающих загрузку XML из строковых, файлов или удалённых URI.
Там, где приложению никогда не требуются внешние сущности, а также для большинства его запросов можно вообще отключить загрузку внешних ресурсов на более глобальном уровне. В большинстве случаев это куда предпочтительнее для определения всех «точек» загрузки XML, учитывая, что многие библиотеки имеют врождённые уязвимости к XXE-атакам:
Только не забывайте возвращать значение TRUE после каждого временного включения загрузки внешних ресурсов. Она может понадобиться для таких безобидных задач, как преобразование Docbook XML в HTML, когда применение XSL-стилей зависит от внешних сущностей.
Однако отключающая libxml2 функция — не панацея. Проанализируйте другие расширения и PHP-библиотеки, которые парсят или как-то ещё обрабатывают XML, чтобы найти их «выключатели» применения внешних сущностей.
Если это сделать невозможно, то дополнительно проверьте, объявляет ли XML-документ DOCTYPE. Если да и если при этом внешние сущности отключены, то просто выкиньте XML-документ, запретив ненадёжный XML-доступ к потенциально уязвимому парсеру и журналируя его как вероятную атаку. Это необходимый шаг, потому что других признаков не будет — ни ошибок, ни исключений. Встройте эту проверку в свою обычную валидацию входных данных. Но этот метод далеко не идеален, так что крайне рекомендуется в корне решить проблему внешних сущностей.
Также предпочтительно сразу удалять подозрительные данные, которые могут быть результатом атаки. Зачем продолжать работать с чем-то, что выглядит опасным? Так что комбинация из двух вышеописанных мер позволяет заранее игнорировать очевидно вредоносные данные, одновременно защищая себя на случай, если удалить данные не получится (например, если это сторонние библиотеки). Удалять данные приходится и потому, что libxml_disable_entity_loader() отключает не все кастомные сущности, а только те, что ссылаются на внешние ресурсы. Что оставляет возможность атаки с расширением XML-сущности (XML Entity Expansion).
Расширение XML-сущности
Эта атака во многом аналогична атаке с внедрением XML-сущности. Но в данном случае делается акцент на DOS-атаку с попыткой истощить ресурсы серверного окружения целевого приложения. В DOCTYPE XML создаётся определение кастомной сущности, которая, к примеру, может генерировать в памяти XML-структуры гораздо более крупного размера по сравнению с исходной. Это приводит к заполнению памяти и снижению эффективности работы сервера. Такая атака применяется и к XML-сериализации HTML 5 в том случае, если последний не распознан расширением libxml2 как HTML.
Примеры расширения XML-сущности
Есть несколько способов расширить кастомные XML-сущности ради желаемого истощения серверных ресурсов.
Общее расширение сущности
Другое название — «атака квадратичного увеличения». Кастомная сущность определяется в виде очень длинной строки. Если многократно использовать её в документе, то она каждый раз увеличивается, в результате XML-структура потребляет гораздо больше оперативной памяти по сравнению с исходным XML.
Если найти баланс между размером строки кастомной сущности и количеством использования в теле документа, то можно создать такой XML-файл или строку, при расширении которых получится прогнозировать потребление серверной памяти. Если заполнить её такими повторяющимися вопросами, то выйдет настоящая DOS-атака. Недостаток подхода: изначальный XML тоже должен быть довольно большим, потому что потребление памяти зависит от простого эффекта умножения.
Рекурсивное расширение сущности
В то время как общее расширение требует использования изначально большого XML, рекурсивное обеспечивает гораздо более высокий коэффициент увеличения. Этот метод основан на экспоненциальном разложении (resolve) наборов маленьких сущностей таким образом, чтобы они существенно увеличивались в размерах. Вполне логично, что этот метод часто называют XML-бомбой и атакой миллиарда смешков (Billion Laughs Attack).
Удалённое расширение сущности
Обе вышеописанные атаки используют локально определённые сущности в XML DTD. Но атакующий способен определить сущность и удалённо, если XML-парсер может делать внешние HTTP-запросы. Как мы видели в описании XXE (внедрения внешней XML-сущности), эту возможность нужно заблокировать в качестве базовой меры защиты. Таким образом, защищаясь от XXE, мы защищаемся и от этого вида атаки.
В любом случае: для этой атаки XML-парсер должен делать внешние HTTP-запросы для извлечения расширенного значения соответствующих сущностей. В свою очередь, они самостоятельно определят новые внешние сущности, к которым парсеру придётся сделать дополнительные HTTP-запросы. Таким образом, парочка безобидно выглядящих запросов быстро выйдет из-под контроля, увеличивая нагрузку на доступные серверные ресурсы, что в результате может привести к рекурсивному расширению сущностей и усугубить ситуацию.
Вышеприведённый код также позволяет провести DOS-атаку более хитрым способом: внешние запросы должны быть адаптированы для локального приложения или любого другого приложения, совместно использующего серверные ресурсы. В результате система будет атаковать сама себя: попытки разложить (resolve) внешние сущности с помощью XML-парсера спровоцируют отправку множества запросов к локальным приложениям и потребление массы серверных ресурсов. Эта атака может использоваться для усиления эффекта XXE-атаки, ради дальнейшего выполнения DOS-атаки.
Защита от расширения XML-сущностей
Методы защиты те же, что и в случае с одиночными XXE-атаками. Нужно отключить разложение (resolution) кастомных XML-сущностей в локальные файлы, а также функции; отключить внешние HTTP-запросы с помощью следующей функции, которая глобально применяется ко всем XML-расширениям PHP, основанным на использовании libxml2.
libxml2 обладает врождённой нетерпимостью к рекурсивному разложению сущностей, поэтому ваш лог ошибок разукрасится, как новогодняя ёлка. Поэтому у нас нет особой нужды в реализации специфической защиты от рекурсивных сущностей; хотя нужно что-то сделать на тот случай, если у libxml2 произойдёт рецидив.
Конечно, нужно ещё подстраховаться и присвоить libxml_disable_entity_loader значение TRUE, чтобы ссылки на внешние сущности не были разложены (resolve) при первичной загрузке XML. Это может быть единственно возможной защитой там, где XML-парсер не зависит от libxml2, если только этот парсер не имеет исчерпывающего набора опций управления разложением сущностей.
Если вы намерены использовать SimpleXML, то имейте в виду, что с помощью функции simplexml_import_dom() вы можете импортировать проверенный объект DOMDocument.