Кто в 2020 все еще имеет дело с PHP? Предложение!
Публичный постКазалось бы - есть куча разных новомодных языков типа Golang. Но PHP все еще уверенно входит в TOP-10, а самым популярным движком для сайтов остается WordPress, который написан на оном PHP.
Мне очень часто приходилось иметь дело с PHP, но не как разработчик, а как DevOps и каждый раз, когда я размещал приложение, в котором все настройки были в открытом виде прописаны в config.php, то содрогался от ужаса, представляя себе хаккера, который взламывает код, считывает креды и сливает себе базу.
Я приглашаю вас на дискуссию по обеспечению безопасности приложений на интерпретаторах, где для примера взят PHP как наиболее популярный.
Будут рассмотрены такие кейсы:
Угроза уровня 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/
В целом, две самые главные проблемы PHP - это его репутация из начала нулевых и версий 4-5.0, когда все мы были юны, свежи и лепили весь этот ваш MVC в один index.php, со всеми конфигами и секретами, и тонна сомнительного легаси, написанного в этом стиле.
В целом, как по мне, сейчас пых стал куда взрослей, обзавёлся добротными фреймворками всех мастей и возможностей, за те самые config.php принято бить тапками, плюс очень большая работа в семёрке над скоростью.
И, подытожив, PHP, имея в себе все средства, чтобы писать правильно и безопасно, так же и позволяет быстренько сделать нестыдный бэк, который будет работать.
P.S. Моя любимая пикча на эту тему 😜
Я работаю, уже 20+ лет, из них лет 15 его хоронят. В последние годы язык движется в правильную сторону, на 8.0 уже почти можно будет нормально писать.
Последнее, что стоит делать в разработке - это гнаться за модой. У голанга есть свои сильные и слабые стороны по сравнению с похапе, есть они и у остальных альтернатив.
Какое это отношение имеет к языку? Это можно на любом языке сделать.
Я не совсем понял вопрос, если честно. Если вопрос о перспективах - я думаю, что этот вопрос решится в ближайшие 5-10 лет и в значительной мере зависит от того, будет ли улучшена поддержка асинхронности (сейчас это всякие либы вокруг генераторов вроде Amp) и многопоточности (современные сборки по умолчанию не потокобезопасны). Уже сделано много шагов в правильном направлении, взять те же FFI и JIT.
6 лет пишу на PHP, брат жив, язык тоже.
Репутация его была сформирована в умах слишком давно и не имеет отношения к современной реальности.
Да, на PHP, пожалуй, легче и быстрее всего написать бэк для новичка. И да, там может куча ошибок и дыр в безопасности.
Но если тот же новичок просто возьмёт фреймворк, ему уже надо будет заморочится чтобы допустить проблемы безопасности.
В остальном язык быстр, распространён, с отличной экосистемой, с кучей специалистов и кучей уже существующего кода.
PHP крутейшая тема
https://twitter.com/levelsio/status/1308145873843560449
(мое небольшое ИМХО основанное на предыдущих постах и комментариях автора)
Любая попытка скрыть пароль от базы данных в случае исполнения случайного кода на вашем сервере злоумышленником обречена на провал. Все, что вы пытаетесь сделать, это обфускация, а не защита. Никому ваш пароль собственно и не нужен будет -- БД скорее всего защищена на сетевом уровне и все равно недоступна извне.
Вы видете проблему там, где ее на самом деле нет.
Злоумышленник не будет пытаться подключиться к БД напрямую чтобы сдампить ее -- зачем? Вместо этого он просто встроит в ваш сервер код, который позволит ему выполнить произвольный запрос. Ваше приложение само выдаст все данные по команде.
Если все-таки ваша база доступна всему интернету, и очень хочется найти именно пароль, то поверьте, хоть где-нибудь в памяти он останется. Как правило, виртуальные машины позволяют снять дамп памяти в отладочных целях, придется только хорошо в нем покопаться. Если даже пароль будет действительно удален, в памяти найдутся ключи сессий, позволяющие восстановить соединение с БД без пароля.
И, как уже дважды сказали, PHP не заставляет вас использовать классический подход с CGI когда каждый запрос исполняется в собственном процессе php. Я полагаю, так сейчас уже не делают.
Т.е. на хабре мало было комментов? Могу, конечно, скопировать оттуда сюда свой-же коммент, но можно уложиться в одну фразу: при кривых руках язык не при чём.
Что-то да, наброс на config.php странный. В любом интерпретируемом языке такое встречается у разных разработчиков. И в JavaScript, и в Python (config.py в pgAdmin, например). Будут так делать или нет зависит от разработчиков, а не от языка. Чисто технически там можно делать и по-другому спокойно.
По теме если, то на PHP не пишу, поэтому сложно оценить, насколько язык плох или хорош. Но у нас в Авито очень много PHP и хотя и есть тренд перехода на Golang, но он далеко не во всех командах и отделах. Кому-то он не зашел и они продолжают писать на PHP :)
Приятно, что ваш пост написан на следующий день после выхода PHP 8.0, который наконец-то решает множество родовых проблем языка и, я надеюсь, позволит ему и дальше развиваться не только как «язык скриптов, на котором написан Вордпресс» (или какая-то другая CMS-как для сайта)
Сам я работаю с PHP с версии 3, вышедшей в 1998 году. Настройки в текстовом файле, на мой взгляд, — это наименьшая из проблем языка была.
config.php просто ж хранят за пределами условной /public директории (aka document_root), выпяченной в интернеты. ну или на худой конец .htaccess можно прикрыться, но это уже такое себе.
Более трудоёмкий вариант — прописать пароли в недрах самой конфигурации php/вебсервера/пользовательских переменных (типа SetEnv в VirtualHosts апача) — тогда всякие mysqli_connect() можно вообще без параметров вызывать, ну или получить пароли через $_ENV
Конечно надо не забывать отключить phpinfo() и вообще применить весь арсенал php hardening какой есть (хоть он и достаточно примитивный, но тем не менее).
Ну а если уж хацкеру удалось читать содержимое файлов из любой директории на сервере, то там проблемы совсем другого класса.
На самом деле автор пригласил нас на вебинар(?) послушать и обсудить(?) как решать проблему доступа к секретам в PHP в рамках необходимости обеспечения безопасности для сертификации PCI/DSS.
Но сделал это так, будто "PHP" плохой, а "бинарник golang" хороший.
Мы тут все на это здорово триггернулись и усторили небольшой бардак.
А автор всего лишь хотел рассказать о безопасности.
вот имею дело с приложением на пхп (со стороны devops), которое приносит очень порядочно денег (pci-dss там, слава богам, нет) - и всем стейкхолдерам АБСОЛЮТНО ПОФИГ на безопасность.
Безопасность приложения на любом языке - это такой театр для торговли угрозами и дележки бюджетов.
Очень понравилась картинка про remoteok.io - с пхп работает один подход: максимизировать и выдоить максимум из проекта, желательно поменьше напрягаясь. Более тут обсуждать нечего :)
P.S. Театр безопасности не уникален для PHP, на других платформах и языках тоже самое. Всегда надо смотреть на выгодоприобретателей, произносящих это слово.
Реальная безопасность работает совсем по-иному.
10 лет работаю с Drupal. Каждый год про него говорят что он отстой, потому что первое, второе, третье и пхп вообще создан чтобы умирать.
Но вот удивительно: ентерпрайзы его всё выбирают и выбирают в качестве источника контента для своих нужд, потому что админку можно построить быстро (и удобно для контент манагера) и контент можно строить как захочешь.
Можно натыкать любой необходимый функционал мышкой, наставив сотню модулей (тем самым забив всю память на сервере при выполнении запроса), а можно сделать то же самое парой (или немного большим кличеством) строчек кода. При умелом обращении друпал, пусть хоть и написан на пхп, но показывает отличную производительность.
Начиная с восьмой версии ядра друпала он построен на компонентах симфони и избавился от коллбек ада. Теперь у разрабов в руках нормальный человеческий ООП, компоненты симфони, композер, отлично задокументированный код ядра, который позволяет не лезть в документацию каждый раз, и все вытекающие из этого плюсы. Как бонус - любой симфонист может запрыгнуть в друпал через пару вечеров с документацией.
Даже если строить на основе друпала сложные гуй приложения на каком нибудь новомодном вуе/реакте, то он очень хорош в качестве бекенда для апи: ставишь модуль который предоставляет доступ к контенту через JSON:API или GraphQL, расставляешь галочками ACL и отдаешь фронтендерам апи ендпоинты на растерзание.
У друпала есть очень прокачаный функционал для контент манагеров: модуль Workflow, который предоставляет прокачаные ревизии контента, аппрувы/реджекты и всякую фигню которой обмазываются контент манагеры в больших компаниях с кучей легал аппрувов на разных уровнях для любой запятой.
Резюмируя: PHP всё хоронят и хоронят уже сколько, лет 15 подряд? PHP - это не только говно-вордпресс, годные продукты на нем все еще есть и они останутся живыми и поддерживаемыми, так как плотно влезли в ентерпрайз сектор на десятки лет вперед.
Насколько я понял, описанная в посте проблема свойственна всем интерпретируемым языкам в принципе. А почему в заголовке речь идет конкретно о PHP?
@andreyka, можно CVE для «угрозы уровня Zero-Day в интерпретаторе PHP», чтобы понимать о чем конкретно мы говорим?
Я уже вебинар провел и там все рассказал
Есть запись
В качестве примера такой уязвимости может послужить https://blog.qualys.com/product-tech/2019/10/30/php-remote-code-execution-vulnerability-cve-2019-11043
Но лучше посмотреть запись
Кому нужны хакеры в 2020м когда вся инфа стоит какие-то копейки.
Коррупция победила хаккеров.