Почему я не люблю PHP

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

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

    Смотрите - каждый раз, когда вы обращаетесь к своему коду через веб-интерфейс, вы запускаете интерпретатор, который считывает все файлы и формирует ответ. В том числе и файл, где вы так заботливо указали доступы к своей базе данных. И не спешите шифровать его - ведь ключ для расшифровки вам тоже надо где-то брать, верно?

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

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

    И не беда, если у вам там обычный блог или сайт-визитка. А если интернет-магазин? А если финансовое приложение?

    Только не говорите, что в финтехе нет PHP. Есть. Я лично видел.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 121

      +31
      А причем тут php? В других языках что нет уязвимости в древних версиях? Или они не считывают файлы в том числе с конфигами при выполнении? И то что ты не позаботился хотя-бы о выносе критичных конфигов в переменные окружения это уж ты сам себе злобный буратино. Я уж не говорю что эти конфиги должны быть за пределами рабочей папки твоего вебсервера.
        –53
        Спасибо, теперь я вижу средний уровень понимания аудитории хабра.
          +32
          Нет, это МЫ видим твой уровень понимания
            0

            Тут все готовы дискутировать, тебе вполне цивилизованно задали вопрос

            +8
            И то что ты не позаботился хотя-бы о выносе критичных конфигов в переменные окружения это уж ты сам себе злобный буратино.

            Это никак не поможет. Если злоумышленник может выполнять свой PHP-код на сервере, он сможет прочесть переменные окружения.


            Почему тут каждый второй пишет про переменные окружения? Это неудобный способ хранить конфиги. Его придумали не для безопасности, а для поддержки хостингов, где используется read-only файловая система, и контейнерных систем вроде докера.


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


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


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


            Я не вижу плюсов у переменных окружения. Дурацкая идея, которую все слепо используют, не взвешивая плюсы и минусы.

              –1
              > кстати, название файла .env тоже выбрано максимально по-дурацки: с точки в линуксе начинаются скрытые файлы
              Это не баг, это фича: веб-сервер даже при неправильной настройке скрытые файлы не отдаст в веб.

              А вообще, нужно помнить, что конфиги конфигам рознь. Например, у нас на несколько серверов развернуто приложение. При этом начальная конфига (хост, логин, пароль к бд) задается именно через параметры запуска в сервисе, так очень удобно деплоить — кодовая база собирается без изменений, а стандартная конфига лежит частично в бд, частично в файле свойств. Кроме того, продакшн значения начальной конфиги не утекут случайно при неосторожном коммите (было у меня такое когда-то давно: чтобы протестить локально, внес в файл данные от пре-прода, и забыл)

              И в целом, наверное, «переменные окружения» следует понимать как «внешняя конфига»: это как и сами environment variables, так и файл в $USER_HOME, так и какой-нибудь, простихосподи, jndi.

              Так что, золотое правило здесь «не хранить все яйца в одной корзине»
                +1
                веб-сервер даже при неправильной настройке скрытые файлы не отдаст в веб.
                Не совсем так: при правильном урле отдаст за милую душу, но при генерации autoindex'а действительно их не покажет.
                0

                Попробуйте например так: https://frederic-hemberger.de/notes/kubernetes/manage-secrets-with-sops/


                • Переменные хранятся рядом с кодом, версионирование через git
                • Файл зашифрован, потеря исходников не грозит потерей секретов
                • Валидация в пайплайне если хотите
                  0

                  Наличие конфига ничем не противоречит переменным среды.
                  Никто же не запрещает держать только необходмые значения, типа доступов к базе данных или JWT secret-а, в vault, и подгружать в конфиг из env, а остальное хранить напрямую в конфиге.


                  А read only файловая система и контейнеры это вообще уже де-факто стандарт. Тут дело не только и не столько в безопасности, сколько в масштабируемости (см. 12 Factor App).

                +34

                А статья где?


                Плюс, такую же ахинею можно написать вообще про любые старые версии и легаси в продакшене.

                  +11

                  Пишите сайты на С++. В нем самая лучшая обратная совместимость со старым кодом, которая есть в 2020. Обновляй конпелятор сколько влезет, да и интерпретатора не будет!


                  //sarcasm

                    +2
                    Конечно не сайты, но достаточно навороченный WEB-интерфейс ко многим серверным приложениям у меня написан на С++ и Ваш сарказм мне не совсем очевиден.
                      +4

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

                    +24
                    Смотрите — каждый раз, когда вы обращаетесь к своему коду через веб-интерфейс, вы запускаете интерпретатор, который считывает все файлы и формирует ответ.

                    Нет, не все.

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

                    Хм… Ну ок. Положили в окружение. При чем тут сам язык?

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

                    А чего не {любой_другой_язык}?

                    Ведь его уже никто не поддерживает, а перейти на новую версию вам мешает отсутствие обратной совместимости.

                    Это какой функционал мешает этому? Что-то не смог вспомнить что-то, что нельзя перенести из 5-ки в 7-ку (да и в 8-ку тоже)…

                    И вот злой хаккер стягивает файл с доступами базы

                    «Стягивает файл»?! Пароли у вас в .txt лежат?

                    В целом — какой-то бред написан.
                      –3

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

                        +3
                        Да писать можно на чём угодно, хоть на 3-м php. Важно понимать риски и отвественность.
                        А что касается шелла — как это относится к языку? Ну представим, что у нас golang и все секреты в переменных окружения. И вот какой-то «злой гений залил шелл» и посмотрел все эти переменные. Снова php виноват?
                          –26
                          8080 порт слушает приложение на golang.
                          Ты заливаешь шелл но не можешь слушать 8080 порт — он занят.
                          HA-HA.

                            +6

                            А 80 порт занят вебсервером. Шах и мат!

                              +7

                              Вывод: веб-шелл — принципиально нерабочее решение, шах и мат, аметисты ;)

                                +2

                                Я так понимаю, товарищ имеет в виду, что 80 и 443 порт уже заняты веб-сервером/прокси/балансировщиком, 8080 порт (на который проксируются 80 и 443) уже занят бэкендом, а все остальное закрыто фаерволом.
                                А PHP-шелл у вас спокойно запустится на тех же 80 и 443.

                              0

                              Но если злой гений залил веб-шелл, то он сможет и прочитать env-ы, нет?

                              +2

                              <сарказм>Ты смеешь оспаривать мнение человека, который Senior Cyber Security Consultant DevSecOps?????????? </сарказм>


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

                                0

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


                                Ну а выпиливание каких-то методов всегда сопровождалось альтернативой и документацией.

                                  0

                                  Новая трактовка обращений типа $foo->$bar['baz'] очень многое поломала. Фиксить можно, но..

                                    +1
                                    Ну за такое вообще руки вырывать надо! Шутка конечно, но с долей правды…
                              +6

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

                                +7
                                дело совсем не в коде, не в пороге вхождения, фреймворках или отсутсвия обратной совместимости

                                а перейти на новую версию вам мешает отсутствие обратной совместимости

                                Так таки дело в этом или нет?
                                  +5
                                  Да я бы не сказал, что у PHP там какие то непреодолимые преграды в обратной совместимости. Лично я очень легко перешел на новую версию. Подозреваю проблема у тех кто использует всякие подключаемые модули и лайфхаки. Ну с лайфхаками они сами себе злобные буратины. Документацию ведь не просто так пишут от скуки.
                                    +3

                                    Проблемы у тех, кто, например, игнорирует deprecated предупреждения.

                                      0

                                      "Ну работает же!"
                                      "Ну это еще когда оно в силу вступит!"
                                      "Позже обязательно пофиксю!"
                                      "Это же ворнинг, а не ошибка!"

                                  +20

                                  Блин, есть миллион причин не любить php, и я даже прочитал этот (кхм...) пост несмотря на минусы предполагая, что они от фанатов php, и надо поддержать автора, но блин… Серьезно?..

                                    +4
                                    Шо це?
                                      0
                                      Похоже, это репост из твиттера.
                                      +14
                                      Заменяем PHP на {любой язык} и получаем тоже самое, к чему статья непонятно или это просто обострение синдрома пятничного репутационного суицида?
                                        +1

                                        #sitnikfriday ж вчера был...

                                          +4

                                          Статья? Больше похоже "пост в соцсеточке"…

                                          +2
                                          По-моему, сейчас чаще всего доступы к базам задаются тоже в PHP-файлах, где инициализируется и заполняется данными некий массив $config. Или не так?
                                          А такой файл обычно веб-сервер не отдаёт плейн-текстом, а только выполняет. То есть, если вы откроете в браузере некий example.com/config.php, вы увидите только пустую страницу.
                                            +1
                                            Совсем не так. Сейчас хорошим тоном является использование переменных окружения. Для разработки же используют .env файл в которые прописывают те же переменные, но со своими значениями. Ну или в yaml файлах хранят конфиги. Но в любом случае эти конфиги будут за пределами папки выставленной в сеть и получить их зайдя на example.com/.env не получится. Хотя это конечно не касется всяких древних cms-ок. Там может быть всё что угодно.
                                              +1
                                              Подскажите, где почитать про переменные окружения и где они задаются при использовании, например, Apache?
                                                +2
                                                  +2
                                                  Про переменные окружения, на мой взгляд, лучше всего объяснять в контексте баша: wiki.merionet.ru/servernye-resheniya/43/peremennye-okruzheniya-v-linux-kak-posmotret-ustanovit-i-sbrosit

                                                  Для апача это будет примерно так
                                                  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 и они подхватятся процессом
                                                    0
                                                    То есть, выходит, хранить пароль от БД в конфиге веб-сервера безопаснее, чем в коде? Вопрос без сарказма или риторики, действительно не изучал этот вопрос.
                                                      0

                                                      При нормальных процессах особо без разницы. При дефолтных настройках или распространённых конфигах для пхп — в конфигах веб-серверов безопасней.

                                                        0
                                                        На мой взгляд настройки в конфиге веб-сервера защищены только от копирования (когда исходники сайта скачиваются). Если есть remote shell, то printenv запустить ничто не помешает.
                                                          0
                                                          Их не обязательно хранить в конфиге веб сервера. Можно зашировать их например. symfony.com/doc/current/configuration/secrets.html
                                                            0
                                                            ну цитата
                                                            The actual value will be resolved at runtime: container compilation and cache warmup don’t need the decryption key.

                                                            говорит нам, что от printenv это не спасет все равно
                                                              0
                                                              Если шелл уже залит в систему тебя ничего не спасёт. Так может стоит защищать не от угона базы при уже залитом шелле, а от возможности заливки шелла на сервер? А то прям хакер и солонка получается.
                                                            0
                                                            в исходниках хранить пароли вообще не есть гуд. Исходники могут попадать разным людям, разработчикам, отправляться для различных анализаторов третьей стороне. Пароли должны храниться либо в специальном сервисе, либо непосредственно на сервере.
                                                            Максимум — в исходниках можно хранить шифрованные пароли, ключ от которых лежать секурно
                                                        +2
                                                        Но в любом случае эти конфиги будут за пределами папки выставленной в сеть

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

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

                                                          +4
                                                          Если упадет, к примеру, стоящий за вебсервером php-fpm — то вебсервер отдаст 500, никаких файлов в текстовом виде клиент не получит.
                                                          Upd: Разумеется, при правильной настройке вебсервера. Но это уже к php не имеет отношения.
                                                            0

                                                            Просто не надо маппить урлы запросов на пхп файлы, доступные веб-серверу.

                                                          +27

                                                          Ругать PHP за "отсутсвие обратной совместимости" — это что-то. Код, написанный десяток лет назад и более, прекрасно запускается или сразу или с минимальными правками. Тут, скорее, надо ругать за слишком ярое присутствие этой самой обратной совместимости...


                                                          Ну а по факту очень странный пост от "Senior Cyber Security Consultant DevSecOps". Переменные окружения отменили? Секреты в Vault? Фреймворки и язык не надо обновлять? Базу наружу открывать — это пять. Дыры в самом PHP не так просто эксплуатировать. Чаще это банальный stored XSS или что-то в этом роде. Понятно что и не такое бывает, но при чём тут PHP?

                                                            –44
                                                            Вы не понимаете азов безопасности
                                                              +10

                                                              Ждем статью, раскрывающую эту тему!

                                                                +2

                                                                А как правильно-то? Нет, серьезно. Вы говорите, что читать конфигурацию из файла это плохо, а как правильно?

                                                                  +4
                                                                  Ну на самом деле автор предлагает (в комментах) довольно адекватное решение — ничего не хранить, использовать все секреты только при старте приложения, а дальше даже в процессах ничего не должно оставаться. Т.е. законнектились к базе и забыли доступы наглухо.

                                                                  Итого:
                                                                  — автор, по каким-то только ему ведомым выводам, считает невозможным такую реализацию на php (тут вроде есть подвижки, посмотрим);
                                                                  — большинство комментаторов не понимают, для чего такое может понадобиться (т.к. никогда не имели дело с сертификацией приложений по разным стандартам безопасности).

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

                                                                Это такой типаж — корпоративный безопасник. Ничего не знает и не умеет, нахватался по верхам, зато умеет произвести умными словами впечатление перед руководством. Всем рассказывает, что никто не разбирается в безопасности, в полном соответствии с принципом Даннинга-Крюгера. Занимается бессмысленной деятельностью типа установки антивирусов на линукс-серверах.

                                                                  +1

                                                                  Напомнило


                                                                +11

                                                                “Ведь его уже никто не поддерживает”
                                                                Вас кто то обидел с поддержкой вашего проекта?
                                                                Вас бросили и ушли от вас?


                                                                Иначе я не понимаю, почему вы решили что если у ВАС все плохо то и у ДРУГИХ все так же!

                                                                  +24

                                                                  В очередной раз убеждаюсь, что корпоративные консультанты знают о современной разработке на php чуть менее, чем ничего. Мифы и ужасы нашего городка, часть 100500.

                                                                    +6
                                                                    Надо заметить, что поддержка PHP5 закончилась в январе 2019. Ужас какой древний язык.
                                                                      +6
                                                                      Потому что ты не осилил версию 7.х.х? А недавно еще и 8.х.х подтянулась… ты поднажми, почитай документацию, что ли. А то стремновато как-то — 2к20 на дворе, а до сих пор звучат мантры из нулевых.

                                                                      Стыдно должно быть.
                                                                        +7

                                                                        Шедевральный бред на тему о хабрасуциде как не надо писать посты:
                                                                        Где статья? Несколько абзацев эмоций с голословными утверждениями.
                                                                        Утверждения не только не обоснованы, но и опровержены комментариями
                                                                        Если заменить php на любой другой язык, ничего не поменяется.


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


                                                                        Немного г на вентилятор По теме, или что бы написал я (кратко, статью не хочу):
                                                                        Отсутствие многопоточности. Т.е. она есть, но на уровне запросов, контроль потоков минимальный, если не пользоваться спец.расширениями.
                                                                        Да, расширения. И конфиги. И версии. Это минус если нам дают что есть, т.е. какой-нибудь бесплатный хостинг: нельзя быть уверенным, будет у нас данная фича или нет. Поведение рантайма сильно зависит от конфиги, с которым двиг собирался — и зачастую приходится детектить фичи. Кроме джаваскрипта, нет ни одного языка с этим безумием (как кодировки и волшебные кавычки, и т.п.)
                                                                        Мы всё ещё рендеримся как html. Тег ?php всё ещё с нами и поощряет смешивать логику и разметку. Ах да, вид тегов тоже зависит от конфиги.
                                                                        Слабая типизация раскладывает грабли неочевидных неявных приведений типов и хаков навроде сложения числа со строкой и умножения строки на единицу.
                                                                        Многофункциональные массивы, которые одновременно являются и картами, отчего неочевидность поведения ($i=1;$arr[$i] — это обращение ко второму элементу или элементу с ключом 1? А если ключи "а", "1"? А вот надо знать!) И это было бы удобно, но слабая типизация не даёт расслабляться… А порядок определен контекстом (используемой функцией, все вот эти kvsort, kasort)
                                                                        Слабая типизация, опять: это и избыточность внутреннего представления переменных (как объединений), и почти полная невозможность оптимизировать интерпретатор как во многих других языках
                                                                        Слабая типизация опять: универсальность типов приводит не только к избыточности, но и ограниченности
                                                                        Груз легаси со времён 4ой версии с известной чехардой функций и порядком аргументов к ним. Спасибо, начиная с 7ой версии ситуацию значительно исправили
                                                                        Боль с кодировками до сих пор, увы, хоть и mbstring на пенсии.
                                                                        Всё ещё вывод ошибок в стандартный поток по умолчанию (т.е. браузер), и не все функции кидают исключения, а плюются предупреждениями и игнорятся. Тяжёлое легаси, увы.
                                                                        И по-мелочи куча ещё претензий.
                                                                        Есть и плюс: спасибо за префикс доллара перед именем: так избегаем коллизий с ключевыми словами и синтаксис последовательнее.


                                                                        Пока что всё

                                                                          +3
                                                                          Вам бы подсократить список.

                                                                          > как кодировки и волшебные кавычки
                                                                          Забудьте об этом. Magic quotes выпилили в 5.4, кодировка давно utf8.

                                                                          > вид тегов тоже зависит от конфиги
                                                                          Уже нет. Те же short tags уже удалены.

                                                                          > Боль с кодировками до сих пор, увы, хоть и mbstring на пенсии
                                                                          Вот только поведения по умолчанию как при mbstring.func_overload=1 не хватало. Мы же не битрикс разрабатываем.

                                                                          > почти полная невозможность оптимизировать интерпретатор
                                                                          Оставьте это тому, кто занимается оптимизацией. Результативное движение в эту сторону есть в виде того же jit.

                                                                          > зачастую приходится детектить фичи
                                                                          Только не говорите, что вы делаете это вручную. Ещё на этапе установки composer расскажет, чего не хватает. Но если у вас «какой-нибудь бесплатный хостинг», то и проект соответствующего уровня. А значит, наиболее вероятно, хватит того, что предустановлено по умолчанию (в т.ч. апач).

                                                                          > хаков навроде сложения числа со строкой и умножения строки на единицу
                                                                          Не делайте так. Меньше хаков — понятнее код.
                                                                          –46
                                                                          Прикольно наблюдать, насколько скатился уровень аудитории прошлого хабра. Люди вообще не понимают причины и несут какую-то ересь.
                                                                          Хабр не торт, с чем и поздравляю администрацию. Так держать — и я никогда не останусь без масла к своему ломтику хлеба :)
                                                                            +9
                                                                            я вижу средний уровень понимания аудитории хабра.
                                                                            Вы не понимаете азов безопасности
                                                                            Прикольно наблюдать, насколько скатился уровень аудитории прошлого хабра. Люди вообще не понимают причины

                                                                            Хватит пустословить. Как написанное на пхп приложение с использованием env переменных ломается на основании САМОГО ЯЗЫКА? Не понятно, вчитываюсь-вчитываюсь в ваше супер-мнение — которое не чета хабровскому, да-да, понял я, но к делу давайте, я не увидел доводов…

                                                                            Хотел бы в Яндекс.Еде и Ламоде заказы на халяву сделать, поломав БД
                                                                            Ну или по старым магазинам и форумам пройтись, чтобы себе др плюсов наделать…
                                                                            Или скажите, ваш профиль поломал кто-то тут на Хабре через эту вашу фатальную уязвимость языка и карму слил кто-то из нас?
                                                                              +5

                                                                              Ну насколько я могу понять, по обрывочным комментариям ТС, в частности про golang выше, основных проблем он видит две:


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

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


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

                                                                                0

                                                                                Ну, скажем так, перезаписать файл может быть всё-таки сложнее, чем положить где-то новый.
                                                                                И в случае с PHP, особенно в древнем легаси, "директория с кодом" будет одновременно являться "директорией с остальным контентом" или лежать очень близко, а для ноды подобное вообще трудно представить.
                                                                                Самая популярная детская ошибка начинающих админов и разработчиков: пользователь может аплоадить файлы, делается это в какую-нибудь сабдиректорию /uploads/, для которой не задано никаких исключений, и все загруженное в нее может быть выполнено интерпретатором.
                                                                                Но это настолько детский сад, что рассуждать о нем нет смысла.


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

                                                                                  +1

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


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


                                                                                  Если в таком случае разработчик умудрился, кхм, обХАкаться, то он это заслужил. Разве что пользователей жалко, если пострадают.

                                                                                    0
                                                                                    Если идет эксплуатация RCE-бага, то не имеет значения, что и куда загружается. Например, эксплуатируем баг Exif-модуля — юзер грузит волшебную картинку и на веб-сервере через несколько секунд стартует вражеский шелл. Далее — дело техники.
                                                                                  +7

                                                                                  Лично у меня ощущение, что автор к проблемам php относит ошибки конфигурации веб-серверов, которые, если не сам допустил, то заапрувил судя по хабпопрофилю.

                                                                                    0
                                                                                    В том что язык интерпретируемый и залив на сервер PHP файл можно легко получить шелл, что сложнее с компилируемыми языками, где залить файл с кодом недостаточно. Надо как-то запустить свой бинарник и дать ему доступ в сеть.
                                                                                    В «нормальных» проектах на PHP уже более 5ти лет применяется паттерн Front Controller с соответствующей конфигурацией Nginx. Запустить записанный пхп-файл «вручную» не выйдет. Необходимо будет сначала считать уже используемый файл и дописать его злоумышленным кодом. Сомневаюсь, что удастся сделать как-либо иначе, не удосужившись узнать хотя бы используемые библиотеки и их версии.

                                                                                    Она правда не интерпретирует заново на каждый запрос, но если уж мы смогли писать в директорию с кодом, то достаточно перезаписать какой-нибудь файл и дождаться перезагрузки сервера
                                                                                    Если уж говорить о потенциальных аналогичных уязвимостях в Go, то что мешает злоумышленнику заинжектить в память процесса свой код и исполнить его? Считаю это подобной «проблемой» относительно вышеописанной о PHP.
                                                                                  +2

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

                                                                                    +2

                                                                                    Нет, он же Senior Cyber Security Consultant DevSecOps как-никак. А вот вы Senior Cyber Security Consultant DevSecOps, чтобы спорить с Senior Cyber Security Consultant DevSecOps?

                                                                                      +3
                                                                                      Ну, вообще-то я Double Senior Cyber Security Consultant DevSecOps, но поскольку Хабр не позволяет написать в этом поле такой длинный текст, то я зовусь просто Пользователь. Вы надеюсь шутите, потому что верить тому, что юзер сам написал в своем профиле — ну это такое…
                                                                                        +1

                                                                                        А я, а я тогда это… Squared Double Long Senior Cyber Security Consultant DevSecOpsWithMoreCamelCasedWords!

                                                                                          0
                                                                                          Знаете, верю!
                                                                                          0

                                                                                          Думаю, обилие сарказма в моем комменте достаточное, чтобы не сомневаться :)

                                                                                          +3

                                                                                          Простая математика: больше громких слов в должности — больше зарплата

                                                                                        +7
                                                                                        Так держать — и я никогда не останусь без масла к своему ломтику хлеба :)

                                                                                        Только не в моей компании.
                                                                                          +2

                                                                                          Расскажите, как понимающий, вы в курсе, что php-скрипты через http выполнить можно в абсолютном большинстве продакшенов исключительно через белые списки в конфигах веб-сервера, к php отношения не имеющих. И ответственны за эти списки именно devsecops или как их там специалисты. Процессы php обычно http-трафик не обрабатывают напрямую, а получают от веб-сервера данные http запроса и путь к php файлу, если веб-сервер решит, что этот запрос попадает в белый список запросов и должен обрабатываться php.

                                                                                          +7

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

                                                                                            +6

                                                                                            У нас есть страница с некими обучающими материалами, написанная на питоне (flask если не ошибаюсь), так если к адресу добавить суффикс /edit/, то она открывается на редактирование :)
                                                                                            Поэтому я Питон тоже не люблю, а ещё там принудительное форматирование.

                                                                                              0

                                                                                              Возможно, именно синтаксис php нанёс этим людям психологическую травму.

                                                                                                0

                                                                                                Можно устроить шоковую терапию брейнфаком

                                                                                                +3
                                                                                                >а потом винят язык
                                                                                                Именно так. Причем в таком тоне, что «Я Д'Артаньян, а вы все ничего не понимаете в безопасности». А на самом деле налажать в любом языке можно точно так же. Условно — настроить апач (или nginx, или томкат, или что там у нас бывает, да даже и свое приложение) таким образом, чтобы по http отдавались файлы настроек, где лежат пароли в открытом виде. И это конечно же проблема апача, что его так криво настроили.
                                                                                                +1

                                                                                                Кажется обратная совместимость вполне себе есть, за Тоти минусуют видимо

                                                                                                  +1

                                                                                                  Я так понимаю, основной наброс топик стартера в том, что почти любой файл, каким-то образом закинутый злоумышленником в диру с другими php-файлами вашего сайта через какую-то дыру, при обращении к нему будет выполнен веб-сервером. Что даёт возможность легко поднять веб-шелл, читать или инклудить в себя лежащие по соседству файлы, читать env'ы, цепляться к базе с теми же правами, и т.д.
                                                                                                  Правда, все это вполне себе легко прикрывается. Например, ограничением точек входа в веб-приложение (whitelist либо рерайты), настроенным мониторингом содержимого директории, и т.д.

                                                                                                    +3

                                                                                                    Разграничение прав тоже давно придумано, жаль что редко используется. За это нужно возненавидеть Linux.

                                                                                                      +1

                                                                                                      Кажется, что автор не понимает, что чтобы выполнить через http тот же шелл залитый куда-то надо явно указать веб-серверу, вообще к php отношения не имеющего, что команду на запуск этого шелла нужно передать php интерпретатору. И подобные уязвимости — это, чаще всего, ошибки конфигурирования веб-сервера лицами, ответственными за размещение и безопасность.

                                                                                                        0

                                                                                                        Ну о том и речь, что если у апача включен и дефолтно настроен mod_php, или в nginx прописан proxy_pass на fastcgi для *.php, или ещё что подобное, то веб-серверу не надо дополнительно объяснять, что он должен запустить интерпретатор, который запустит веб-шелл, достаточно просто сделать запрос на соответствующий URL.

                                                                                                          +3

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

                                                                                                        +1

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

                                                                                                        +8

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

                                                                                                          0
                                                                                                          DEL: Не туда написал комментарий.
                                                                                                            0
                                                                                                            Security through obscurity они любят.
                                                                                                            +2

                                                                                                            Мне вот очень интересно, какой язык веб разработки он считает безопасным. Вот чисто л
                                                                                                            Для понимания, на каком он курсе учебного заведения.

                                                                                                              0
                                                                                                              Самый безопасный язык веб-разработки, это тетрадь, ручка и голубиная почта!
                                                                                                              +4
                                                                                                              Смотрите — каждый раз, когда вы обращаетесь к своему коду через веб-интерфейс, вы запускаете интерпретатор, который считывает все файлы и формирует ответ.

                                                                                                              Это давно не так работает. Никакой интерпретатор не запускается, все уже давно запущено. Иначе тормозило бы все ужасно. в apache библиотека php уже загружена в памяти, в nginx-fastcgi тоже.

                                                                                                              В том числе и файл, где вы так заботливо указали доступы к своей базе данных

                                                                                                              Причем тут php? доступы к базе можно указать во внешнем ваулте, их можно зашифровать, доступ к базе может быть доступен исключительно через локалхост. Что за бред?

                                                                                                              И не спешите шифровать его — ведь ключ для расшифровки вам тоже надо где-то брать, верно?

                                                                                                              В любом случае программе нужно получить доступ к базе. И СОВЕРШЕННО не важно это скрипт или откомпилированная программа.

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

                                                                                                              Пример такой уязвимости?

                                                                                                              Ведь его уже никто не поддерживает, а перейти на новую версию вам мешает отсутствие обратной совместимости.

                                                                                                              Хм. В отличие от современных python и java, php гораздо более совместимый. Я — вообще не разработчик на питон, но легко запустил на php 7.2 старый форумный движок с минимальными переделками, которые нагуглил за 5 минут.

                                                                                                              И вот злой хакер стягивает файл с доступами базы

                                                                                                              Каким образом он это делает? Что за уязвимость, которая СРАЗУ дает доступ ко всему содержимому диска? Как можно получить доступ к базе, которая за пределы локалхоста вообще не предоставляет доступ?

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

                                                                                                              пожалуйста, конкретные примеры как именно благодаря версии php 5 можно взломать любой сайт и вытянуть оттуда произвольные файлы?

                                                                                                              И не беда, если у вам там обычный блог или сайт-визитка. А если интернет-магазин? А если финансовое приложение?

                                                                                                              В таких случаях нанимается нормальный secdevops который ЗНАЕТ как работает на самом деле и куда нужно смотреть. А не тупо кричит на версию php.

                                                                                                                0
                                                                                                                Причем тут php? доступы к базе можно указать во внешнем ваулте, их можно зашифровать

                                                                                                                В случае с PHP, особенно в древнем легаси, "директория с кодом" легко может одновременно являться "директорией с остальным контентом" или лежать очень близко. Из-за того, что язык скриптовый, выяснить, откуда берутся реквизиты (файл, названия переменных окружения, и т.д.) гораздо проще, чем дизассемблировать скомпиленный бинарь.


                                                                                                                Пример такой уязвимости?
                                                                                                                Разные были, в том числе и критические: https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/version_id-167754/PHP-PHP-5.6.0.html
                                                                                                                как именно благодаря версии php 5 можно взломать любой сайт и вытянуть оттуда произвольные файлы?

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

                                                                                                                  А если веб-сервер по умолчанию любой путь пытается интерпретировать как путь к бинаринку от корня ФС и его запустить?

                                                                                                                    0

                                                                                                                    Это всё-таки большая редкость, я такое встречал только в древние времена, когда ещё были в ходу обычные CGI.
                                                                                                                    В большинстве других языков обычно бэкенд запускается не веб-сервером, а отдельно средствами системы, а веб-сервер просто проксирует на него запросы.
                                                                                                                    А вот 99% инструкций под настройке Apache+mod_php или nginx+php-fpm сводятся именно к "При обработке запроса по умолчанию запускаем в интерпретаторе всё, что оканчивается на *.php".
                                                                                                                    Впрочем, это проблема и задача администратора серверов. А языки типа PHP просто требуют немного бо́льшего внимания и понимания при подобной настройке — это тот случай, когда подход, выбранный когда-то давно для низкого порога вхождения, в современных реалиях лишь создаёт лишь иллюзию этого самого низкого порога.

                                                                                                                      +3

                                                                                                                      php-fpm я тоже запускаю средствами ОС, может даже на другом сервере, и запросы вида /index.php вернут 404.


                                                                                                                      Но вообще я к тому, что автор, прежде всего, путает проблемы PHP с проблемами конфигурирования веб-сервера по 99% инструкций.

                                                                                                                        0
                                                                                                                        php-fpm я тоже запускаю средствами ОС, может даже на другом сервере, и запросы вида /index.php вернут 404.
                                                                                                                        Вот только как я уже говорил выше, 99% инструкций по настройке nginx+php-fpm или lighttpd+php-fpm по умолчанию предлагают вариант «всё, что оканчивается на *.php, проксируем на бэкенд-интепретатор». То же самое с 99% shared-хостингов. И /index.php вполне себе сработает, если он физически существует.
                                                                                                                          0

                                                                                                                          Так автор же позиционирует себя DevSecOps специалиста. Разве это подразумевает копипаст конфигов из 99% инструкций при необходимости размещения php приложения?

                                                                                                                            0

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

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

                                                                                                                        Какие конкретно «отдельные средства системы»?

                                                                                                                        Это всё-таки большая редкость, я такое встречал только в древние времена, когда ещё были в ходу обычные CGI.

                                                                                                                        С тех пор все стало гораздо сложнее, ведь кроме apache/nginx есть и другие веб-сервера, которые как раз используются — jetty, http библиотека питона, http библиотека nodejs — кучи application серверов, под капотом тоже крутится то apache то еще что-то — все это тоже веб-сервера.
                                                                                                                        Все они требуют настройки и понимания, но зачастую никто их не настраивает вообще, берутся дефолтные настройки и вперед, и в них тоже может быть полно уязвимостей, потому что люди с удивлением вообще узнают что в этих серверах тоже есть дефолтные роуты и возможности.

                                                                                                                        А языки типа PHP просто требуют немного бо́льшего внимания и понимания при подобной настройке

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

                                                                                                                          0
                                                                                                                          Какие конкретно «отдельные средства системы»?
                                                                                                                          Да какие угодно. Например, systemd. Или просто init-script внутри контейнера. Или какая-нибудь наркота типа Consul. Или сервер приложений типа Nginx Unit.
                                                                                                                          Проблема в том, что многие ничего просто не настраивают.
                                                                                                                          Ну о том и речь. Проблема в том, что сеттинг по умолчанию, когда-то придуманный для облегчения порога вхождения, на самом деле в наше непростое время только добавляет требований к квалификации администратора.
                                                                                                                      0
                                                                                                                      >теми же правами, что и само приложение
                                                                                                                      Т.е. например, только на запуск некоторых хранимых процедур? Нуачо, если автору можно предполагать про наше приложение всякую хрень, то почему мы не можем ответить тем же?
                                                                                                                        +1
                                                                                                                        В случае с PHP, особенно в древнем легаси, «директория с кодом» легко может одновременно являться «директорией с остальным контентом» или лежать очень близко.

                                                                                                                        Причем тут версия php? Это проблема конкретного кода. Такое может быть в любом языке любой версии. Опять же, чем остальной контент мешает вам жить?

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

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

                                                                                                                        Разные были, в том числе и критические:

                                                                                                                        Это просто список уязвимостей языка. Такие есть для каждого языка программирования. Вы не привели конкретный пример, который бы показывал уязвимость скриптового языка. А если посмотреть на список, то видно что основные уязвимости — уязвимости в конкретных функциях/библиотеках. То есть не отличается ничем от любого другого языка, с функциями и библиотеками.

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

                                                                                                                        Если веб-сервер настроен криво, то он легко может запустить любой бинарник/скрипт/удаленный код. Уязвимость веб сервера тут никоим образом к языку отношения не имеет. Тем более, что «веб-приложение отдельно» это как? В любом веб-приложении есть веб-сервер, и он должен быть настроен не криво.

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

                                                                                                                        Потрудитесь привести пример, чем ВОЗМОЖНОСТЬ ЗАПУСТИТЬ НА СЕРВЕРЕ ПРОИЗВОЛЬНЫЙ КОД разнится между тем, что я использую скриптовый или компилируемый или байт-код? Ведь объективно ничем.

                                                                                                                        Итого, пока я не вижу ни одного аргумента, что дело именно в php
                                                                                                                          +2

                                                                                                                          Так, давайте проясним ситуацию. Я не считаю, что PHP плохой язык и что у него есть проблемы с безопасностью. Я просто пытаюсь распарсить и перевести на человеческий то, что написал автор публикации. Он, судя по всему, от души насмотрелся на дефолтные конфиги, поставляемые во многих пакетах, разные древние legacy-проекты на PHP и настройки shared-хостингов, и рассуждает именно в этом сеттинге, и именно в этом сеттинге нужно воспринимать то что пишу я. И при этом, не надо упускать из виду то, чо всё описанное выше, напрямую относится к используемому языку, ничуть не меньше чем его синтаксис и внутренности.


                                                                                                                          Причем тут версия php?
                                                                                                                          Не причем, под словом legacy я имел в виду саму кодовую базу. И если она написана под старые версии php, весьма вероятно, что сам код, и заложенные в его архитекутуру принципы тоже старые.
                                                                                                                          Такое может быть в любом языке любой версии.
                                                                                                                          Такое сложно представить в NodeJS, например. Положить .js-файлы прямо в ту диру, откуда же отдается статика, это совсем клинический случай. То же самое для Golang, ASP.net, Java (Spring), и многих других языках.
                                                                                                                          Напротив, в огромном количестве старых php-проектов, разных там CMS, e-commerce движков, блог-платформах, форумах, и т.д., практика класть скрипты бэкенда прямо рядом со всем остальным контентом и обращаться к .php-файлам напрямую применяется практически повсеместно.
                                                                                                                          Простите, вы храните конфиги или реквизиты прямо в бинарнике?
                                                                                                                          Я — нет. Но хранить конфиги и реквизиты в каком-нибудь config.php и инклудить его везде — очень частая практика в PHP-проектах с давней историей, которые не переписывались под современные практики.
                                                                                                                          получил доступ не хакер а школьник, который не умеет в дизассемблер, то именно разница между скриптом и бинарником является мерой безопасности?
                                                                                                                          В том числе да. Не надо списывать скрипткиддисов со счетов. Ну и даже в случае с квалифицированным взломщиком, имеет место экономия времени и сил этого самого взломщика.
                                                                                                                          А если посмотреть на список, то видно что основные уязвимости — уязвимости в конкретных функциях/библиотеках. То есть не отличается ничем от любого другого языка, с функциями и библиотеками.
                                                                                                                          Отличаются и очень сильно просто легкостью в эксплуатации. Если через RCE вы можете читать память — это будет одинаково, да. Если же чтение памяти «в лоб» ни к чему не приводит или затягивается слишком надолго, но у вас есть возможность создавать файлы с правами веб-сервера — то см. выше про классические конфиги, howto и shared-хостинги с «исполнением всего, что лежит в рут-дире и имеет расширение .php». И вот тут есть разница, т.к.
                                                                                                                          В любом веб-приложении есть веб-сервер, и он должен быть настроен не криво.
                                                                                                                          … стандартный http-сервер NodeJS, ровно как и всякие там express, что стандартный веб-сервер в Golang, не будут по умолчанию исполнять первый попавшийся бинарник, на который укажет URL. Там это надо специально явно и осознанно закодить, причем не двумя строчками кода.
                                                                                                                          Поэтому
                                                                                                                          Уязвимость веб сервера тут никоим образом к языку отношения не имеет.
                                                                                                                          К языку имеют отношение дефолтные конфигурации и описанные в очень большом количестве источников рекомендации по настройке этих конфигураций и окружения. См. тот же mod_php, например.
                                                                                                                          Потрудитесь привести пример, чем ВОЗМОЖНОСТЬ ЗАПУСТИТЬ НА СЕРВЕРЕ ПРОИЗВОЛЬНЫЙ КОД разнится между тем, что я использую скриптовый или компилируемый или байт-код?
                                                                                                                          Ну, со скриптовыми языками все-таки чуть проще: если вы уже получили возможность закинуть на сервер файл, не надо угадывать ОС и архитектуру машины, на которой крутится бэкенд чтобы запустить там шелл, что снижает требования к квалификации злоумышленника. Но это на самом деле фигня, основная разница не сколько в скриптовости или не-скриптовости языка, а как я уже сказал выше, в практике «запускаем все что просят» в случае многих дефолтных конфигураций.
                                                                                                                          Итого, пока я не вижу ни одного аргумента, что дело именно в php
                                                                                                                          Ну это и не удивительно.
                                                                                                                            0

                                                                                                                            Вы же сами пишите, что дело не в php, а в конфигах апача или nginx, которые кто-то, вроде автора, ответственный за размещение и безопасность, явно настраивает на исполнение любого php файла. Банальный белый список файлов в конфиге вместо *.php закроет возможность исполнения залитого в папку uploads шелла

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

                                                                                                                              Язык неплохой, а проблемы с безопасностью у него действительно есть, странно, что Вы их не замечаете. Как у самого PHP(точнее, у его модулей), так и множества продуктов на нем написанных весьма разнообразного качества — Drupal, Jumla, Wordpress и т.д. Впрочем, если разработчики грамотные, то риск по безопасности там не выше, чем у тех же nodejs/java/ruby/python. Опять же, грамотный админ может так настроить окружение PHP(конфиги, web-firewall, IDS), что риски будут невысоки, но нужно постоянно мониторить CVE.
                                                                                                                        +4
                                                                                                                        а где анализ? где варианты решения проблемы? где обзор уязвимостей последних версий?
                                                                                                                        пост для срача?
                                                                                                                          +2
                                                                                                                          пост для обмазывания автора
                                                                                                                            0
                                                                                                                            Это пятничный хабрасуицид автора)
                                                                                                                            +3

                                                                                                                            /dev/null

                                                                                                                              0

                                                                                                                              Всем оставаться на своих местах! Это же троллинг! Очень толстый!!!

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

                                                                                                                                  Only users with full accounts can post comments. Log in, please.