Pull to refresh

Comments 14

Есть подозрение, что автор забыл php!=backed

Вредные советы с phpclub за 2004-й год. Чем-то таким повеяло.

Сначала начал писать замечания по пунктам, а потом понял, что это просто рандомная устаревшая хуета, просто автор особо не разбирается в тематике и все это бессмысленно.

Без негатива)

Заставили бедного сотрудника скопипастить хуйню для галочки?

import os; os.system('rm some_file')

Это легкий налет питона на пхпшный Twig?

Статья очень смешная, но при этом очень, очень полезная. Из неё становится ясно, что в SpaceWeb - ни ногой! И в этом контексте ей полезно побывать в топе, "дабы дурость каждого была видна".

Такой набор ереси даже ChatGPT не под силу. Это писал живой человек, причем человек, который не смыслит в "веб-уязвимостях" вообще ничего. Буквально. Не понимает ни одной строчки из тех примеров, которые приводит в этой статье. Хотя даже у джуна сразу возникли бы вопросы. И это "руководитель R&D SpaceWeb!", что бы это самоназвание не значило.

Плюс эту статью можно использовать как сборник вредных советов. Которым только не хватает сеанса разоблачения, по которому мы сейчас быстро пробежимся.

  1. RCE (Remote Code Execution) — инъекция кода
    Вся защита сводятся к запретам, "никогда не используем" и "запрещаем использовать". Отличная рекомендация! А ещё лучше вообще не делать веб-сайт или приложение. Вот где будет 100% безопасность! Что такое "непрямое добавление" АКА подготовленные запросы/белые списки для SQL автор не знал, да ещё и забыл в придачу. Как и функцию escapeshellarg().
    Ну и UNION+TRUNCATE+users- это новое слово в SQL инъекциях!

  2. LFI/RFI (Local/Remote File Inclusion) — подключение файлов
    Ну тут худо-бедно без галлюцинаций, если только по мелочи: allow_url_include и так отключена в php.ini по умолчанию. И непонятно, какая проблема в том, чтобы подключить любой файл проекта - они и так подключаются. Про подключение, скажем, логов (или пресловутого "/etc/passwd") наш специалист по компьютерной безопасности даже не подозревает.

  3. SSTI (Server-Side Template Injection) — инъекция в шаблоны
    А вот здесь градус маразма наоборот повышается. Сама по себе уязвимость - это плод пубертатных фантазий каких-то мамкиных хакиров, которые умудрились протащить этот частный случай RCE ажно в OWASP.
    Но прекраснее всего здесь пример, конечно же. Пример полного непонимания текста его автором. Насколько я понял, суть этой уязвимости заключается в том, что шаблонизатор рендерит подсунутый снаружи шаблон. Но наш "руководитель R&D" полагает, что речь идет о простом "отображении поискового запроса в шаблоне".
    Ну и вишенка на изюминке - payload, внезапно - на Питоне!

  4. SSRF (Server-Side Request Forgery) — подделка запросов
    Сначала показалось, что уж в этой банальности, известной каждому школьнику, накосячить просто негде. А потом вчитался в рекомендацию. Это надо отлить в граните: "Если есть возможность установить белый список адресов для обращения, делаем это. В случае, когда нет возможности ограничить адреса, исключаем обращение к внешним ресурсам". WAT?! Ну ОК, ограничиваем доступ к нашему порталу только для браузеров бабки, дедки, внучки и жучки, а остальные пользователи пусть ходят куда-то ещё. Но при чём здесь обращения к внешним ресурсам? Кто, в какие "внешние ресурсы" и зачем тут обращается? Снова автор не понял ни слова из написанного.

  5. IDOR (Insecure Direct Object References) 
    В этой банальности тоже ошибиться особо негде, только непонятно, зачем проверять "все источники". Какая вообще разница, из какого источника пришел запрос? Да хоть из консоли. "Проверка и ограничение доступа к объектам" (которую люди попроще называют авторизацией), вообще никак не зависит от источника данных.

  6. PHP Object Injection — инъекция объекта
    Здесь автор, понятное дело, не мог не облажаться, эта уязвимость чуть менее тривиальная. Тут он перепутал существующий класс в атакуемом коде (в котором и есть этот "деструктивный деструктор") с вредоносной сериализацией (в которой не может быть никаких деструкторов, а только данные). И получается, что в данном примере на атакующей стороне достаточно объявить пустой class Example1{} - эффект будет тот же самый. А чуть более жизненным примером была бы передача, скажем, имени файла, который будет удаляться в деструкторе.

  7. Упс! Больше уязвимостей нету, только 6. То ли автор слишком утомился писать этот эпохальный труд, то ли приписал в заголовок лишнюю единичку по привычке.

Это потрясающе, будь я с кармой – дал бы на акк, до слез

Как минимум RFI не работает с версии PHP 5.2 (без изменения конфигурации самого интерпретатора PHP), который вышел, на минуточку, в 2006 году.

Исправлению этой уязвимости как класса уже можно покупать пиво и сигареты.

Как вообще упоминание RFI до сих пор бывает в 2024 году - загадка.

Несколько дополнений к этому комменту и замечаний по статье:

  1. RCE - вообще не уязвимость, а последствия эксплуатации. В статье смешали внедрение SQL кода и внедрение команд ОС.

  2. В статье не упоминаются использования php://, которые позволяют выполнить RFI без внешнего URL и прочие интересные штуки.

  3. SSTI - внедрение в код шаблона, аналогично другим внедрениям, таким как SQLi. Шаблонизатор сам по себе предполагает использование подготовленных запросов, поэтому уязвимость встречается не так часто. В OWASP такие уязвимости и должны быть, т.к. RCE - слишком обширная категория уязвимостей, собранная по последствиям атаки. SSTI и внедрение команд OS являются одними из наиболее частых уязвимостей, приводящих к RCE.

  4. В статье вообще не представлена SSRF. Настоящая SSRF заключается в возможности отправлять запросы со стороны сервера для извлечения данных и взаимодействия с локалкой сервера. Например, когда сайт позволяет загрузить аватар по URL. В статье вместо этого представлен пример IDOR для не числового ID и действия удаления аккаунта.

  5. По десериализации авторы статьи скорее всего перепутали PHP с питоном. В pickle действительно можно сериализовать деструктор для выполнения кода, но в PHP нужно быть более изобретательным, чтобы найти цепочку гаджетов для RCE (если она вообще есть на целевом сайте)

Отмечу, что есть целый класс уязвимостей связанных с десериализацией XML и JSON. Всё дело в том, что в обычный XML/JSON код можно включить RPC команды, которые будут выполнены на сервере, при неправильной обработке XML/JSON.

Подробнее смотри здесь

Хочу порекомендовать ребятам из SpaceWeb перестать писать статьи, в которых пересказывается давно устаревший материал. Если у вас есть желание (а так же время и энергия) написать годный материал, то не ленитесь и проверяйте актуальность как самой темы, так и изложенного текста.

Это я, непрошенный кэп. Правилами настольного тенниса габариты ракетки не регламентируются, и даже держать ее двумя руками не запрещается. Так что Билл Гейтс на фото все делает в рамках закона.

script.php?name=aa+UNION+TRUNCATE+users --

Результат SQL-инъекции: будет удалена таблица users.

Удалена или очищена?

Кстати да, хорошее замечание :)

Ну то есть не будет ни того, ни другого, поскольку union, но даже здесь у автора галлюцинация.

Sign up to leave a comment.