Как сделать сайт своими рукамиСейчас ИИ не только выполняет написание кода, но и производит его проверку. Если попросить ИИ проверить проект на безопасность, то он выдаст множество замечаний. Я заметил, что ИИ часто ошибается в этом вопросе, поскольку начинает откровенно фантазировать и придумывать ситуации, которых не может быть в реальности. Вот некоторые, с которыми я столкнулся на практике.
«Ошибки-штампы»
ИИ часто необдуманно выдаёт откровенные штампы. Например если есть функция unserialize(), то он всегда укажет, что это небезопасно и лучше использовать не серилизацию, а json-кодирование. В качестве решения он предлагает указать дополнительные параметры ['allowed_classes' => false].
На самом деле, серилизация не проблема безопасности, поскольку unserialize() обычно работает с проверенными данными, в которых нет опасного кода. Поэтому ИИ начинает фантазировать, что если вдруг в данные попадет php-класс, а внутри окажется магические методы, которые будут автоматически выполнены при десериализации, а в этих методах будет вредоносный код, то это уже «дырка». В реальности в проекте нет таких магических методов, более того в данные для unserialize() они никогда не попадают. То есть на безопасность это вообще никак не влияет. Чтобы стать реальной «дырой», требуется очень сложная схема взлома исходных данных. На практике это неосуществимо.
Вывод необработанных данных
Это тоже частая «ошибка», которую ИИ может приравнивать к страшному слову «XSS». Например если вы что-то выводите на сайте в html-формате, то фактически не можете использовать htmlspecialchars(), а значит в вывод попадёт «сырой» код.
Если это форма или любой другой ввод пользователя, то ИИ буквально сходит с ума, считая это «дыркой».
На самом деле данные и нужно хранить в сыром виде, но обработку для вывода делать в зависимости от ситуации. Есть ситуации, когда введенные данные видит только сам пользователь. Например он ввел опасную ссылку и сайт его показал как есть. Система заблокировала отправку данных, а значит их видит сам юзер. Здесь нет ни взлома, ни дыры — пользователь просто решил ввести сам для себя «плохие» данные.
Недостаточное понимание работы проекта
Если есть отправка данных пользователем, то ИИ часто галлюцинирует, даже не пытаясь разобраться в том, как реально работает проект.
Например если пользователь отправляет комментарий с вредоносным кодом, то ИИ считает это «дырой», хотя на самом деле пользователь не видит, то что оправил — вместо текста идёт плашка «Ваш комментарий отправлен. Ждите одобрения». Сам текст попадает админу в обычном текстовом виде, там может быть что угодно. Поэтому вредоносный код физически не будет выполнен ни при каких обстоятельствах. Но ИИ не может допетрить как именно происходит администрирование комментариев и подставляет свой шаблонный алгоритм, который не имеет к проекту никакого отношения.
Или другой пример. Выводится html-код как есть, но ИИ не может сообразить, что данные были обработаны другой функцией, то есть уже безопасны.
Фантазии
С этим я сталкиваюсь постоянно.
Например есть шифрование на сайте, которое зависит от секретной фразы. Очевидно, что для каждого сайта она должна быть своей, но по дефолту она написана так: md5(SITE_URL). ИИ сходит с ума, поскольку предполагает, что секретная фраза будет единой для всех сайтов (типа юзер забыл её поменять). То есть ИИ продумывает худший сценарий, хотя прекрасно понимает, что секретная фраза будет другой. Но он уже включился в цикл и начинает «резвиться».
Другой пример — это «а что если...». Это когда ИИ начинает придумывать ситуации, которых могут произойти «проблемы». Например если сервер не Апач, а Nginx, где не работает .htaccess. То есть он сам смоделировал ситуацию и стал её развивать по худшему сценарию. Он не может сообразить, что если юзер использует какой-то свой вариант настроек, то это уже его проблемы. Я уверен, что тот, кто использует Nginx и сам понимает, что нужно сделать с «неработающими» .htaccess. Но для ИИ пользователь всегда тупой.
Ещё пример. У меня по умолчанию в .htaccess есть строки для Content-Security-Policy, но они закомментированы. Это из-за того, что на разных серверах они могут различаться. Более того, CSP — очень специфичная вещь, когда нужно блокировать трафик под разные условия. ИИ это понимает, но развивает эту ситуацию в «плохую» сторону и начинает «накручивать». В реальности для 99% сайтов это даже не нужно.
Другой пример. Например в Albireo CMS есть файл zip.php, через который можно быстро сделать бэкап сайта. Это удобный и простой механизм, который позволяет за несколько секунд получить все данные сайта. На выходе формируется zip-файл со случайным хэшем в имени. То есть вероятность того, что кто-то его подберёт близка к нулю. Для запуска zip.php требуется секретный ключ.
ИИ начинает фантазировать, что а) секретный ключ может быть слишком простым и б) а вдруг кто-то подберёт имя zip-файла? Поскольку он и сам понимает, что ответы — это тупик, то начинает предлагать какие-то свои идеи, вообще не имеющие отношение к назначению этого файла.
Последний пример. Как-то ИИ посчитал, что сайт может работать по http (а не по https), а значит возможен «угон куки», которую теоретически можно раскодировать и дальше он стал строить цепочку рассуждений, которую сам же и завершил, что дескать лучше работать по https. То есть он сам придумал проблему, сам же её раскрутил и выдал как проблему безопасности. Это не значит, что проблемы с http нет, но он возвёл её слишком высоко, поскольку не учёл, что если сейчас сайт работает по http, значит это продуманное решение пользователя (например для локального тестирования).
Накручивание «проблемы»
Очень часто это даже не проблема, но ИИ возводит её в ранг «дырки». Например у меня отслеживается количество попыток отправки формы. Естественно для обычных пользователей с браузерами. Но ИИ вдруг решает, что должна быть защита от ботов, которые просто игнорируют браузерные заголовки и защита не работает. Поэтому он начинает предлагать какие-то сумашедшие идеи о том, что нужно хранить IP ботов и отслеживать из через базу данных.
То есть ИИ не может понять, что защита от ботов происходит уже потом на уровне обработки данных. Да он может отправить 1000 сообщений в секунду, но это уже не проблема системы, а проблема сервера. Сама система отсеет все эти отправки, то есть в реальности никакого вреда (кроме трафика) не произойдет. Но ИИ уже накрутил ситуацию.
Другой пример. Например ИИ накрутил себе, что если будет ошибка в конфигурации Nginx, то любой сможет получить доступ к закрытым каталогам сайта (Require all denied). Даже если это произойдёт, то ИИ расценивает это как катастрофу. На самом же деле многие каталоги защищены скорее по привычке, чтобы никто в них не «заходил». По факту в них могут быть php-файлы, которые невозможно выполнить напрямую, поскольку все они защищены строчкой прямого вызова. Даже если её нет, то скорее всего файл вывалится с ошибкой. И я молчу про то, что обычно в php-файлах только объявляются функции и классы, но не выполняются при подключении.
То есть ИИ сильно накручивает, но не понимает, что в таких случаях данными невозможно воспользоваться. Даже если это sqlite-база, то всё равно в ней нет критически важных и секретных данных. Например кэширование страниц содержит только заголовки и служебную информацию, которая и так видна на каждой странице сайта. Даже если в открытую опубликовать файл базы, то это никак не сказывается на безопасности.
Я не говорю, что это правило для всех. Мои примеры касаются Albireo CMS, где все важные данные хранятся в обычных php-файлах (конфигурация). Даже если открыть каталог, то невозможно получить данные из этих файлов.
Или ещё частая накрутка, когда происходит вывод ошибок на странице сайта. ИИ считает катастрофой, если там будет путь к ошибочному файлу (или цепочке файлов). В реальности это вообще никак не влияет на безопасность, поскольку знать расположение файлов это просто информация. Воспользоваться ей для взлома — нереально, особенно для открытых проектов. То есть ИИ перебдел, только непонятно зачем.
Как стрелять себе в ногу
Это тоже из области накрутки. ИИ может придумать ситуацию, когда пользователь может сам себе отправить вредоносные данные. Например юзер может ввести XSS-код в поле формы и сам же её получить. Фактически от этого пострадает сам юзер, поскольку данные остаются только у него.
Или другой пример. Если есть доступ к админке, то юзер может написать что-то на PHP, что начнет превышать его разрешения. Это очень сложная ситуация, поскольку если система работает на PHP и юзеру разрешено его использовать, то фактически он может сделать что угодно. Именно поэтому я всегда говорю, что админка не для посторонних — это 100% доверенная зона. Если админ не доверяет юзеру как человеку, то ему в админке делать нечего (MaxSite CMS).
В Albireo CMS ситуация ещё круче, поскольку здесь админу можно выполнять любой php-код: хоть на уровне страниц, админки, конфигов и т.п. Это идеология системы — 100% доверие пользователю, если ему хочется стрелять себе в ногу, пусть стреляет.
Итого
То что ИИ может сделать аудит — неплохо. Это хороший дополнительный инструмент для любого разработчика. Но не следует слепо доверять ИИ по каждому пункту. Часто он ошибается, фантазирует и накручивает проблему. На мой взгляд при аудите безопасности важно различать реальную опасность от вымышленной. ИИ часто путает их между собой, хотя в реальности не сможет создать цепочку взлома через найденную «дыру». То есть его фантазии часто не имеют практической реализации. В идеале нужно требовать от ИИ не просто аудита безопасности, но и подтверждать реальным кодом её эксплуатацию. Тогда такой аудит будет намного полезней.