Кто в 2020 все еще имеет дело с PHP? Предложение!  Публичный пост

Казалось бы - есть куча разных новомодных языков типа Golang. Но PHP все еще уверенно входит в TOP-10, а самым популярным движком для сайтов остается WordPress, который написан на оном PHP.

Мне очень часто приходилось иметь дело с PHP, но не как разработчик, а как DevOps и каждый раз, когда я размещал приложение, в котором все настройки были в открытом виде прописаны в config.php, то содрогался от ужаса, представляя себе хаккера, который взламывает код, считывает креды и сливает себе базу.

Я приглашаю вас на дискуссию по обеспечению безопасности приложений на интерпретаторах, где для примера взят PHP как наиболее популярный.

PHP zero-day attack model
PHP zero-day attack model

Будут рассмотрены такие кейсы:

Угроза уровня Zero-Day, когда уязвимость в самом интерпретаторе PHP, а не в том коде, который на нем написан
Почему вынос конфигов за пределы вебсервера и использование переменных окружения не защищает (https://www.php.net/manual/ru/ini.core.php#ini.sql.safe-mode)
Невозможность использования One Time Password для доступа к хранилищу секретов в PHP (https://github.com/mittwald/vaultPHP)

Приходите, будет интересно. https://www.linkedin.com/events/6738138413498724352/

130 комментариев 👇
Konstantin Marinenkov, PHP & Go Кекендер 27 ноября 2020

В целом, две самые главные проблемы PHP - это его репутация из начала нулевых и версий 4-5.0, когда все мы были юны, свежи и лепили весь этот ваш MVC в один index.php, со всеми конфигами и секретами, и тонна сомнительного легаси, написанного в этом стиле.

В целом, как по мне, сейчас пых стал куда взрослей, обзавёлся добротными фреймворками всех мастей и возможностей, за те самые config.php принято бить тапками, плюс очень большая работа в семёрке над скоростью.

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

P.S. Моя любимая пикча на эту тему 😜

  Развернуть 1 комментарий

@dwdraugr, Пикча смешная. А ситуация страшная.
Смотрите — у вас есть приложение на PHP, которое обслуживает сайт для оплаты мобильного телефона. Как минимум у вас есть личный кабинет с телефонами пользователей.
Ваш PHP скрипт должен иметь возможность работать с базой данных, чтоб писать-читать информацию о пользователях.
Для этого вы информацию где-то храните — в конфиг-файле или переменных окружениях, не важно.
Если сам PHP-интерпретатор (бинарник) имеет уязвимость нулевого дня типа CVE-2019-13224, то можно послать такой запрос, который будет выполнятся в контексте самого процесса PHP, не имея отношения к вашему коду.
Что это значит — если процесс PHP может прочитать файл с кодами или окружение, то значит и хаккер сможет.
А это значит, что все ваши совет про хранение отдельно файлов, ротации и файрволл — бесполезны. Раз хаккер действует в контексте PHP процесса, то он получает все доступы.

Хотите обсудить меры противодействия? Приходите на дискуссию!

  Развернуть 1 комментарий

@andreyka, в целом, от CVE в интерпретируемых средах не застрахован никто, поэтому гон в сторону именно PHP мне не ясен. А уж если злоумышленник получил возможность ползать по файлам на сервере, то тут хоть на ассемблере пиши, ничего не поможет.

  Развернуть 1 комментарий

@dwdraugr, Я преглашаю в свою дискуссию, где мы обсудим возможные методологии решения подобных проблем.

От защиты утечки секретов из файлов/окружения давно придуман OTP. Но в таких интерпретаторах как PHP, его невозможно применить. У меня есть методология для избежания подобных проблем.

  Развернуть 1 комментарий

@dwdraugr, не очень понял, где бьют тапками за условные config.php. Можно конкретные примеры?

Большинство популярных CMS именно так и делают. Wordpress, Bitrix, Joomla, Opencart, MODX — у всех просто PHP-файл с доступами к БД внутри. Не похоже, чтобы кто-то хотел это исправить. У меня есть ощущение, что это просто считается нормальной практикой.

  Развернуть 1 комментарий

Я работаю, уже 20+ лет, из них лет 15 его хоронят. В последние годы язык движется в правильную сторону, на 8.0 уже почти можно будет нормально писать.

куча разных новомодных языков типа Golang

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

все настройки были в открытом виде прописаны в config.php

Какое это отношение имеет к языку? Это можно на любом языке сделать.

Я не совсем понял вопрос, если честно. Если вопрос о перспективах - я думаю, что этот вопрос решится в ближайшие 5-10 лет и в значительной мере зависит от того, будет ли улучшена поддержка асинхронности (сейчас это всякие либы вокруг генераторов вроде Amp) и многопоточности (современные сборки по умолчанию не потокобезопасны). Уже сделано много шагов в правильном направлении, взять те же FFI и JIT.

  Развернуть 1 комментарий

@EduardSurov, Что значит это можно сделать в любом языке?
Например я могу в golang передать через переменную окружения/файл OTP, через которое он зайдет в секрет-менеджер, вычитает секреты в процесс и будет обрабатывать все запросы.
Но PHP так не может, ведь он - интерпретатор и каждый раз ему надо читать файл с секретами.

  Развернуть 1 комментарий

@andreyka, это значит, что и в голанге можно засунуть секреты в const\vars. И точно так же передавать через переменные в пыхе.

  Развернуть 1 комментарий

Ну так запихнуть секреты в Vault а потом прокинуть как ENV в контейнер

  Развернуть 1 комментарий

а что мешает сделать то же самое в php?

  Развернуть 1 комментарий

@aktuba, то, что PHP - интерпретатор. Он каждый раз будет лезть с OTP, но OTP экспайрится после первого раза

  Развернуть 1 комментарий

@Offout, Ну так хаккер читает ENV и твои базы стали его базами

  Развернуть 1 комментарий

@andreyka, В ENV находится OTP, который перестает работать после первого обращения. Но PHP так не умеет.

  Развернуть 1 комментарий

php и не должен это уметь (как не умеет ни один другой язык). Берёте доступы, кладёте в какое-то внутреннее хранилище (упрощенно - в переменную), так?

Ну так и на php сделайте то же самое: положите в кеш, например. https://www.php.net/manual/ru/book.shmop.php как вариант, хоть и ограниченный.

  Развернуть 1 комментарий

@aktuba, Смотрите внимательно.
Вот у меня приложение на golang, которое стартует. Оно читает переменную окружение с одноразовым паролем. Затем делает запрос к хранилищу, вычитывает секртеты. После этого пароль из переменной работать не будет - да и не нужно, ведь все секреты в памяти процесса, который слушает запросы.

Но PHP так не умеет - оно на каждый вызов создает запрос, который должен откуда-то читать эти секреты.
И не важно где они будут лежать, в файле, в переменной окружения или в shared memory. Если PHP интерпретатор может их прочитать оттуда - то сможет прочесть и взломщик через PHP RCE. Понимаете о чем я?

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

  Развернуть 1 комментарий

PHP так не умеет - оно на каждый вызов создает запрос

Что значит не умеет? Кто мешает писать асинхронные сервисы на похапе и стартовать их единожды?

  Развернуть 1 комментарий

Вы как-то смешали в одну кучу всё. Смотрите, есть 2 режима работы (если знаете другие - буду благодарен за информацию):

  • держать в памяти доступы (в переменной, упрощенно) и иметь возможность, например, реконнектов к сервисам
  • делать персистент-коннект к сервису и забывать доступы после первого использования. Но тут проблема - в случае любой ошибки, например сетевой (привет хецнеру) всё приложение просто падает, что не гуд.

Так вот: оба этих режима легко реализуются в php. Первый уже обсудили, второй - берём amphp / rr / reactphp и реализуем вашу схему.

Из опыта: буквально пару месяцев назад реализовывал на amphp коннект к headless chrome без хранения конфигурации в файле (правда и из env доступы не удалял, хотя это легко).

По факту - это вопрос реализации, а не языка. Я не один раз видел, когда ради хот-релоада на гошке вычитывали конфиг именно из файлов при каждом запросе. Значит ли это, что и go можно записать в говно-языки? ;)

  Развернуть 1 комментарий

Можно ссылку на документацию или пример?

  Развернуть 1 комментарий

Падение приложения решается его запуском в нескольких контейнерах
Во всех сразу да не упадет
Можете указать ссылки на примеры решений, которые вы упомянули?

  Развернуть 1 комментарий
  Развернуть 1 комментарий

Спасибо
Изучу детальнее.

  Развернуть 1 комментарий

@aktuba, Документация не очень, причем у всех трех.
Если там форкается новый дочерний процесс - то нет, это не подойдет, так как секреты от родителя надо будет передавать как-то дочерним процессам. И это можно будет отловить хаккеру менее чем за 5 минут.
Если же это мультитред от одного процесса - желательно ссылка на страницу документации, где это явно описано.

В любом случае - спасибо за ваш труд!

  Развернуть 1 комментарий

Оохх... То вам надо, чтобы доступов не было, то - чтобы были и передавались в дочерние треды/процессы... Ну ок.

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

  • если нам необходимо хранить секреты (хотя вы как-раз были против этого, насколько помню) - никаких проблем с любой из библиотек нет. при старте получаем и храним в процессе, передавая тредам.
  • если не храним секреты, то при старте приложения получаем их, используем и забываем.

Ваш комментарий про первый вариант, верно? Ок, давайте по нему. Итак:

  • roadrunner: прямо на главной странице "RoadRunner utilizes goroutines and the multi-threading capabilities of Golang to bring maximum performance to PHP applications."
  • amphp: на главной "Amp is an event-driven concurrency framework for PHP providing primitives to manage cooperative multitasking building upon an event loop, and promises."
  • reactphp: на главной "Its event-driven architecture makes it a perfect fit for efficient network servers and clients handling hundreds or thousands of concurrent connections, long-running applications and many other forms of cooperative multitasking with non-blocking I/O operations."

Честно, я не знаю как еще более заметным всё это сделать). Думаю, про асинхронность не надо рассказывать?

Чесно слово - я устал объяснять, что язык не важен, важна архитектура и реализация. И у меня появился к вам вопрос: представим гипотетическую ситуацию, что есть golang-приложение, которое хранит секреты в себе (полученные по вашей схеме) + злодей, получивший доступ к контейнеру/железу. Сможет ли он, оборвав внешние соединения, проснифать доступ к бд?

  Развернуть 1 комментарий

@aktuba, Вы прямо меня заинтриговали. Попробую на следующей неделе запустить какой-то популярный фреймворк через эти решения и проверить, действительно ли там threads или prefork.

Ответ на ваш вопрос - нет, не сможет. Ибо соеденение с базой идет через TLS, это раз. А два - сам пароль хранится в памяти через разделение секрета и соеденить эти части - довольно долго.

Ну а через 5 минут сработает алерт в SIEM и лавочку прикроют. Вероятность успешной атаки за 5 минут при этих факторах настолько мала, что эти критерии становятся приемлимыми.

  Развернуть 1 комментарий

Удивительно... Был наброс на язык, а теперь откуда-то фреймворки взялись). Ну да ладно, под фреймворки годится только roadrunner, остальное можно, но сложнее.

А вторая часть прям повеселила, серьезно. «Нет, не сможет» и «долго»:

  • не совместимые, в данном контексте, выражения
  • оба подтверждают мой довод, что язык не важен, важна реализация
  Развернуть 1 комментарий

@aktuba, Ну смотрите - вы предлагаете проверить решение. Чем я его буду проверять? Возьму https://github.com/tokenly/laravel-vault, модифицирую чтоб после чтения секретов сделал ревок (если еще нет) и проверю что секреты передаются в треды через память.

И еще одно - на счет «Нет, не сможет» и «долго». Вы немножко путаете теплое с мягким. У меня нет цели сделать абсолютно защищенную систему. Моя задача - задержать атаку минут на 5, чтоб сработала система оповещений. Но я должен быть уверен, что там нет секретов в открытом виде - иначе это будет быстрее 5 минут.

  Развернуть 1 комментарий

Да что-ж такое... Как вы умудряетесь переобуваться в воздухе?) Хронология ваших высказываний:

  • php плохой, потому что читает все файлы при каждом запросе и отдаёт их содержимое первому встречному. Нет.
  • проблема не в скриптах, а в бинарнике php, т.к. он не позволяет хранить секреты не в файлах. Нет.
  • проблема не в php, а во фреймворках, т.к. они содержат конфиги в файлах. Нет.

Хотите проверить laravel на предмет пригодности под вашу схему - ваше право. А почему не хотите проверить именно php? Берёте amphp (как наиболее простой вариант) и пробуете. В чём проблема?

  Развернуть 1 комментарий

Проблема в уязвимости самого бинарника - есть возможности RPC
Я хочу использовать для проверки вашего решения готовый фреймворк, который поддерживает Hashicorp Vault.

  Развернуть 1 комментарий

Проблема в уязвимости самого бинарника - есть возможности RPC

Дадите ссылку на описание уязвимости? Или снова всё в рамках "мне так кажется"?

  Развернуть 1 комментарий

Уязвимости нулевого дня нигде не публикуются. Есть уже запатченные, но я давал пример на такую.

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

@EduardSurov, я вот в корне не согласен вот с этим утверждением:

Последнее, что стоит делать в разработке - это гнаться за модой.

Мне вот показалось, в разработке крайне важно отслеживать модные тренды и всегда иметь в иметь в загашнике один стек, который вряд ли сдохнет в ближайшие 5 лет, и другой - который может через годик-другой мощно выстрелить. Технические характеристики языка и его библиотек - это вообще десятый вопрос, главное понимать, сколько вакансий будет на рынке и сколько в каждой будет денег.

  Развернуть 1 комментарий

Важно отслеживать не моду, а перспективу - это не одно и то же.

  Развернуть 1 комментарий

@EduardSurov, вы имеете в виду, что надо разглядеть, что в каких-то случаях за модой, возможно ничего не стоит?

  Развернуть 1 комментарий

В большинстве случаев это именно так, тут и разглядывать нечего. А вот чтобы предсказать, что останется на плаву, когда хайп схлынет - нужно иметь прокачанную инженерную интуицию.

  Развернуть 1 комментарий
Ivan Filatov, PHP програмист/SRE 27 ноября 2020

6 лет пишу на PHP, брат жив, язык тоже.
Репутация его была сформирована в умах слишком давно и не имеет отношения к современной реальности.
Да, на PHP, пожалуй, легче и быстрее всего написать бэк для новичка. И да, там может куча ошибок и дыр в безопасности.
Но если тот же новичок просто возьмёт фреймворк, ему уже надо будет заморочится чтобы допустить проблемы безопасности.
В остальном язык быстр, распространён, с отличной экосистемой, с кучей специалистов и кучей уже существующего кода.

  Развернуть 1 комментарий

@Offout, Тут вопрос не про уязвимости на уровне ошибок в PHP скрипте/фреймворке. Тут более высокоуровневая проблема - ошибка в самом интерпретаторе (бинарнике php).

  Развернуть 1 комментарий
  Развернуть 1 комментарий

@rozhok, Картинка красивая. Но если вы работаете, например, по стандартам PCI-DSS, то вас будут штрафовать за утечку на $5,000 - $100,000 ежемесячно. Как-то уже цифра стала не такой уж и красивой, верно?

  Развернуть 1 комментарий

@andreyka, ха, у нас тоже PCI-DSS на пыхе! 😄

  Развернуть 1 комментарий

А надо ли 99% юзеров пхп работать по этому стандарту? Мне кажется прикручивают платёжный сервис Яндекса, stripe и тд, и не парятся о том чтобы номера карт через себя пропускать, боже упаси =)

  Развернуть 1 комментарий

Приходите на дискуссию
Будет, что обсудить

  Развернуть 1 комментарий

Вы правы, это узкая специфика

  Развернуть 1 комментарий

@TepMex, надо, если вы сами платежный шлюз)
Это уже так сказать некст левел, когда пол процента - процент комиссии уже очень много.

  Развернуть 1 комментарий

Плох тот стартап который не хочет экономить полпроцента

  Развернуть 1 комментарий

(мое небольшое ИМХО основанное на предыдущих постах и комментариях автора)

Любая попытка скрыть пароль от базы данных в случае исполнения случайного кода на вашем сервере злоумышленником обречена на провал. Все, что вы пытаетесь сделать, это обфускация, а не защита. Никому ваш пароль собственно и не нужен будет -- БД скорее всего защищена на сетевом уровне и все равно недоступна извне.
Вы видете проблему там, где ее на самом деле нет.
Злоумышленник не будет пытаться подключиться к БД напрямую чтобы сдампить ее -- зачем? Вместо этого он просто встроит в ваш сервер код, который позволит ему выполнить произвольный запрос. Ваше приложение само выдаст все данные по команде.

Если все-таки ваша база доступна всему интернету, и очень хочется найти именно пароль, то поверьте, хоть где-нибудь в памяти он останется. Как правило, виртуальные машины позволяют снять дамп памяти в отладочных целях, придется только хорошо в нем покопаться. Если даже пароль будет действительно удален, в памяти найдутся ключи сессий, позволяющие восстановить соединение с БД без пароля.

И, как уже дважды сказали, PHP не заставляет вас использовать классический подход с CGI когда каждый запрос исполняется в собственном процессе php. Я полагаю, так сейчас уже не делают.

  Развернуть 1 комментарий

Смело
Давайте я вам дам доступ к приложению на go, а вы попробуете за сутки выдрать пароль к базе?
Если получится - я вам поклонюсь и нарезку мастером

  Развернуть 1 комментарий

Так вы и сами ниоткуда паролей не выдирали, чтобы титулы раздавать.

  Развернуть 1 комментарий

@EduardSurov, лично я - нет. Этим занимался QSA со своей командой. Но эту проверку я прошел. Правда не с первой попытки.

  Развернуть 1 комментарий

@andreyka, ну так возьмите PHP-сервис на Amp, который использует OTP для доступа в Vault, и либо покажите, как ваш QSA выдирает оттуда базу, либо прекратите гнать ересь про "единый бинарник" и "интерпретируемые языки".

  Развернуть 1 комментарий

@EduardSurov, Обязательно попробую запустить на следующей неделе под этими тремя сервисами какой-то более-менее популярный продукт типа WordPress и Laravel, и если пойдут - проверю secretless уровень.
Если все выйдет - то это будет здорово, а авторы решения будут упомянуты мной в дискуссии.

Однако это мало чем поможет, если вам когда-то поставили зазенденный index.php, который вы не сможете переписать. Но такой кейс я тоже буду рассматривать!

  Развернуть 1 комментарий

Вы бы уже определились с одним из вариантов:

  • проблема в языке и вашу схему невозможно реализовать
  • проблема во фреймворка/cms, которые по умолчанию не предоставляют такую возможность

Вы набросили на язык, вам со всех сторон объясняют, что язык тут не при чём, что авторы решений поступают по своему (и этому есть объяснение и весомые доводы), что такую схему можно реализовать или не реализовать на любом языке (а не фреймворке), но вы перескакиваете с одних требований и условий на другие. Не красиво.

  Развернуть 1 комментарий

Я и хочу решить проблемы уязвимости нулевого дня для бинарника php, что защитить от утечки информации любые скрипты и фреймворки
В том числе заэнкоженые

  Развернуть 1 комментарий

Честное слово, я устал. Сначала вы набрасываете на язык и только сейчас выясняется, что вы хотите защитить всё и ничего одновременно... Могу только пожелать удачи и больше не разбрасываться пустыми упреками и утверждениями.

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

Простите, что утомил вас
Но ваши старания не пропадут зря - я упомяну вас в своей дискуссии

  Развернуть 1 комментарий

Т.е. на хабре мало было комментов? Могу, конечно, скопировать оттуда сюда свой-же коммент, но можно уложиться в одну фразу: при кривых руках язык не при чём.

  Развернуть 1 комментарий

@aktuba, Слишком примитивно. Ошибки совершают все люди, а значит уязвимости есть везде - в том числе и ошибки нулевого дня.

  Развернуть 1 комментарий
Валентин Хомутенко, Бэкенд-разработчик 27 ноября 2020

Что-то да, наброс на config.php странный. В любом интерпретируемом языке такое встречается у разных разработчиков. И в JavaScript, и в Python (config.py в pgAdmin, например). Будут так делать или нет зависит от разработчиков, а не от языка. Чисто технически там можно делать и по-другому спокойно.

По теме если, то на PHP не пишу, поэтому сложно оценить, насколько язык плох или хорош. Но у нас в Авито очень много PHP и хотя и есть тренд перехода на Golang, но он далеко не во всех командах и отделах. Кому-то он не зашел и они продолжают писать на PHP :)

  Развернуть 1 комментарий

@valentin-kh, А пайтон в режиме веб сервер каждый раз перечитывает конфиг? Или он его считывает и передает в виде переменных в дочерние процессы?

  Развернуть 1 комментарий

Сам Python не работает в проде в режиме веб-сервера, обычно перед ним ставят гипервизор типа gunicorn, который запускает нужное количество процессов и между ними по внутреннему протоколу раскидывает входящий трафик. Соответственно, если какой-то из воркеров умер, то его нужно перезапустить и конфиг должен все еще быть доступен там же, если сервер конфигурируется условным config.py
Насколько я понимаю, fpm для PHP работает примерно так же.

  Развернуть 1 комментарий

Ну значит болячка и для Пайтона тоже актуальна

  Развернуть 1 комментарий

Вы всё о своём) "Болячка" актуальна для любого языка, это вопрос реализации.

  Развернуть 1 комментарий

@aktuba, Только для интерпретаторов. Если непонятно почему - приходите на дискуссию, я вначале озвучу тезисы.

  Развернуть 1 комментарий

Нет, не только. Я выше или ниже приводил пример, когда ради хот-релоада на golang постоянно читался файл конфига. Еще раз - это вопрос реализации, никак не языка

  Развернуть 1 комментарий

Ну значит интерпретируемые языки плохо подходят для частей систем, которые должны соответствовать over9000 стандартам безопасности по юридическим причинам, ок. Это же не значит, что PHP плохой язык.

  Развернуть 1 комментарий

@aktuba, Можно уточнить, что такое хот-релоад и зачем он нужен?

  Развернуть 1 комментарий

@valentin-kh, Я и не говорил что плохой. Просто у интерпретаторов определенные проблемы с безопасностью.

  Развернуть 1 комментарий

Изначальный наброс звучал именно так. Это хорошо видно по первым комментариям, до апдейта первого поста с учетом заголовка «Кто вообще использует PHP сейчас».

  Развернуть 1 комментарий

@valentin-kh, Мой заголовок - "
Кто в 2020 все еще имеет дело с PHP?"

И я еще указал, что этот язык входит в ТОП-10. Где тут вообще негатив?

Я лишь предложил поучаствовать в дискуссии, если у вас есть потребность решить вопросы уровня защиты от уязвимостей нулевого дня.

Странно. Наверное я не могу четко выразить свою мысль без эмоционального акцента.

Но спасибо за замеачние - буду стараться быть более понятным.

  Развернуть 1 комментарий
Захар Кириллов, Амбассадор ЕРАМ в Клубе 27 ноября 2020

Приятно, что ваш пост написан на следующий день после выхода PHP 8.0, который наконец-то решает множество родовых проблем языка и, я надеюсь, позволит ему и дальше развиваться не только как «язык скриптов, на котором написан Вордпресс» (или какая-то другая CMS-как для сайта)

Сам я работаю с PHP с версии 3, вышедшей в 1998 году. Настройки в текстовом файле, на мой взгляд, — это наименьшая из проблем языка была.

config.php просто ж хранят за пределами условной /public директории (aka document_root), выпяченной в интернеты. ну или на худой конец .htaccess можно прикрыться, но это уже такое себе.

Более трудоёмкий вариант — прописать пароли в недрах самой конфигурации php/вебсервера/пользовательских переменных (типа SetEnv в VirtualHosts апача) — тогда всякие mysqli_connect() можно вообще без параметров вызывать, ну или получить пароли через $_ENV

Конечно надо не забывать отключить phpinfo() и вообще применить весь арсенал php hardening какой есть (хоть он и достаточно примитивный, но тем не менее).

Ну а если уж хацкеру удалось читать содержимое файлов из любой директории на сервере, то там проблемы совсем другого класса.

  Развернуть 1 комментарий

@zahhar, Увы, все ваши варианты бесполезны.
На том-же golang никаких директорий на сервере не будет - сам golang и есть сервер.

  Развернуть 1 комментарий

@andreyka, дык если стоит задача разработать payment gateway или нутро итернет-банка, который надо сертифицировать по PCI-DSS, то есть много причин выбрать go/java/.netcore вместо php. каждой задаче — свой инструмент в соответствии с требованиями.

  Развернуть 1 комментарий

На том-же golang никаких директорий на сервере не будет

Это ложное утверждение. Хакер же исполняет код в контексте нашего сервиса, а сервис исполняется на некой linux-машине, будь то контейнер или голое железо; разумеется, хакер будет иметь доступ к файлам этой машины в рамках прав процесса.

  Развернуть 1 комментарий

В теории да
Но на практике у вас может быть ядро на пыхе с 90-х
Вспомните ситуацию с cobol

  Развернуть 1 комментарий

Пардон, но go выдает единый бинарь
Никаких директорий там нет

  Развернуть 1 комментарий

У меня изначально были большие сомнения в вашей компетенции, но после данного комментария, думаю, всем все понятно.

  Развернуть 1 комментарий

@EduardSurov, Это здорово, что вам все понятно. Уверен, что вы со своим знанием и пониманием сможете создать тру диджитал банк и защитить его по PCI-DSS. Дерзайте!

  Развернуть 1 комментарий

@andreyka, Если мне когда-нибудь потребуется это сделать - вы можете быть уверены на 100%, что к вам я за консультациями не пойду. Успехов вам с вашим эвентом.

  Развернуть 1 комментарий

@EduardSurov, Не в обиду — если ваш CSO решит, то скорее всего он даже не спросит об этом а просто уведомит по факту

  Развернуть 1 комментарий

На самом деле автор пригласил нас на вебинар(?) послушать и обсудить(?) как решать проблему доступа к секретам в PHP в рамках необходимости обеспечения безопасности для сертификации PCI/DSS.

Но сделал это так, будто "PHP" плохой, а "бинарник golang" хороший.

Мы тут все на это здорово триггернулись и усторили небольшой бардак.

А автор всего лишь хотел рассказать о безопасности.

  Развернуть 1 комментарий

Я бы не взял на себя смелость решать за автора, что он хотел нам сказать. Я полагаю, что что хотел - то и сказал.

  Развернуть 1 комментарий

@rozhok, Спасибо
Именно это я и хотел обсудить. Наверное мне лучше такие вопросы озвучивать голосом, так как текст можно трактовать двояко, если не слышать эмоционального контекста. Постараюсь исправить.

  Развернуть 1 комментарий

@rozhok, автор всего лишь хотел сказать что интерпретатор PHP который пилят уже 20 лет по-умочанию хуже любого приложения на GoLang. Там не может быть дыр допущенных разработчиком приложения и не может быть багов в реализации самого языка =)


Но вообще идея с одноразовым получением доступов интересна. Также в комментариях выше был вопрос о том что будет если инстанс приложения упадет. На это было предложено запускать несколько контейнеров с приложением.

Ну вот, допустим, запустили мы 3 контейнера и через какое-то время они все попадали. Автоматически они уже не поднимутся? Нужно звать девопса чтобы он руками сделал какую-то магию или автоматически запустится процесс деплоя с получением свежих креденшлов?

  Развернуть 1 комментарий

@rhamdeew, 1. Почему упали 3 сразу? Разумеется, что подымутся автоматом. Если девопс все правильно настроит.

  Развернуть 1 комментарий

вот имею дело с приложением на пхп (со стороны devops), которое приносит очень порядочно денег (pci-dss там, слава богам, нет) - и всем стейкхолдерам АБСОЛЮТНО ПОФИГ на безопасность.

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

Очень понравилась картинка про remoteok.io - с пхп работает один подход: максимизировать и выдоить максимум из проекта, желательно поменьше напрягаясь. Более тут обсуждать нечего :)

P.S. Театр безопасности не уникален для PHP, на других платформах и языках тоже самое. Всегда надо смотреть на выгодоприобретателей, произносящих это слово.

Реальная безопасность работает совсем по-иному.

  Развернуть 1 комментарий

@longbow, Приходите на дискуссию, обсудим какие меры можем принять, когда верхи не могут, а низы - не хотят. (Ну или наоборот).

  Развернуть 1 комментарий
Alex Danilenko, Отец, муж, веб-горилла 28 ноября 2020

10 лет работаю с Drupal. Каждый год про него говорят что он отстой, потому что первое, второе, третье и пхп вообще создан чтобы умирать.

Но вот удивительно: ентерпрайзы его всё выбирают и выбирают в качестве источника контента для своих нужд, потому что админку можно построить быстро (и удобно для контент манагера) и контент можно строить как захочешь.

Можно натыкать любой необходимый функционал мышкой, наставив сотню модулей (тем самым забив всю память на сервере при выполнении запроса), а можно сделать то же самое парой (или немного большим кличеством) строчек кода. При умелом обращении друпал, пусть хоть и написан на пхп, но показывает отличную производительность.

Начиная с восьмой версии ядра друпала он построен на компонентах симфони и избавился от коллбек ада. Теперь у разрабов в руках нормальный человеческий ООП, компоненты симфони, композер, отлично задокументированный код ядра, который позволяет не лезть в документацию каждый раз, и все вытекающие из этого плюсы. Как бонус - любой симфонист может запрыгнуть в друпал через пару вечеров с документацией.

Даже если строить на основе друпала сложные гуй приложения на каком нибудь новомодном вуе/реакте, то он очень хорош в качестве бекенда для апи: ставишь модуль который предоставляет доступ к контенту через JSON:API или GraphQL, расставляешь галочками ACL и отдаешь фронтендерам апи ендпоинты на растерзание.

У друпала есть очень прокачаный функционал для контент манагеров: модуль Workflow, который предоставляет прокачаные ревизии контента, аппрувы/реджекты и всякую фигню которой обмазываются контент манагеры в больших компаниях с кучей легал аппрувов на разных уровнях для любой запятой.

Резюмируя: PHP всё хоронят и хоронят уже сколько, лет 15 подряд? PHP - это не только говно-вордпресс, годные продукты на нем все еще есть и они останутся живыми и поддерживаемыми, так как плотно влезли в ентерпрайз сектор на десятки лет вперед.

  Развернуть 1 комментарий

@alexander-danilenko, Drupal - это скрипт. Я же говорю об уязвимостях того php, который бинарник и выполняет этот скрипт.

Против Drupal ничего не имею, у меня старая версия моего сайта dedic.ru работала на нем.

  Развернуть 1 комментарий

@andreyka, сори, я не с целью набросить, а с целью донести что продуктов на пхп больше чем один вордпресс, и каждый задачи безопасности решает по своему. почти всегда - успешно.

уязвимости на уровне скриптов были и будут всегда, и не всегда нужно решать эти проблемы на уровне интерпретатора и/или сервера. иначе веб-инфосеки останутся без работы :)

  Развернуть 1 комментарий

Да нет в бинарнике php такой «уязвимости». Почему вы смешиваете язык, интерпретатор и механизм взаимодействия веб-сервера и интерпретатора в одну кучу - мне никак не понять...

Упрощенно: запустите скрипт в режиме демона и обрабатывайте запросы, кто мешает? Туда же подключите свою схему с секретами. Всё? Проблема решена?

Почему никто так не делает? Для этого есть миллиард причин: от порога вхождения до производительности, от легкости деплоя и хот релоада до отсутствия необходимости сертификации приложений...

Для примера, в фреймворках на так любимом вами golang используются похожие принципы. Вот например: https://revel.github.io/manual/appconf.html

И замечу: в этом нет ничего плохого. Нужна повышенная безопасность - реализовывайте, сами языки для этого препятствия не ставят. Но, безопасность повышенного уровня нужна не всем, не всегда и не обязательно именно в таком исполнении.

Собственно, потому вам и объясняют: нет проблем в языке или интерпретаторе.

  Развернуть 1 комментарий

Я понимаю, что нужна не всем
Но тут есть как минимум один, у кого тоже PCI DSS и PHP

  Развернуть 1 комментарий

Я нигде не утверждал, что это никому не нужно. Говорил только об одном: сам язык (и интерпретатор) не имеют дефекта, о котором вы говорите. Необходимо реализовать - не проблема. Это возможно.

  Развернуть 1 комментарий

@aktuba, Проверю. Спасибо.

  Развернуть 1 комментарий

Проверю на неделе

  Развернуть 1 комментарий

@alexander-danilenko,
OFFTOP.

Cам Wordpress тоже не так уж и плох если не ставить 100500 плагинов и какие-то вещи реализовать несколькими строчками кода.
Да, он изначально заточен под блоги и делать на нем что-то другое - не самая лучшая затея. Но при этом можно сделать так чтобы все работало быстро и стабильно. API есть из коробки.

  Развернуть 1 комментарий

@rhamdeew, так про очень многие технологии можно сказать :)

  Развернуть 1 комментарий

@rhamdeew, ну если использование echo() в 4099 местах в ядре вордпресса (текущий мастер бранч) это норма, то я не знаю даже что сказать. У каждого своё представление о прекрасном 🐘

  Развернуть 1 комментарий

@alexander-danilenko, тогда стоит вспомнить про Drupal 7. Он был очень далек от прекрасного. Все проекты которые мне доставались на нем еле шевелились и очень сложно дорабатывались.
Рад что в 8 версии разработчики одумались и перешли на кодовую базу Symfony.

Про Wordpress я и не говорил что он прекрасен, но при желании с ним можно работать и не делать 💩

  Развернуть 1 комментарий

@stansv,

=)

  Развернуть 1 комментарий

@rhamdeew, С технической точки зрения - WP ужасен. С пользовательской - прекрасен.
Ибо позволяет быстро склепать сайт с нужным функционалом.

Я работал в одной компании которая начинала на WP, стала огромным новостником и там WP использовался только для генерации статики в S3, лямбд для экшинов и это все весьма недурно работает.

  Развернуть 1 комментарий

@rhamdeew, Нормально никто никогда не делает. Увы, но кто сделал быстрее - тот и победил.

  Развернуть 1 комментарий

@alexander-danilenko, а что плохого в echo? Особенно, если завернуть его в ob_ функции?

P.S.: не троллинга ради, просто интересно. Мельком глянул результаты поиска (https://github.com/WordPress/WordPress/search?q=echo), увидел 399 использований (а не 4099, как вы указали) и (вроде) большинство - шаблоны или виджеты. Что не так, в данном случае?

  Развернуть 1 комментарий

@aktuba, echo плох тем, что он выводит сразу и нигде его перебить\переопределить\убрать нельзя. используя шаблонизаторы шаблон можно подменить своим или переопределить значение прилетающее в шаблонизатор. в случае с шаблонами всё решается без прямого вторжения в чужой код, который по хорошему надо бы держать нетронутым. трогать чужой код не правильно, потому что любой слепой апдейт ядра\плагина\темы потрет все ручные изменения.

echo грепнул через cd wordpress-master && grep -nro 'echo' .
паста: тыц

  Развернуть 1 комментарий

@alexander-danilenko, хорошие и правильные доводы. вот только это ядро - его в любом случае трогать не надо ;).

Нужен другой шаблон? Ну подключаем. Другой виджет - пишем и подключаем. И т.д.

В общем - я тут (ни в коде, ни в вашем комментарии) не увидел проблемы с echo. Но да, если привязать тот-же twig - наверное получилось бы лучше. Хотя, твиг появился на 5 лет позже wp. И я очень рад, что они додумались не использовать смарти)

  Развернуть 1 комментарий

@aktuba, я прикручивал twig к Wordpress. Ничего сложного в этом нет)

  Развернуть 1 комментарий

Хм... А разве я говорил, что это сложно? При условии, что это в плагине/шаблоне. А вот в ядро затащить - очень сложно ;)

  Развернуть 1 комментарий
Vladimir Hooke, Front-end Developer 1 декабря 2020

Насколько я понял, описанная в посте проблема свойственна всем интерпретируемым языкам в принципе. А почему в заголовке речь идет конкретно о PHP?

  Развернуть 1 комментарий

Так, по 3-му кругу). Скажите плз, что именно «свойственно интерпретируемым языкам»?)

  Развернуть 1 комментарий

@aktuba, ну опять же, это насколько я понял: автор утверждает что поскольку golang компилируется в бинарник, то есть возможность доставать секреты из определенного хранилища всего один раз (во время компиляции). И, мол, даже если вы получите доступ к серверу, то хрен вы из памяти эти секреты выдернете, а больше их нигде нет.

Интерпретатор PHP, напротив, имеет доступ к секретам в любой момент. Так вот вопрос, почему для примера взяли именно пхп? Node.js ведь в той же ситуации?

  Развернуть 1 комментарий

Ну выше это уже обсуждали. И нет, питон и нода чуть иначе работают.

  Развернуть 1 комментарий

@aktuba, а можешь плз в 2 словах объяснить в чем иначе? Или направить почитать по теме 🙂

  Развернуть 1 комментарий

@aktuba, ааа, похоже я напутал и речь идет не о получении секретов во время компиляции, а во время старта приложения. И в таком случае, "пхп работает иначе" имеется в виду старый подход на LAMP стеке, где веб-сервер не часть пхп приложения.

  Развернуть 1 комментарий

@vovahooke,

И, мол, даже если вы получите доступ к серверу, то хрен вы из памяти эти секреты выдернете

ну это если еще и бинарник из файловой системы удалить

  Развернуть 1 комментарий

@vovahooke, да, я именно это и имел в виду.

  Развернуть 1 комментарий

Ну я просто писал на php, а node мало практики

  Развернуть 1 комментарий

@andreyka, можно CVE для «угрозы уровня Zero-Day в интерпретаторе PHP», чтобы понимать о чем конкретно мы говорим?

  Развернуть 1 комментарий
Andrey Rogovsky, Ответственная автор 24 декабря 2020

Я уже вебинар провел и там все рассказал
Есть запись

  Развернуть 1 комментарий

А для тех, кто не видел и не имеет возможности посмотреть запись - можно кратко итог?

  Развернуть 1 комментарий
Andrey Rogovsky, Ответственная автор 24 декабря 2020

В качестве примера такой уязвимости может послужить https://blog.qualys.com/product-tech/2019/10/30/php-remote-code-execution-vulnerability-cve-2019-11043
Но лучше посмотреть запись

  Развернуть 1 комментарий

Запись смотреть не буду - может начать бомбить, судя по нашим прошлым диалогам). А что с попыткой опробовать мои предложения?

  Развернуть 1 комментарий

@aktuba, И напрасно. Стоит понимать, что люди в интернете и IRL коммуницируют по-разному.
Предложения хорошие, но еще не прошли полной проверки.

  Развернуть 1 комментарий

@andreyka, прочитал представленный материал, но не понял где тут Zero-Day, да ещё и в интерпретаторе. Тут уязвимости год, на наших LTS-системах она не актуальна, кроме того, она не в интерпретаторе, а в модуле php-fpm (сервер FastCGI).

  Развернуть 1 комментарий

@bolknote, Zero-Day был до того, как эту уязвимость нашли - ее эксплуатировали и делали ботнеты.
А php-fm это один из режимов реализаци PHP с протоколом CGI.

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@bolknote, Если есть опыт работы с C и желание помочь - обращайтесь, сейчас делаю воркараунд

  Развернуть 1 комментарий

@andreyka, так баг исправлен давно: https://bugs.php.net/bug.php?id=78599

  Развернуть 1 комментарий

@bolknote, Этот - да. А сколько их еще? Неизвестно! Вот от неизвестных багов и надо защищаться.

  Развернуть 1 комментарий

@andreyka, вы это переизобретаете? https://www.hardened-php.net/ или taint?

  Развернуть 1 комментарий

@bolknote, Нет, у меня чисто инжинерное решение на уровне инфраструктуры.

  Развернуть 1 комментарий
Максим Коновалов, Программирую на PHP 24 декабря 2020

Кому нужны хакеры в 2020м когда вся инфа стоит какие-то копейки.
Коррупция победила хаккеров.

  Развернуть 1 комментарий

@MaximKonovalov, Ну например, из последнего SolarWinds.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб