Компания
279,16
рейтинг
7 июня 2012 в 15:03

Разработка → Веб-уязвимости. Невероятное — очевидно

В ходе тестирования на проникновение, аудита безопасности и других работ, выполненных экспертами Positive Technologies в 2010 и 2011 годах, собралась статистика по защищенности более сотни корпоративных веб-приложений. Именно приложений, а не сайтов-визиток. Сайты электронного правительства, системы интернет-банкинга, порталы самообслуживания сотовых операторов — вот далеко не полный список объектов исследования.

Анализ результатов работ помог нам найти ответы на извечные вопросы ИБ:

  • сколько сайтов заражено «зловредами»?
  • какая CMS безопасней — коммерческая, OpenSource, или проще разработать самому?
  • что безопасней — Java, PHP или ASP.NET?
  • выполнить требования стандарта PCI DSS– миф или реальность?

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

Потенциально опасны?

Да! Мы нашли уязвимости во всех проверяемых нами веб-приложениях, при этом две трети ресурсов содержали критические уязвимости. На графике — топ-10 уязвимостей с указанием долей уязвимых сайтов.

image

Кого пожрали вредители

10% сайтов оказались заражены «зловредами». Какие уязвимости этому способствовали? Подозрение падает в первую очередь на выполнение команд ОС, а также на внедрение SQL-кода и некорректные разрешения файловой системы. Инфицированные сайты гораздо чаще содержат эти уязвимости. Для уязвимости «Выполнение команд ОС» разница весьма заметна: почти все зараженные сайты (92%) были уязвимы — в отличие от сайтов без вредоносного кода (21%). В итоге каждый третий сайт с этой уязвимостью оказался заражен вредоносным кодом.



CMS: стоит ли платить за безопасность?

Всем давно хотелось узнать, можно ли использовать CMS с открытым кодом и не стоит ли раскошелиться на коммерческую? или даже разработать самостоятельно? Наше исследование показало, что сайты, построенные на системах собственной разработки, содержат большее количество критических и других распространенных уязвимостей, чем сайты на коммерческих и свободных системах. Плюсом их оказалась, как ни странно, защищенность от малвари: несмотря на множество уязвимостей, они менее подвержены «случайному» взлому в рамках массовой атаки с использованием автоматизированных средств, поскольку никто не возьмется писать эксплойт в надежде «наткнуться» на вашу CMS. Для открытых систем это стало большой проблемой: почти четверть оказались заражены.

Итак, CMS собственной разработки напоминают старое решето и плетутся в хвосте. А что же коммерческие и open-source? Рассматривая самые распространенные и самые опасные уязвимости, приходим к выводу, что различия не так уж и велики. Каждая группа лидирует в своем наборе уязвимостей. Например, уязвимыми для внедрения SQL-кода чаще оказываются коммерческие CMS. Но если вы уверены, что попытки внедрения SQL-кода вам не страшны, — выбирайте коммерческие CMS (у них первое место по защищенности в общем зачете). Выполнение команд ОС, межсайтовое выполнение сценариев (XSS) и внедрение нулевого байта — удел свободных систем. А по уровню устойчивости к обходу каталога и межсайтовой подмене запросов (CSRF) — здесь боевая ничья. Критическая уязвимость «Удаленное включение файлов» была выявлена исключительно на ресурсах с CMS собственной разработки. Ниже представлен график распределения уязвимостей по уровням риска на сайтах с различными типами CMS.



Зрим в корень

Известно, что «дырявость» сайта определяется еще в момент выбора языка. Различия в этом смысле потрясающие: системы на PHP в 81% случаев содержат критические уязвимости, на Java — в 59% случаев, а на ASP.NET — только в 26%.

Кто чего боится? Ресурсов на ASP.NET, уязвимых для обхода каталога, не оказалось вообще! Для выполнения команд ОС были уязвимы только 4%. А вот межсайтовому выполнению сценариев почти в два раза реже прочих подвержены сайты на Java. С небольшим отрывом Java выигрывает у ASP.NET и в чемпионате по защищенности от внедрения SQL-кода, а PHP грустно машет им ручкой (61% уязвимых сайтов — доля почти в три раза выше, чем у конкурентов). Та же история с CSRF: сайты на PHP уязвимы в два раза чаще. Ну а внедрению нулевого байта оказались подвержены и вовсе одни только PHP-сайты.



Куда текут деньги по проводам


Рассмотрев веб-ресурсы финансового сектора, мы пришли к выводу, что ситуация весьма удручающая. Только в 10% случаев владельцам удалось выполнить требования PCI DSS к защите веб-приложений. Хорошо хоть, что переполнения буфера никто не допустил. А вот некорректная обработка ошибок характерна для 76% (!) приложений.

image

В то же время анализ систем дистанционного банковского обслуживания показал, что в них устранены практически все критические уязвимости. Только 1% уязвимостей ДБО связан с высоким уровнем риска.

P.S. Данные собраны в ходе работ по анализу защищенности веб-приложений, проведенных Positive Technologies в 2010—2011 годах. Оценка защищенности проводилась ручным способом методами черного и белого ящика с использованием вспомогательных автоматизированных средств. Для классификации уязвимостей применялась система Web Application Security Consortium Threat Classification (WASC TC v. 2) — за исключением ошибок обработки входных и возвращаемых данных и отказа в обслуживании. Степень критичности уязвимости оценивалась согласно системе Common Vulnerability Scoring System (CVSS v. 2), затем выделялись высокий, средний и низкий уровень риска.

P.P.S. У самых любознательных читателей есть возможность ознакомиться с полной версией отчета.
Автор: @ptsecurity
Positive Technologies
рейтинг 279,16

Комментарии (54)

  • 0
    Занимательно
  • +9
    А Python\Ruby планируете исследовать? Было бы также очень интересно.
    • +2
      Да, в следующей статистике охватим и Python с Ruby.
  • +4
    Весьма любопытные результаты. Особенно «порадовал» PHP. Причины, впрочем, очевидны — «нулевой» порог вхождения и большое количество дилетантов… Но все равно интересно.

    Вопрос к автору — была ли информация о найденных уязвимостях предоставлена производителям/сообществам CMS?
    • +3
      Никогда не понимал про 0-й порог. ASP-шники что, посвящение какое-то проходят?
      • +1
        Нет, все проще.
        Просто попробуйте перечислить, что вам нужно для работы с ASP и прикинуть, где это есть.
        Вы поймете, что в 80% случаях — это относительно крупные компании, как минимум имеющие свои сервера.

        Поясню.
        Я могу ошибиться в цифрах, пусть коллеги поправят, но, наверное, 90% хостеров предлагают только LAMP. А ASP — это почти сплошь корпоративные (зачастую внутренние) проекты компаний. И попасть в такую компанию немного сложнее (тот самы «не нулевой» порог), чем в сайтолепильнуювеб-студию или на фриланс. Так что все просто.
        • 0
          Так это вопрос популярности технологии, а не ее каких-то качеств.
          • +3
            Под термином «нулевой порог вхождения» понимается (кажущаяся) простота начала работы с чем-то. В данном случае — с языком программирования.
            Чтобы начать «программировать» в ПХП вам нужно сделать едва-ли десяток кликов мышкой (Denver). Как-бы даже не пол-десятка.
            А чтобы начать работать с ASP — я даже не помню, сколько тыкать надо. Да еще и знать, куда тыкать… Но это будет точно не десяток тычков…
            Также, существенно снижает порог вхождения наличие и доступность как информации о языке вообще, так и технической информации в частности.
            Про бесплатность LAMP тоже не следует забывать.

            Все перечисленные факторы не только влияют на «популярность» как таковую. Но и позволяют начать «писать на ПХП» людям не имеющим никакой квалификации.
            И зачем я все это написал? Вроде и так все это знают???
            • 0
              Рискну впасть в немилость:
              Помнится лет эдак 6 назад работал с турбо паскалем. Так вот там, чтобы начать кликов необходимо было и того меньше — банально два клика запустить сам ТП и как то там скомпилить прогу.
              Про тот же денвер ещё узнать надо, скачать его, поставить, запустить, настроить локалхост (или оно там по дефолту?)… В турбе, помнится, вставил дискету, сделал два клика и работаешь.
              Всё, паскаль для нубов? =)

              • +3
                Тут можно вспомнить, что изучение программирования (языков программирования) в конце 90х-начале 00х в школах и институтах начиналось с книги Фаронова «Турбо Паскаль». Таки да, паскаль для начинающих)
                • 0
                  Нынче, вроде, рекомендуют питон для начала. До этого мне казалось с бейсика учили.
                  В общем я к тому, что уязвимости — бич популярности, а никак не простоты языка.

                  • –2
                    Python (англ. python — питон, произносится [ˈpaɪθ⟨ə⟩n] ).

                    А теперь произносим: П-а-й-т-о-н. Отличненько. Я зануда.
              • +1
                PHP — достаточно простой язык с большой кучей подводных камней. Об этих камнях редко пишут в книгах на подобие «PHP для чайника», отсюда и появляется много кодеров готовых за 5 минут сделать сайт, в котором будут уязвимости о которых они даже не будут догадываться.
                А ТП тут несколько не к месту :-)
            • 0
              Ну денвер точно слабый аргумент.
              Питон из коробки уже все содержит — Апач ему не нужен, базу можно sqlite брать, если даже в твоей сборке не будет простого фреймворка типа бутылки, то ставится опять таки в два клика…
              Но как-то порог вхождения низким от этого не стал.

              Хотя в целом да, ход мысли верный, согласен :)
        • 0
          Чтобы раскрутить ASP.NET много действий не нужно. Результаты обусловлены еще и нормальными дефолтовыми установками и встроенными механизмами защиты. Большинство контролов имеет экранирование, а ORM защиту от инъекций. Я не уверен, что многие в курсе о том, какую часть работы делает за них платформа, и с 0-вым порогом приложения будут менее дырявые. Написать хреновое приложение на PHP гораздо проще чем на Java и ASP.NET, вот видимо и пишут.
          • 0
            Написать хреновое приложение на PHP гораздо проще чем на Java и ASP.NET, вот видимо и пишут.

            Вы хотели сказать, что гораздо проще на PHP чем на Java и C#/VB/… или на symfony/yii/zend/… чем на Spring MVC или ASP.NET MVC?
    • 0
      Да, разумеется! Мы активно работаем с вендорами ПО.
    • +1
      В любом языке есть «нулевые» «знатоки». Вопрос только, стоит или нет такого нанимать — но это вопрос к заказчикам. Другой вопрос — «цена вхождения» в язык и для разработчика, и для заказчика.

      Тот же PHP, если влиться в команду крупного opensource-проекта, можно неплохо поднять-прокачать. А вот хоститься на .NET, на Ruby, Python, чем-то еще — это сложнее и дороже, поэтому заказчики с ограниченным бюджетом, и понимающие в технологиях (т.е. — хотя бы минимально сравнивающие цены и условия) будут думать о дешевом хостинге — а от него путь приведет к PHP. Ну а предельная экономия даст еще и дешевого, но криворукого (точнее, незнающего и неопытного) новичка в PHP в роли «архитектора проекта», который на этом руку себе, конечно, набьет, но первый-второй-третий проект которого будет не самым лучшим.

      Правда, могу сказать и обратное — когда есть задача заказать сайт, крутость (порой дутая) конторы-разработчика и язык, на котором в ней пишут, роль играет не самую важную. Важно, чтобы люди хотели сделать нечто особенно хорошее, и тратили на это силы и время. А если работа будет «спустя рукава» — так тут никакой язык не спасет :)
  • 0
    Про один 1% среди СДБО как-то «позитивно» 8)
    • 0
      Да мы вообще, самые позитивные))
  • +2
    Тут встает такой интересный вопрос: столь высокая уязвимость сайтов на php связана с тем, что данный язык сам по себе является решетом, или, все — таки, в большей степенью с тем, что программы на нем писались менее квалифицированными разработчиками (в народе — «быдлокодерами»)?
    • +2
      С тем, что разработчики PHP сделали ВСЕ, чтобы неопытные программисты допускали уязвимости…
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Отличное определние PHP!
  • 0
    Подпишите третий график — совсем непонятно про что он
    • 0
      Спасибо. Подправили в тексте, график показывает распределение уязвимостей по уровням риска на сайтах с различными типами CMS
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Ещё одна причина, по-моему — большое количество приложений построенных «с нуля, на „голом“ PHP с использованием сторонних библиотек, максимум, для задач типа отправки почты, логирования и доступа к API. Если шаблонизатор будут использовать, то вообще замечательно. А вот на Java/C#, ставится, наверное, вопрос какой full-stack фреймворк будет использоваться (а с C# может и не ставится вовсе, вроде кроме ASP.NET MVC и не слышал ни об одном), какая ORM и т. п.

      Плюс качество обучающих материлов — многие из них находятся на уровне, утрируя, „вчера написал hello world, сегодня учу вас“. Про архитектуру, тестирование, паттерны и прочие „тру“ вещи вообще молчу.
    • 0
      Не забывайте, что инструменты тоже пишут люди, и их архитектуру, и код. И я не уверен в тех людях (и в их целях), что разрабатывали PHP
    • 0
      Дело именно в языке. PHP был написан человеком, который в своем выступлении у ОРейли признавался, что он не совсем программист, и до сих пор не умеет писать парсеры. Получается, что система типов языка, преобразование типов и разбор выражений ущербны с момента создания языка, и в ней до сих пор есть ошибки вида «Ox0+2=4», которые пока никто не нашел.

      К сожалению, автор языка утверждает " I hate programming with a passion. I like problem solving.", что сразу напоминает «А чо думать? Прыгать надо !».

      А поскольку PHP написан в начале Интернет-эпохи, то сейчас он занял очень большое место в области веб-разработки и все разработчики прыгают как автор языка, даже если не хотят.
  • +1
    Жаль только, что нет статистики по популярным CMS — Битрикс, WordPress, Joomla, Drupal и т. д.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        И какие же выводы можно сделать из Вашего комментария?.. Что соль соленая, а сахар сладкий, я и так давно знаю. Лично меня интересует совершенно другое — статистика уязвимости моих любимых Joomla 1.0.12 и Joomla 1.5 в сравнении с другими CMS.
        • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            А вот за этот комент большое спасибо. Есть над чем задуматься.
        • 0
          Ваша любимая Joomla ужасна даже не сама по себе, а отвратным качеством большинства расширений.
  • 0
    Интересно, было протестировано одинаковое количество приложений на разных зыках? По 41 на язык или разное… Нашел ответ PHP «на нем написаны 63% всех протестированных сайтов» Получается статистика по языкам надумана.
    • 0
      Хотя я не отрицаю что в PHP продуктах возможно наибольшее количество уязвимостей.
      • 0
        сайты, это конкретные приложения, которые используют наши заказчики. Список их естественно привести не сможем, коммерческая тайна, NDA. Что касается процентов, округляли до целого или двух десятичных знаков.

        Разглашение информации — это более чувствительные вещи, например, комментарии разработчиков, трейсы и пути файловой системы в сообщениях об ошибках и прочее.

        Еще раз повторю — это реальные цифры и нам (да и владельцам систем) достаточно трудно (да и не особо нужно) угадывать в чем причина дырявости приложения: в особенностях asp.net или в свойствах «прокладки». Да и наша методика анализа не позволяет это понять, для этого надо влезать в SDL и другие процессы компании.

        Но в целом да, холиварный отчет. Но вот такой он есть.
  • +8
    Желтуха так желтуха!

    «Известно, что «дырявость» сайта определяется еще в момент выбора языка»

    збс.
  • 0
    Средняя температура по больнице — 36,6.

    Интересно взять 10 лучших результатов (сайтов) в каждом языке, 10 худших, может ещё какие срезы делать. Иначе это скорее не количество уязвимостей продуктов на языках, а количество ошибок в ДНК прокладок между креслом и клавиатурой, использующих данные языки.
  • 0
    Хочется попросить авторов этого и других исследований интернета раскрывать чуть-чуть больше подробностей и писать рядом с процентами абсолютные цифры в ключевых моментах.
    Например в приложенном документе
    Пункт 3
    >> В данном разделе приведены наиболее значимые заключения по статистическому анализу уязвимостей, выявленных в 123 веб-приложениях в ходе тестирований

    Веб-приложение — это что? Джумла, Битрикс или конкретный сайт вроде гов.ру или газпром.ру? Можете добавить список этих протестированных веб-приложений?

    >>… на нем написано 63% протестированных ресурсов
    123 * 63% / 100% = 77.49. Что это за полресурса или всё-таки ресурсов (сайтов) было больше? Если больше, то можно узнать количество и список?)

    Пункт 5.4
    >> Во всех случаях лидером стала уязвимость Information Leakage.
    Вот тут тоже хотелось бы узнать. Если сервер в заголовках отдаёт Apache 2.2/PHP 5.4 — это уязвимость? А если GWS?
    Если в тексте страницы виден путь до ресурсов, который начинается с "/bitrix/..." — это уязвимость?
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Посмотрел приложенный документ.
    Зачем вы делали эту «филькину грамоту»? Делать выводы по выборкам 7, 12, 13 элементов это тоже самое что гадать на картах.

    Где погрешности? Где распределение по платформам?
    Каково распределение по платформам внутри индустрий? Каковы ресурсы организаций? (некорректно сравнивать коленочное приложение на PHP против миллионного на сделанного на ASP, если мы говорим именно о платформах, а не конкретных приложениях)

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

    • +1
      Статистика была получена в результате анализа приложений, проводимого на коммерческой основе, поэтому даже если приложение и «коленочное» оно достаточно ценно для заказчика, чтобы инвестировать в его безопасность.

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

      Еще раз напомним, что наше исследование прежде всего практическое, оно показывает как обстоят дела с безопасностью, а не как могли бы быть. Согласитесь телеком компании достаточно все равно, через багу в asp.net модном сайте или унаследованный наколенный php-сайтец были опубликованы смс его клиентов.
      Это реальный мир и реальные риски.
      • 0
        Если ваша статья начинается с тезисов,
        "- какая CMS безопасней — коммерческая, OpenSource, или проще разработать самому?
        — что безопасней — Java, PHP или ASP.NET?"

        то деление по платформам, типам CMS, как бы подразумевается. Нет?

        Под погрешностями имелась ввиду достоверность выводов. С какими допущениями, то что вы написали правда? У вас очень маленькие выборки и значительная экстраполяция если говорить о платформах и типах CMS. Или же я неправильно понял, и пассажи "С небольшим отрывом Java выигрывает у ASP.NET и в чемпионате по защищенности от внедрения SQL-кода, а PHP грустно машет им ручкой (61% уязвимых сайтов — доля почти в три раза выше, чем у конкурентов)." относятся исключительно к проверенным системам и экстраполяций не проводилось?

        В разных индустриях свои требования к защите информации. Поэтому сравнивать банковское решение с гораздо более простыми системами в других областях несколько не корректно.

        Да, я согласен. Телеком компании все равно. Она заказывает отчет о своем сайте и борется за свою безопасность. А нам не все равно, потому что мы пришли в топик узнать результаты исследований, а попали на данные не вызывающие ни доверия. Из вашей статьи нельзя вынести никаких практических выводов. Все графики можно было заменить утверждением — Все плохо, но мы делаем чтоб было лучше.
        • +1
          Ах, вы об этом.
          Детальные данные и выводы см. в оригинале исследования. Этот текст его урезанная интерпретация, сдобренная buzzwords. В оригинале есть информация в том числе и по регулированию, поскольку оно оказывает большое влияние на распределение уязвимостей. Так, благодаря PCI DSS в ДБО практически вычищены XSS и SQLi, но достаточно много логических недочетов связанных со сложными функциями авторизации (одноразовые пароли, sms и проч). Резать по платформам в рамках отрасли на такой выборке не вижу смысла, ибо непонятно к чему это приведет.

          Погрешность и достоверность (простите за педантство) несколько разные понятие, чем и был вызван мой вопрос. Резюмируя, наши данные абсолютно достоверны при заданных начальных условиях, изложенных в полном тексте, а именно:
          — приложения российских компаний из топ 100
          — наиболее бизнес-критичные системы, доступные из Интернет (именно с ними связаны основные риски, именно их и заказывают)
          — Ограничения методики «серого ящика» согласно которой анализировались приложения, и которая (как, к слову и любая) не дает гарантии, что все проблемы были обнаружены

          К сожалению других чисел у нас нет. То, что делает WASC и Whitehat Security менее адекватно, поскольку содержит либо смесь черного и белого ящика (WASC), либо только черный с ручной верификацией (Whitehat).

          Экстраполяции, предсказания и прочая мистика не использовались, только опыт. Что касается практического применения, то многие факты из исследования могут быть использованы в количественных методиках анализа рисков, что, согласитесь, достаточно полезно.
  • +6
    Ну, это как проанализировать количество косяков в Ламборджини и каком-нибудь Форд Фокусе.

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

    На PHP, хочется вам того или нет, написано, по разным оценкам, от 10 до 50% веб-приложений вообще. На Яве тоже очень много, а на довольно привязанном к M$ дотнете (и более молодом) — сильно меньше.

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

    Это, увы, так, хотя и печально. Вот я, к примеру, пишу это с Убунты 11.04. И как бы мне не хотелось считать, что эта система в миллион раз лучше Винды благодаря архитектуре без эти C:\, благодаря пакетному менеджеру, благодаря open-source и миллиону других вещей, это не так.

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

    А знаете почему? Потому что не молоток — еблан, а еблан тот, кто этим молотком бьет себе по пальцу. Язык, или Ось — это только инструмент. И как нет защиты в любом Линуксе против бабы, вводящей свой рут-пароль в прогу «введи рут-пароль и просмотри СМСки мужа», так и нет защиты против говнокодеров, которых за сто выстрелов не то что к программированию — к станку подпускать нельзя.
    • 0
      Конечно, отчасти вы правы. С увеличением популярности среди пользователей, растет и популярность среди вирусописателей. Но эта зависимость не всегда значит то, что «никто не пишет вирусы, потому что не нужно». Возьмите, например, MacOS. Да будет вам известно, что в европе/США большая половина всех предпринимателей, глав корпораций, просто работников различных контор, а так же студентов хороших ВУЗов используют продукцию Apple в качестве десктопов/ноутбуков/нетбуков/планшетных компьютеров. Это продукция достаточно обеспеченной аудитории, часто очень обеспеченной, которые довольно часто платят в интернете, у них могут храниться данные, которые можно использовать против них самих и так далее. Как правило, это более «активные» пользователи, чем домохозяйки с виндой. Прямо-таки рай для вирусов и троянцев, казалось бы. А как обстоит дело на самом деле?
    • +1
      И да, и нет. Просто есть инструменты, более подходящие для решения цели, а есть менее подходящие. У первых как правило возможность стукнуть себе по пальцу минимизирована уже «из коробки». Чтобы эффективно использовать вторые нужно быть экспертом в обхождении подводных камней и знать все нюансы имплементации.
  • +3
    Не хочу обидеть автора, но не понимаю смысла таких статей и исследований, в которых имеет место быть подмена понятий и неправильная установка акцентов. Ведь эти статьи потом находят в интернете люди, понимающие в программировании еще меньше, чем программисты, которые делают уязвимые сайты на PHP.

    Когда потенциальные заказчики проводят собственные «исследования» вопроса, касательно сайтов, они могут найти статью, подобную этой, и сделать вывод, что сайты не нужно делать на PHP, потому что он — говно. Но вы же понимаете, что это проблема никак не языка и не технологии, а исключительно исполнителя по этим конкретным сайтам. Уязвимостей в самом PHP было не так уж и много и не многие из них были критичными по части безопасности. Но прочитав эту статью можно решить, что для безопасности сайта, лучше его делать на Java или APS.NET, тогда не будет уязвимости.

    Вытекает это все в то, что заказчик, собираясь открывать интернет магазин, начинает искать исполнителей, которые выполнят эту работу на технологиях Java/.NET, игнорируя PHP и считая специалистов в этом языке какими-то новичками с дырявыми руками и головами. Т.е., всех. Уровень серьезного отношения к PHP падает с каждым годом, при том, что число заказов растет. Хорошо ли это?

    Это приводит к тому, что сама по себе разработка таких проектов теряет эффективность. И совсем не потому, что на Java/.NET могут программировать только истинные специалисты с сертификатами от microsoft, лично для меня уже давно не существует понятия «сложность языка», потому что программирование везде одинаковое, по сути (если речь не идет о декларативных и функциональных ЯП). А потому, что для конкретного круга задач использовать PHP можно эффективнее, чем в общих равных использовать JSP/ASP. Просто потому, что Java/.NET избыточны для многих задач, количество специалистов с опытом на этих технологиях меньше, а значит поддержка и программное сопровождение проекта будет дороже, не говоря уже о том, что срок разработки на этих технологиях обычно ставится больший, чем в случае PHP, хотя их использование не намного сложнее.

    Уровень «безопасности» тут диктуется только тем, что использование этих платформ накладывает определенные архитектурные ограничения, особенно при использовании фреймворков, которые не позволяют попасться на «новичковые» ошибки. Например, используя ORM вряд ли можно столкнуться с SQL-injection, но это не значит, что используют их программисты «высшей лиги», ведь человек, который всю жизнь работает с базами через интерфейс и ORM может вообще не знать, в чем суть самой ошибки недостаточной фильтрации данных и как это становится уязвимостью на сайте. Как и в managed программах, человек может вообще не знать, что такое переполнение буффера и как оно происходит и по какой причине.

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

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

Самое читаемое Разработка