Комментарии 122
И то что ты не позаботился хотя-бы о выносе критичных конфигов в переменные окружения это уж ты сам себе злобный буратино.
Это никак не поможет. Если злоумышленник может выполнять свой PHP-код на сервере, он сможет прочесть переменные окружения.
Почему тут каждый второй пишет про переменные окружения? Это неудобный способ хранить конфиги. Его придумали не для безопасности, а для поддержки хостингов, где используется read-only файловая система, и контейнерных систем вроде докера.
Иметь обычный конфиг-файл гораздо удобнее, чем в неудобной админке хостинга вбивать руками переменные окружения (особенно если у вас их десятки). Конфиг-файл вы можете редактировать любым редактором, версионировать с помощью git. Можете коментировать. Конфиг-файл валидируется и при опечатке в имени параметра выдается ошибка. А вот переменные окружения никто не валидирует, опечатались в названии и это незаметно.
При использовании переменных окружения нужны дополнительные шаги, например, при открытии консоли надо импортировать эти переменные перед выполнением команд. Лишнее неудобство.
Да, я в курсе про env-файлы, но это скорее возврат к конфигам, только извратным способом: вы пишете конфиг, потом он превращается в переменные окружения, потом их парсит приложение. Уж лучше сразу использовать нормальные конфиги. (кстати, название файла .env тоже выбрано максимально по-дурацки: с точки в линуксе начинаются скрытые файлы).
Я не вижу плюсов у переменных окружения. Дурацкая идея, которую все слепо используют, не взвешивая плюсы и минусы.
Это не баг, это фича: веб-сервер даже при неправильной настройке скрытые файлы не отдаст в веб.
А вообще, нужно помнить, что конфиги конфигам рознь. Например, у нас на несколько серверов развернуто приложение. При этом начальная конфига (хост, логин, пароль к бд) задается именно через параметры запуска в сервисе, так очень удобно деплоить — кодовая база собирается без изменений, а стандартная конфига лежит частично в бд, частично в файле свойств. Кроме того, продакшн значения начальной конфиги не утекут случайно при неосторожном коммите (было у меня такое когда-то давно: чтобы протестить локально, внес в файл данные от пре-прода, и забыл)
И в целом, наверное, «переменные окружения» следует понимать как «внешняя конфига»: это как и сами environment variables, так и файл в $USER_HOME, так и какой-нибудь, простихосподи, jndi.
Так что, золотое правило здесь «не хранить все яйца в одной корзине»
Попробуйте например так: https://frederic-hemberger.de/notes/kubernetes/manage-secrets-with-sops/
- Переменные хранятся рядом с кодом, версионирование через git
- Файл зашифрован, потеря исходников не грозит потерей секретов
- Валидация в пайплайне если хотите
Наличие конфига ничем не противоречит переменным среды.
Никто же не запрещает держать только необходмые значения, типа доступов к базе данных или JWT secret-а, в vault, и подгружать в конфиг из env, а остальное хранить напрямую в конфиге.
А read only файловая система и контейнеры это вообще уже де-факто стандарт. Тут дело не только и не столько в безопасности, сколько в масштабируемости (см. 12 Factor App).
А статья где?
Плюс, такую же ахинею можно написать вообще про любые старые версии и легаси в продакшене.
Пишите сайты на С++. В нем самая лучшая обратная совместимость со старым кодом, которая есть в 2020. Обновляй конпелятор сколько влезет, да и интерпретатора не будет!
//sarcasm
Смотрите — каждый раз, когда вы обращаетесь к своему коду через веб-интерфейс, вы запускаете интерпретатор, который считывает все файлы и формирует ответ.
Нет, не все.
В том числе и файл, где вы так заботливо указали доступы к своей базе данных. И не спешите шифровать его — ведь ключ для расшифровки вам тоже надо где-то брать, верно?
Хм… Ну ок. Положили в окружение. При чем тут сам язык?
Я просто уже вижу, как воспользовавшись одной из уязвимостей старых версий, злой хаккер ломает ваше приложение на древнем PHP5.
А чего не {любой_другой_язык}?
Ведь его уже никто не поддерживает, а перейти на новую версию вам мешает отсутствие обратной совместимости.
Это какой функционал мешает этому? Что-то не смог вспомнить что-то, что нельзя перенести из 5-ки в 7-ку (да и в 8-ку тоже)…
И вот злой хаккер стягивает файл с доступами базы
«Стягивает файл»?! Пароли у вас в .txt лежат?
В целом — какой-то бред написан.
Так то если злой гений залил веб-шелл — почему бы и не стянуть любой файл. Да, за это нужно ненавидеть php5, и тех, кто на нём до сих пор пишет.
А что касается шелла — как это относится к языку? Ну представим, что у нас golang и все секреты в переменных окружения. И вот какой-то «злой гений залил шелл» и посмотрел все эти переменные. Снова php виноват?
<сарказм>Ты смеешь оспаривать мнение человека, который Senior Cyber Security Consultant DevSecOps?????????? </сарказм>
Насчет несовместимости пятерки с семеркой, она есть. Те, кто на пятой версии несколько лет к ряду игнорировали ворнинги с депрекейтами, были неприятно удивлены при переходе на семерку. Но тут уж им никто не виноват.
Есть, но их настолько мало и они так быстро фиксятся, что даже стыдно об этом говорить… Для меня самой большой проблемой была смена алгоритма рандомизации на уровне интерпретатора. И даже это относительно легко поправить, если уж критично.
Ну а выпиливание каких-то методов всегда сопровождалось альтернативой и документацией.
А где собственно та самая уязвимость? Я уж думал сейчас будут примеры кода.
дело совсем не в коде, не в пороге вхождения, фреймворках или отсутсвия обратной совместимости
а перейти на новую версию вам мешает отсутствие обратной совместимости
Так таки дело в этом или нет?
Блин, есть миллион причин не любить php, и я даже прочитал этот (кхм...) пост несмотря на минусы предполагая, что они от фанатов php, и надо поддержать автора, но блин… Серьезно?..
А такой файл обычно веб-сервер не отдаёт плейн-текстом, а только выполняет. То есть, если вы откроете в браузере некий example.com/config.php, вы увидите только пустую страницу.
Для апача это будет примерно так
stackoverflow.com/questions/10902433/setting-environment-variables-for-accessing-in-php-when-using-apache
для nginx'а так
stackoverflow.com/questions/8098927/nginx-variables-similar-to-setenv-in-apache
При работе в докере можно просто установить переменные через environment или env_file и они подхватятся процессом
При нормальных процессах особо без разницы. При дефолтных настройках или распространённых конфигах для пхп — в конфигах веб-серверов безопасней.
Максимум — в исходниках можно хранить шифрованные пароли, ключ от которых лежать секурно
Но в любом случае эти конфиги будут за пределами папки выставленной в сеть
Ну у меня так же php файлы с конфигами лежат за пределами папки, выставленной в сеть. Какие проблемы?
Есть нюанс. Если пхп-машина по какой-то неведомой причине упадет, то вебсервер может отдать файл клиенту в текстовом виде. Но если конфиги лежат вне директории, мапящейся на адрес запроса, это уже не будет проблемой.
Ругать PHP за "отсутсвие обратной совместимости" — это что-то. Код, написанный десяток лет назад и более, прекрасно запускается или сразу или с минимальными правками. Тут, скорее, надо ругать за слишком ярое присутствие этой самой обратной совместимости...
Ну а по факту очень странный пост от "Senior Cyber Security Consultant DevSecOps". Переменные окружения отменили? Секреты в Vault? Фреймворки и язык не надо обновлять? Базу наружу открывать — это пять. Дыры в самом PHP не так просто эксплуатировать. Чаще это банальный stored XSS или что-то в этом роде. Понятно что и не такое бывает, но при чём тут PHP?
Ждем статью, раскрывающую эту тему!
А как правильно-то? Нет, серьезно. Вы говорите, что читать конфигурацию из файла это плохо, а как правильно?
Итого:
— автор, по каким-то только ему ведомым выводам, считает невозможным такую реализацию на php (тут вроде есть подвижки, посмотрим);
— большинство комментаторов не понимают, для чего такое может понадобиться (т.к. никогда не имели дело с сертификацией приложений по разным стандартам безопасности).
Ну и как вывод: нет ни проблем, о которых автор утверждал в посте. И нет никакой необходимости, для абсолютного большинства, создавать и поддерживать то, что критично для автора поста.
Это такой типаж — корпоративный безопасник. Ничего не знает и не умеет, нахватался по верхам, зато умеет произвести умными словами впечатление перед руководством. Всем рассказывает, что никто не разбирается в безопасности, в полном соответствии с принципом Даннинга-Крюгера. Занимается бессмысленной деятельностью типа установки антивирусов на линукс-серверах.
“Ведь его уже никто не поддерживает”
Вас кто то обидел с поддержкой вашего проекта?
Вас бросили и ушли от вас?
Иначе я не понимаю, почему вы решили что если у ВАС все плохо то и у ДРУГИХ все так же!
В очередной раз убеждаюсь, что корпоративные консультанты знают о современной разработке на php чуть менее, чем ничего. Мифы и ужасы нашего городка, часть 100500.
Стыдно должно быть.
Шедевральный бред на тему о хабрасуциде как не надо писать посты:
Где статья? Несколько абзацев эмоций с голословными утверждениями.
Утверждения не только не обоснованы, но и опровержены комментариями
Если заменить php на любой другой язык, ничего не поменяется.
По существу: писать плохой код и плохую архитектуру можно на чем угодно, и это не недостаток языка или платформы. За те же особенности можно как любить, так и не любить. Не любите дальше!
Немного г на вентилятор По теме, или что бы написал я (кратко, статью не хочу):
Отсутствие многопоточности. Т.е. она есть, но на уровне запросов, контроль потоков минимальный, если не пользоваться спец.расширениями.
Да, расширения. И конфиги. И версии. Это минус если нам дают что есть, т.е. какой-нибудь бесплатный хостинг: нельзя быть уверенным, будет у нас данная фича или нет. Поведение рантайма сильно зависит от конфиги, с которым двиг собирался — и зачастую приходится детектить фичи. Кроме джаваскрипта, нет ни одного языка с этим безумием (как кодировки и волшебные кавычки, и т.п.)
Мы всё ещё рендеримся как html. Тег ?php всё ещё с нами и поощряет смешивать логику и разметку. Ах да, вид тегов тоже зависит от конфиги.
Слабая типизация раскладывает грабли неочевидных неявных приведений типов и хаков навроде сложения числа со строкой и умножения строки на единицу.
Многофункциональные массивы, которые одновременно являются и картами, отчего неочевидность поведения ($i=1;$arr[$i] — это обращение ко второму элементу или элементу с ключом 1? А если ключи "а", "1"? А вот надо знать!) И это было бы удобно, но слабая типизация не даёт расслабляться… А порядок определен контекстом (используемой функцией, все вот эти kvsort, kasort)
Слабая типизация, опять: это и избыточность внутреннего представления переменных (как объединений), и почти полная невозможность оптимизировать интерпретатор как во многих других языках
Слабая типизация опять: универсальность типов приводит не только к избыточности, но и ограниченности
Груз легаси со времён 4ой версии с известной чехардой функций и порядком аргументов к ним. Спасибо, начиная с 7ой версии ситуацию значительно исправили
Боль с кодировками до сих пор, увы, хоть и mbstring на пенсии.
Всё ещё вывод ошибок в стандартный поток по умолчанию (т.е. браузер), и не все функции кидают исключения, а плюются предупреждениями и игнорятся. Тяжёлое легаси, увы.
И по-мелочи куча ещё претензий.
Есть и плюс: спасибо за префикс доллара перед именем: так избегаем коллизий с ключевыми словами и синтаксис последовательнее.
Пока что всё
> как кодировки и волшебные кавычки
Забудьте об этом. Magic quotes выпилили в 5.4, кодировка давно utf8.
> вид тегов тоже зависит от конфиги
Уже нет. Те же short tags уже удалены.
> Боль с кодировками до сих пор, увы, хоть и mbstring на пенсии
Вот только поведения по умолчанию как при mbstring.func_overload=1 не хватало. Мы же не битрикс разрабатываем.
> почти полная невозможность оптимизировать интерпретатор
Оставьте это тому, кто занимается оптимизацией. Результативное движение в эту сторону есть в виде того же jit.
> зачастую приходится детектить фичи
Только не говорите, что вы делаете это вручную. Ещё на этапе установки composer расскажет, чего не хватает. Но если у вас «какой-нибудь бесплатный хостинг», то и проект соответствующего уровня. А значит, наиболее вероятно, хватит того, что предустановлено по умолчанию (в т.ч. апач).
> хаков навроде сложения числа со строкой и умножения строки на единицу
Не делайте так. Меньше хаков — понятнее код.
Хабр не торт, с чем и поздравляю администрацию. Так держать — и я никогда не останусь без масла к своему ломтику хлеба :)
я вижу средний уровень понимания аудитории хабра.
Вы не понимаете азов безопасности
Прикольно наблюдать, насколько скатился уровень аудитории прошлого хабра. Люди вообще не понимают причины
Хватит пустословить. Как написанное на пхп приложение с использованием env переменных ломается на основании САМОГО ЯЗЫКА? Не понятно, вчитываюсь-вчитываюсь в ваше супер-мнение — которое не чета хабровскому, да-да, понял я, но к делу давайте, я не увидел доводов…
Хотел бы в Яндекс.Еде и Ламоде заказы на халяву сделать, поломав БД
Ну или по старым магазинам и форумам пройтись, чтобы себе др плюсов наделать…
Или скажите, ваш профиль поломал кто-то тут на Хабре через эту вашу фатальную уязвимость языка и карму слил кто-то из нас?
Ну насколько я могу понять, по обрывочным комментариям ТС, в частности про golang выше, основных проблем он видит две:
- В том, что часто используется старая версия PHP видимо имеющая какие-то проблемы с безопасностью (я не в курсе есть ли известные эксплоиты на старые версии)
- В том что язык интерпретируемый и залив на сервер PHP файл можно легко получить шелл, что сложнее с компилируемыми языками, где залить файл с кодом недостаточно. Надо как-то запустить свой бинарник и дать ему доступ в сеть.
Но все равно не понятно. Например нода также является интерпретатором. Она правда не интерпретирует заново на каждый запрос, но если уж мы смогли писать в директорию с кодом, то достаточно перезаписать какой-нибудь файл и дождаться перезагрузки сервера. Правда не уверен будет ли это работать в докере например.
В любом случае в статье огромное количество допущений и "подразумеваемых по умолчанию" вещей которые автор не раскрывает. Поэтому понять полноценно что он имеет ввиду невозможно. А раскрывать они их не хочет потому что по его мнению средний уровень знаний настолько низок, что нет смысла даже пытаться объяснить. Ну я так понял.
Нативный механизм загрузки файлов в php уже давно это побеждает, апплоадя файлы во временную папку под левым именем, лишь после этого предлагая сохранить файл куда надо с указанием нового имени.
Помогает бороться с необработанными загрузками и явно заставляет разраба обращать внимание на то, что куда и как кладется.
Если в таком случае разработчик умудрился, кхм, обХАкаться, то он это заслужил. Разве что пользователей жалко, если пострадают.
Лично у меня ощущение, что автор к проблемам php относит ошибки конфигурации веб-серверов, которые, если не сам допустил, то заапрувил судя по хабпопрофилю.
В том что язык интерпретируемый и залив на сервер PHP файл можно легко получить шелл, что сложнее с компилируемыми языками, где залить файл с кодом недостаточно. Надо как-то запустить свой бинарник и дать ему доступ в сеть.В «нормальных» проектах на PHP уже более 5ти лет применяется паттерн Front Controller с соответствующей конфигурацией Nginx. Запустить записанный пхп-файл «вручную» не выйдет. Необходимо будет сначала считать уже используемый файл и дописать его злоумышленным кодом. Сомневаюсь, что удастся сделать как-либо иначе, не удосужившись узнать хотя бы используемые библиотеки и их версии.
Она правда не интерпретирует заново на каждый запрос, но если уж мы смогли писать в директорию с кодом, то достаточно перезаписать какой-нибудь файл и дождаться перезагрузки сервераЕсли уж говорить о потенциальных аналогичных уязвимостях в Go, то что мешает злоумышленнику заинжектить в память процесса свой код и исполнить его? Считаю это подобной «проблемой» относительно вышеописанной о PHP.
Нет, он же Senior Cyber Security Consultant DevSecOps как-никак. А вот вы Senior Cyber Security Consultant DevSecOps, чтобы спорить с Senior Cyber Security Consultant DevSecOps?
Простая математика: больше громких слов в должности — больше зарплата
Так держать — и я никогда не останусь без масла к своему ломтику хлеба :)
Только не в моей компании.
Расскажите, как понимающий, вы в курсе, что php-скрипты через http выполнить можно в абсолютном большинстве продакшенов исключительно через белые списки в конфигах веб-сервера, к php отношения не имеющих. И ответственны за эти списки именно devsecops или как их там специалисты. Процессы php обычно http-трафик не обрабатывают напрямую, а получают от веб-сервера данные http запроса и путь к php файлу, если веб-сервер решит, что этот запрос попадает в белый список запросов и должен обрабатываться php.
Я не люблю PHP потому что ответственные за размещение и безопасность люди выпускают в продакшен древние версии, предоставляя через http доступ к файлам с паролями к базам на публичных IP без ограничений по IP клиентов, а потом винят язык.
У нас есть страница с некими обучающими материалами, написанная на питоне (flask если не ошибаюсь), так если к адресу добавить суффикс /edit/, то она открывается на редактирование :)
Поэтому я Питон тоже не люблю, а ещё там принудительное форматирование.
Возможно, именно синтаксис php нанёс этим людям психологическую травму.
Именно так. Причем в таком тоне, что «Я Д'Артаньян, а вы все ничего не понимаете в безопасности». А на самом деле налажать в любом языке можно точно так же. Условно — настроить апач (или nginx, или томкат, или что там у нас бывает, да даже и свое приложение) таким образом, чтобы по http отдавались файлы настроек, где лежат пароли в открытом виде. И это конечно же проблема апача, что его так криво настроили.
Кажется обратная совместимость вполне себе есть, за Тоти минусуют видимо
Разграничение прав тоже давно придумано, жаль что редко используется. За это нужно возненавидеть Linux.
Кажется, что автор не понимает, что чтобы выполнить через http тот же шелл залитый куда-то надо явно указать веб-серверу, вообще к php отношения не имеющего, что команду на запуск этого шелла нужно передать php интерпретатору. И подобные уязвимости — это, чаще всего, ошибки конфигурирования веб-сервера лицами, ответственными за размещение и безопасность.
Наверное, потому что безопасность это комплекс мероприятий, а не просто выбор самого прекрасного языка.
Где пруфы, Билли?
Почему я не люблю безопасников? Они считают, что облалают секретным знанием и по этому могут снисходительно поучать.
Но фактически они живут в своем мирке и ничерта не знают.
Мне вот очень интересно, какой язык веб разработки он считает безопасным. Вот чисто л
Для понимания, на каком он курсе учебного заведения.
Смотрите — каждый раз, когда вы обращаетесь к своему коду через веб-интерфейс, вы запускаете интерпретатор, который считывает все файлы и формирует ответ.
Это давно не так работает. Никакой интерпретатор не запускается, все уже давно запущено. Иначе тормозило бы все ужасно. в apache библиотека php уже загружена в памяти, в nginx-fastcgi тоже.
В том числе и файл, где вы так заботливо указали доступы к своей базе данных
Причем тут php? доступы к базе можно указать во внешнем ваулте, их можно зашифровать, доступ к базе может быть доступен исключительно через локалхост. Что за бред?
И не спешите шифровать его — ведь ключ для расшифровки вам тоже надо где-то брать, верно?
В любом случае программе нужно получить доступ к базе. И СОВЕРШЕННО не важно это скрипт или откомпилированная программа.
Я просто уже вижу, как воспользовавшись одной из уязвимостей старых версий, злой хаккер ломает ваше приложение на древнем PHP5.
Пример такой уязвимости?
Ведь его уже никто не поддерживает, а перейти на новую версию вам мешает отсутствие обратной совместимости.
Хм. В отличие от современных python и java, php гораздо более совместимый. Я — вообще не разработчик на питон, но легко запустил на php 7.2 старый форумный движок с минимальными переделками, которые нагуглил за 5 минут.
И вот злой хакер стягивает файл с доступами базы
Каким образом он это делает? Что за уязвимость, которая СРАЗУ дает доступ ко всему содержимому диска? Как можно получить доступ к базе, которая за пределы локалхоста вообще не предоставляет доступ?
радостно читает и ухмыляясь, запускает на выполнение запрос, который вытягивает ваш дам с базы и покорно отдает его злодею на растерзание.
пожалуйста, конкретные примеры как именно благодаря версии php 5 можно взломать любой сайт и вытянуть оттуда произвольные файлы?
И не беда, если у вам там обычный блог или сайт-визитка. А если интернет-магазин? А если финансовое приложение?
В таких случаях нанимается нормальный secdevops который ЗНАЕТ как работает на самом деле и куда нужно смотреть. А не тупо кричит на версию php.
Если у вас веб-сервер по умолчанию передает интерпретатору любой скрипт, лежащий в дире со скриптами, то запустить произвольный код может оказаться ощутимо проще, чем когда нам нужно запускать веб-приложение отдельно.
А если веб-сервер по умолчанию любой путь пытается интерпретировать как путь к бинаринку от корня ФС и его запустить?
php-fpm я тоже запускаю средствами ОС, может даже на другом сервере, и запросы вида /index.php вернут 404.
Но вообще я к тому, что автор, прежде всего, путает проблемы PHP с проблемами конфигурирования веб-сервера по 99% инструкций.
В большинстве других языков обычно бэкенд запускается не веб-сервером, а отдельно средствами системы, а веб-сервер просто проксирует на него запросы.
Какие конкретно «отдельные средства системы»?
Это всё-таки большая редкость, я такое встречал только в древние времена, когда ещё были в ходу обычные CGI.
С тех пор все стало гораздо сложнее, ведь кроме apache/nginx есть и другие веб-сервера, которые как раз используются — jetty, http библиотека питона, http библиотека nodejs — кучи application серверов, под капотом тоже крутится то apache то еще что-то — все это тоже веб-сервера.
Все они требуют настройки и понимания, но зачастую никто их не настраивает вообще, берутся дефолтные настройки и вперед, и в них тоже может быть полно уязвимостей, потому что люди с удивлением вообще узнают что в этих серверах тоже есть дефолтные роуты и возможности.
А языки типа PHP просто требуют немного бо́льшего внимания и понимания при подобной настройке
нет, одинаково. Сейчас под любой вкус есть преднастроенные и сервера и хостинги и контейнеры — все как везде.
Проблема в том, что многие ничего просто не настраивают.
Т.е. например, только на запуск некоторых хранимых процедур? Нуачо, если автору можно предполагать про наше приложение всякую хрень, то почему мы не можем ответить тем же?
В случае с PHP, особенно в древнем легаси, «директория с кодом» легко может одновременно являться «директорией с остальным контентом» или лежать очень близко.
Причем тут версия php? Это проблема конкретного кода. Такое может быть в любом языке любой версии. Опять же, чем остальной контент мешает вам жить?
Из-за того, что язык скриптовый, выяснить, откуда берутся реквизиты (файл, названия переменных окружения, и т.д.) гораздо проще, чем дизассемблировать скомпиленный бинарь.
Простите, вы храните конфиги или реквизиты прямо в бинарнике? Или вы не знаете, как посмотреть переменные окружения, если это не скрипт? Или вы считаете, что если к боевому серверу с критичными данными, получил доступ не хакер а школьник, который не умеет в дизассемблер, то именно разница между скриптом и бинарником является мерой безопасности?
Разные были, в том числе и критические:
Это просто список уязвимостей языка. Такие есть для каждого языка программирования. Вы не привели конкретный пример, который бы показывал уязвимость скриптового языка. А если посмотреть на список, то видно что основные уязвимости — уязвимости в конкретных функциях/библиотеках. То есть не отличается ничем от любого другого языка, с функциями и библиотеками.
Если у вас веб-сервер по умолчанию передает интерпретатору любой скрипт, лежащий в дире со скриптами, то запустить произвольный код может оказаться ощутимо проще, чем когда нам нужно запускать веб-приложение отдельно.
Если веб-сервер настроен криво, то он легко может запустить любой бинарник/скрипт/удаленный код. Уязвимость веб сервера тут никоим образом к языку отношения не имеет. Тем более, что «веб-приложение отдельно» это как? В любом веб-приложении есть веб-сервер, и он должен быть настроен не криво.
Если у вас есть возможность запустить на сервере произвольный код и есть реквизиты доступа к базе, то вы получите доступ к базе м теми же правами, что и само приложение. Да, через локалхост.
Потрудитесь привести пример, чем ВОЗМОЖНОСТЬ ЗАПУСТИТЬ НА СЕРВЕРЕ ПРОИЗВОЛЬНЫЙ КОД разнится между тем, что я использую скриптовый или компилируемый или байт-код? Ведь объективно ничем.
Итого, пока я не вижу ни одного аргумента, что дело именно в php
Вы же сами пишите, что дело не в php, а в конфигах апача или nginx, которые кто-то, вроде автора, ответственный за размещение и безопасность, явно настраивает на исполнение любого php файла. Банальный белый список файлов в конфиге вместо *.php закроет возможность исполнения залитого в папку uploads шелла
Я не считаю, что PHP плохой язык и что у него есть проблемы с безопасностью.
Язык неплохой, а проблемы с безопасностью у него действительно есть, странно, что Вы их не замечаете. Как у самого PHP(точнее, у его модулей), так и множества продуктов на нем написанных весьма разнообразного качества — Drupal, Jumla, Wordpress и т.д. Впрочем, если разработчики грамотные, то риск по безопасности там не выше, чем у тех же nodejs/java/ruby/python. Опять же, грамотный админ может так настроить окружение PHP(конфиги, web-firewall, IDS), что риски будут невысоки, но нужно постоянно мониторить CVE.
пост для срача?
/dev/null
Всем оставаться на своих местах! Это же троллинг! Очень толстый!!!
Оказываю консультации в сфере SOX, PCI-DSS, HIPAA, FFIEC, FISMA, NERC-CIP, GDPR и прочих страшных аббревиатур, далеких от простых пользователей.
>страшных аббревиатур, далеких от простых пользователей.
По-моему кто-то держит тут всех за не очень далеких людей. Особенно своих клиентов, думается мне исходя из хода мыслей по теме.
Почему я не люблю PHP