Comments 54
Занимательно
А Python\Ruby планируете исследовать? Было бы также очень интересно.
Весьма любопытные результаты. Особенно «порадовал» PHP. Причины, впрочем, очевидны — «нулевой» порог вхождения и большое количество дилетантов… Но все равно интересно.
Вопрос к автору — была ли информация о найденных уязвимостях предоставлена производителям/сообществам CMS?
Вопрос к автору — была ли информация о найденных уязвимостях предоставлена производителям/сообществам CMS?
Никогда не понимал про 0-й порог. ASP-шники что, посвящение какое-то проходят?
Нет, все проще.
Просто попробуйте перечислить, что вам нужно для работы с ASP и прикинуть, где это есть.
Вы поймете, что в 80% случаях — это относительно крупные компании, как минимум имеющие свои сервера.
Поясню.
Я могу ошибиться в цифрах, пусть коллеги поправят, но, наверное, 90% хостеров предлагают только LAMP. А ASP — это почти сплошь корпоративные (зачастую внутренние) проекты компаний. И попасть в такую компанию немного сложнее (тот самы «не нулевой» порог), чем всайтолепильнуювеб-студию или на фриланс. Так что все просто.
Просто попробуйте перечислить, что вам нужно для работы с ASP и прикинуть, где это есть.
Вы поймете, что в 80% случаях — это относительно крупные компании, как минимум имеющие свои сервера.
Поясню.
Я могу ошибиться в цифрах, пусть коллеги поправят, но, наверное, 90% хостеров предлагают только LAMP. А ASP — это почти сплошь корпоративные (зачастую внутренние) проекты компаний. И попасть в такую компанию немного сложнее (тот самы «не нулевой» порог), чем в
Так это вопрос популярности технологии, а не ее каких-то качеств.
Под термином «нулевой порог вхождения» понимается (кажущаяся) простота начала работы с чем-то. В данном случае — с языком программирования.
Чтобы начать «программировать» в ПХП вам нужно сделать едва-ли десяток кликов мышкой (Denver). Как-бы даже не пол-десятка.
А чтобы начать работать с ASP — я даже не помню, сколько тыкать надо. Да еще и знать, куда тыкать… Но это будет точно не десяток тычков…
Также, существенно снижает порог вхождения наличие и доступность как информации о языке вообще, так и технической информации в частности.
Про бесплатность LAMP тоже не следует забывать.
Все перечисленные факторы не только влияют на «популярность» как таковую. Но и позволяют начать «писать на ПХП» людям не имеющим никакой квалификации.
И зачем я все это написал? Вроде и так все это знают???
Чтобы начать «программировать» в ПХП вам нужно сделать едва-ли десяток кликов мышкой (Denver). Как-бы даже не пол-десятка.
А чтобы начать работать с ASP — я даже не помню, сколько тыкать надо. Да еще и знать, куда тыкать… Но это будет точно не десяток тычков…
Также, существенно снижает порог вхождения наличие и доступность как информации о языке вообще, так и технической информации в частности.
Про бесплатность LAMP тоже не следует забывать.
Все перечисленные факторы не только влияют на «популярность» как таковую. Но и позволяют начать «писать на ПХП» людям не имеющим никакой квалификации.
Помнится лет эдак 6 назад работал с турбо паскалем. Так вот там, чтобы начать кликов необходимо было и того меньше — банально два клика запустить сам ТП и как то там скомпилить прогу.
Про тот же денвер ещё узнать надо, скачать его, поставить, запустить, настроить локалхост (или оно там по дефолту?)… В турбе, помнится, вставил дискету, сделал два клика и работаешь.
Всё, паскаль для нубов? =)
Тут можно вспомнить, что изучение программирования (языков программирования) в конце 90х-начале 00х в школах и институтах начиналось с книги Фаронова «Турбо Паскаль». Таки да, паскаль для начинающих)
Нынче, вроде, рекомендуют питон для начала. До этого мне казалось с бейсика учили.
В общем я к тому, что уязвимости — бич популярности, а никак не простоты языка.
В общем я к тому, что уязвимости — бич популярности, а никак не простоты языка.
Python (англ. python — питон, произносится [ˈpaɪθ⟨ə⟩n] ).
А теперь произносим: П-а-й-т-о-н. Отличненько. Я зануда.
А теперь произносим: П-а-й-т-о-н. Отличненько. Я зануда.
habrahabr.ru/post/144168/?utm_source=twitterfeed&utm_medium=twitter#comment_4837655
Progrik 21 мая 2012, 00:27 # ↑
Не подскажите где почитать про это в пайсоне?
Elkan 21 мая 2012, 00:31 # ↑
вы хотели сказать в пуфоне? :D
limitium 25 мая 2012, 15:45 # ↑
писон же
Progrik 21 мая 2012, 00:27 # ↑
Не подскажите где почитать про это в пайсоне?
Elkan 21 мая 2012, 00:31 # ↑
вы хотели сказать в пуфоне? :D
limitium 25 мая 2012, 15:45 # ↑
писон же
PHP — достаточно простой язык с большой кучей подводных камней. Об этих камнях редко пишут в книгах на подобие «PHP для чайника», отсюда и появляется много кодеров готовых за 5 минут сделать сайт, в котором будут уязвимости о которых они даже не будут догадываться.
А ТП тут несколько не к месту :-)
А ТП тут несколько не к месту :-)
Ну денвер точно слабый аргумент.
Питон из коробки уже все содержит — Апач ему не нужен, базу можно sqlite брать, если даже в твоей сборке не будет простого фреймворка типа бутылки, то ставится опять таки в два клика…
Но как-то порог вхождения низким от этого не стал.
Хотя в целом да, ход мысли верный, согласен :)
Питон из коробки уже все содержит — Апач ему не нужен, базу можно sqlite брать, если даже в твоей сборке не будет простого фреймворка типа бутылки, то ставится опять таки в два клика…
Но как-то порог вхождения низким от этого не стал.
Хотя в целом да, ход мысли верный, согласен :)
UFO just landed and posted this here
Да, разумеется! Мы активно работаем с вендорами ПО.
В любом языке есть «нулевые» «знатоки». Вопрос только, стоит или нет такого нанимать — но это вопрос к заказчикам. Другой вопрос — «цена вхождения» в язык и для разработчика, и для заказчика.
Тот же PHP, если влиться в команду крупного opensource-проекта, можно неплохо поднять-прокачать. А вот хоститься на .NET, на Ruby, Python, чем-то еще — это сложнее и дороже, поэтому заказчики с ограниченным бюджетом, и понимающие в технологиях (т.е. — хотя бы минимально сравнивающие цены и условия) будут думать о дешевом хостинге — а от него путь приведет к PHP. Ну а предельная экономия даст еще и дешевого, но криворукого (точнее, незнающего и неопытного) новичка в PHP в роли «архитектора проекта», который на этом руку себе, конечно, набьет, но первый-второй-третий проект которого будет не самым лучшим.
Правда, могу сказать и обратное — когда есть задача заказать сайт, крутость (порой дутая) конторы-разработчика и язык, на котором в ней пишут, роль играет не самую важную. Важно, чтобы люди хотели сделать нечто особенно хорошее, и тратили на это силы и время. А если работа будет «спустя рукава» — так тут никакой язык не спасет :)
Тот же PHP, если влиться в команду крупного opensource-проекта, можно неплохо поднять-прокачать. А вот хоститься на .NET, на Ruby, Python, чем-то еще — это сложнее и дороже, поэтому заказчики с ограниченным бюджетом, и понимающие в технологиях (т.е. — хотя бы минимально сравнивающие цены и условия) будут думать о дешевом хостинге — а от него путь приведет к PHP. Ну а предельная экономия даст еще и дешевого, но криворукого (точнее, незнающего и неопытного) новичка в PHP в роли «архитектора проекта», который на этом руку себе, конечно, набьет, но первый-второй-третий проект которого будет не самым лучшим.
Правда, могу сказать и обратное — когда есть задача заказать сайт, крутость (порой дутая) конторы-разработчика и язык, на котором в ней пишут, роль играет не самую важную. Важно, чтобы люди хотели сделать нечто особенно хорошее, и тратили на это силы и время. А если работа будет «спустя рукава» — так тут никакой язык не спасет :)
Про один 1% среди СДБО как-то «позитивно» 8)
Тут встает такой интересный вопрос: столь высокая уязвимость сайтов на php связана с тем, что данный язык сам по себе является решетом, или, все — таки, в большей степенью с тем, что программы на нем писались менее квалифицированными разработчиками (в народе — «быдлокодерами»)?
Подпишите третий график — совсем непонятно про что он
UFO just landed and posted this here
Ещё одна причина, по-моему — большое количество приложений построенных «с нуля, на „голом“ PHP с использованием сторонних библиотек, максимум, для задач типа отправки почты, логирования и доступа к API. Если шаблонизатор будут использовать, то вообще замечательно. А вот на Java/C#, ставится, наверное, вопрос какой full-stack фреймворк будет использоваться (а с C# может и не ставится вовсе, вроде кроме ASP.NET MVC и не слышал ни об одном), какая ORM и т. п.
Плюс качество обучающих материлов — многие из них находятся на уровне, утрируя, „вчера написал hello world, сегодня учу вас“. Про архитектуру, тестирование, паттерны и прочие „тру“ вещи вообще молчу.
Плюс качество обучающих материлов — многие из них находятся на уровне, утрируя, „вчера написал hello world, сегодня учу вас“. Про архитектуру, тестирование, паттерны и прочие „тру“ вещи вообще молчу.
Не забывайте, что инструменты тоже пишут люди, и их архитектуру, и код. И я не уверен в тех людях (и в их целях), что разрабатывали PHP
Дело именно в языке. PHP был написан человеком, который в своем выступлении у ОРейли признавался, что он не совсем программист, и до сих пор не умеет писать парсеры. Получается, что система типов языка, преобразование типов и разбор выражений ущербны с момента создания языка, и в ней до сих пор есть ошибки вида «Ox0+2=4», которые пока никто не нашел.
К сожалению, автор языка утверждает " I hate programming with a passion. I like problem solving.", что сразу напоминает «А чо думать? Прыгать надо !».
А поскольку PHP написан в начале Интернет-эпохи, то сейчас он занял очень большое место в области веб-разработки и все разработчики прыгают как автор языка, даже если не хотят.
К сожалению, автор языка утверждает " I hate programming with a passion. I like problem solving.", что сразу напоминает «А чо думать? Прыгать надо !».
А поскольку PHP написан в начале Интернет-эпохи, то сейчас он занял очень большое место в области веб-разработки и все разработчики прыгают как автор языка, даже если не хотят.
Жаль только, что нет статистики по популярным CMS — Битрикс, WordPress, Joomla, Drupal и т. д.
Интересно, было протестировано одинаковое количество приложений на разных зыках? По 41 на язык или разное… Нашел ответ PHP «на нем написаны 63% всех протестированных сайтов» Получается статистика по языкам надумана.
Хотя я не отрицаю что в PHP продуктах возможно наибольшее количество уязвимостей.
сайты, это конкретные приложения, которые используют наши заказчики. Список их естественно привести не сможем, коммерческая тайна, NDA. Что касается процентов, округляли до целого или двух десятичных знаков.
Разглашение информации — это более чувствительные вещи, например, комментарии разработчиков, трейсы и пути файловой системы в сообщениях об ошибках и прочее.
Еще раз повторю — это реальные цифры и нам (да и владельцам систем) достаточно трудно (да и не особо нужно) угадывать в чем причина дырявости приложения: в особенностях asp.net или в свойствах «прокладки». Да и наша методика анализа не позволяет это понять, для этого надо влезать в SDL и другие процессы компании.
Но в целом да, холиварный отчет. Но вот такой он есть.
Разглашение информации — это более чувствительные вещи, например, комментарии разработчиков, трейсы и пути файловой системы в сообщениях об ошибках и прочее.
Еще раз повторю — это реальные цифры и нам (да и владельцам систем) достаточно трудно (да и не особо нужно) угадывать в чем причина дырявости приложения: в особенностях asp.net или в свойствах «прокладки». Да и наша методика анализа не позволяет это понять, для этого надо влезать в SDL и другие процессы компании.
Но в целом да, холиварный отчет. Но вот такой он есть.
Желтуха так желтуха!
«Известно, что «дырявость» сайта определяется еще в момент выбора языка»
збс.
«Известно, что «дырявость» сайта определяется еще в момент выбора языка»
збс.
Средняя температура по больнице — 36,6.
Интересно взять 10 лучших результатов (сайтов) в каждом языке, 10 худших, может ещё какие срезы делать. Иначе это скорее не количество уязвимостей продуктов на языках, а количество ошибок в ДНК прокладок между креслом и клавиатурой, использующих данные языки.
Интересно взять 10 лучших результатов (сайтов) в каждом языке, 10 худших, может ещё какие срезы делать. Иначе это скорее не количество уязвимостей продуктов на языках, а количество ошибок в ДНК прокладок между креслом и клавиатурой, использующих данные языки.
Хочется попросить авторов этого и других исследований интернета раскрывать чуть-чуть больше подробностей и писать рядом с процентами абсолютные цифры в ключевых моментах.
Например в приложенном документе
Пункт 3
>> В данном разделе приведены наиболее значимые заключения по статистическому анализу уязвимостей, выявленных в 123 веб-приложениях в ходе тестирований
Веб-приложение — это что? Джумла, Битрикс или конкретный сайт вроде гов.ру или газпром.ру? Можете добавить список этих протестированных веб-приложений?
>>… на нем написано 63% протестированных ресурсов
123 * 63% / 100% = 77.49. Что это за полресурса или всё-таки ресурсов (сайтов) было больше? Если больше, то можно узнать количество и список?)
Пункт 5.4
>> Во всех случаях лидером стала уязвимость Information Leakage.
Вот тут тоже хотелось бы узнать. Если сервер в заголовках отдаёт Apache 2.2/PHP 5.4 — это уязвимость? А если GWS?
Если в тексте страницы виден путь до ресурсов, который начинается с "/bitrix/..." — это уязвимость?
Например в приложенном документе
Пункт 3
>> В данном разделе приведены наиболее значимые заключения по статистическому анализу уязвимостей, выявленных в 123 веб-приложениях в ходе тестирований
Веб-приложение — это что? Джумла, Битрикс или конкретный сайт вроде гов.ру или газпром.ру? Можете добавить список этих протестированных веб-приложений?
>>… на нем написано 63% протестированных ресурсов
123 * 63% / 100% = 77.49. Что это за полресурса или всё-таки ресурсов (сайтов) было больше? Если больше, то можно узнать количество и список?)
Пункт 5.4
>> Во всех случаях лидером стала уязвимость Information Leakage.
Вот тут тоже хотелось бы узнать. Если сервер в заголовках отдаёт Apache 2.2/PHP 5.4 — это уязвимость? А если GWS?
Если в тексте страницы виден путь до ресурсов, который начинается с "/bitrix/..." — это уязвимость?
UFO just landed and posted this here
Или mysait/admin
Посмотрел приложенный документ.
Зачем вы делали эту «филькину грамоту»? Делать выводы по выборкам 7, 12, 13 элементов это тоже самое что гадать на картах.
Где погрешности? Где распределение по платформам?
Каково распределение по платформам внутри индустрий? Каковы ресурсы организаций? (некорректно сравнивать коленочное приложение на PHP против миллионного на сделанного на ASP, если мы говорим именно о платформах, а не конкретных приложениях)
Все это создает очень странное впечатление от уровня ваших экспертов, которые в количестве 17 человек выпустили туфту.
Зачем вы делали эту «филькину грамоту»? Делать выводы по выборкам 7, 12, 13 элементов это тоже самое что гадать на картах.
Где погрешности? Где распределение по платформам?
Каково распределение по платформам внутри индустрий? Каковы ресурсы организаций? (некорректно сравнивать коленочное приложение на PHP против миллионного на сделанного на ASP, если мы говорим именно о платформах, а не конкретных приложениях)
Все это создает очень странное впечатление от уровня ваших экспертов, которые в количестве 17 человек выпустили туфту.
Статистика была получена в результате анализа приложений, проводимого на коммерческой основе, поэтому даже если приложение и «коленочное» оно достаточно ценно для заказчика, чтобы инвестировать в его безопасность.
Не понятно что имеется ввиду под погрешностями в данном случае.
Распределение по платформам внутри индустрии можно привести, но непонятен в чем его смысл на такой выборке.
Еще раз напомним, что наше исследование прежде всего практическое, оно показывает как обстоят дела с безопасностью, а не как могли бы быть. Согласитесь телеком компании достаточно все равно, через багу в asp.net модном сайте или унаследованный наколенный php-сайтец были опубликованы смс его клиентов.
Это реальный мир и реальные риски.
Не понятно что имеется ввиду под погрешностями в данном случае.
Распределение по платформам внутри индустрии можно привести, но непонятен в чем его смысл на такой выборке.
Еще раз напомним, что наше исследование прежде всего практическое, оно показывает как обстоят дела с безопасностью, а не как могли бы быть. Согласитесь телеком компании достаточно все равно, через багу в asp.net модном сайте или унаследованный наколенный php-сайтец были опубликованы смс его клиентов.
Это реальный мир и реальные риски.
Если ваша статья начинается с тезисов,
"- какая CMS безопасней — коммерческая, OpenSource, или проще разработать самому?
— что безопасней — Java, PHP или ASP.NET?"
то деление по платформам, типам CMS, как бы подразумевается. Нет?
Под погрешностями имелась ввиду достоверность выводов. С какими допущениями, то что вы написали правда? У вас очень маленькие выборки и значительная экстраполяция если говорить о платформах и типах CMS. Или же я неправильно понял, и пассажи "С небольшим отрывом Java выигрывает у ASP.NET и в чемпионате по защищенности от внедрения SQL-кода, а PHP грустно машет им ручкой (61% уязвимых сайтов — доля почти в три раза выше, чем у конкурентов)." относятся исключительно к проверенным системам и экстраполяций не проводилось?
В разных индустриях свои требования к защите информации. Поэтому сравнивать банковское решение с гораздо более простыми системами в других областях несколько не корректно.
Да, я согласен. Телеком компании все равно. Она заказывает отчет о своем сайте и борется за свою безопасность. А нам не все равно, потому что мы пришли в топик узнать результаты исследований, а попали на данные не вызывающие ни доверия. Из вашей статьи нельзя вынести никаких практических выводов. Все графики можно было заменить утверждением — Все плохо, но мы делаем чтоб было лучше.
"- какая CMS безопасней — коммерческая, OpenSource, или проще разработать самому?
— что безопасней — Java, PHP или ASP.NET?"
то деление по платформам, типам CMS, как бы подразумевается. Нет?
Под погрешностями имелась ввиду достоверность выводов. С какими допущениями, то что вы написали правда? У вас очень маленькие выборки и значительная экстраполяция если говорить о платформах и типах CMS. Или же я неправильно понял, и пассажи "С небольшим отрывом Java выигрывает у ASP.NET и в чемпионате по защищенности от внедрения SQL-кода, а PHP грустно машет им ручкой (61% уязвимых сайтов — доля почти в три раза выше, чем у конкурентов)." относятся исключительно к проверенным системам и экстраполяций не проводилось?
В разных индустриях свои требования к защите информации. Поэтому сравнивать банковское решение с гораздо более простыми системами в других областях несколько не корректно.
Да, я согласен. Телеком компании все равно. Она заказывает отчет о своем сайте и борется за свою безопасность. А нам не все равно, потому что мы пришли в топик узнать результаты исследований, а попали на данные не вызывающие ни доверия. Из вашей статьи нельзя вынести никаких практических выводов. Все графики можно было заменить утверждением — Все плохо, но мы делаем чтоб было лучше.
Ах, вы об этом.
Детальные данные и выводы см. в оригинале исследования. Этот текст его урезанная интерпретация, сдобренная buzzwords. В оригинале есть информация в том числе и по регулированию, поскольку оно оказывает большое влияние на распределение уязвимостей. Так, благодаря PCI DSS в ДБО практически вычищены XSS и SQLi, но достаточно много логических недочетов связанных со сложными функциями авторизации (одноразовые пароли, sms и проч). Резать по платформам в рамках отрасли на такой выборке не вижу смысла, ибо непонятно к чему это приведет.
Погрешность и достоверность (простите за педантство) несколько разные понятие, чем и был вызван мой вопрос. Резюмируя, наши данные абсолютно достоверны при заданных начальных условиях, изложенных в полном тексте, а именно:
— приложения российских компаний из топ 100
— наиболее бизнес-критичные системы, доступные из Интернет (именно с ними связаны основные риски, именно их и заказывают)
— Ограничения методики «серого ящика» согласно которой анализировались приложения, и которая (как, к слову и любая) не дает гарантии, что все проблемы были обнаружены
К сожалению других чисел у нас нет. То, что делает WASC и Whitehat Security менее адекватно, поскольку содержит либо смесь черного и белого ящика (WASC), либо только черный с ручной верификацией (Whitehat).
Экстраполяции, предсказания и прочая мистика не использовались, только опыт. Что касается практического применения, то многие факты из исследования могут быть использованы в количественных методиках анализа рисков, что, согласитесь, достаточно полезно.
Детальные данные и выводы см. в оригинале исследования. Этот текст его урезанная интерпретация, сдобренная buzzwords. В оригинале есть информация в том числе и по регулированию, поскольку оно оказывает большое влияние на распределение уязвимостей. Так, благодаря PCI DSS в ДБО практически вычищены XSS и SQLi, но достаточно много логических недочетов связанных со сложными функциями авторизации (одноразовые пароли, sms и проч). Резать по платформам в рамках отрасли на такой выборке не вижу смысла, ибо непонятно к чему это приведет.
Погрешность и достоверность (простите за педантство) несколько разные понятие, чем и был вызван мой вопрос. Резюмируя, наши данные абсолютно достоверны при заданных начальных условиях, изложенных в полном тексте, а именно:
— приложения российских компаний из топ 100
— наиболее бизнес-критичные системы, доступные из Интернет (именно с ними связаны основные риски, именно их и заказывают)
— Ограничения методики «серого ящика» согласно которой анализировались приложения, и которая (как, к слову и любая) не дает гарантии, что все проблемы были обнаружены
К сожалению других чисел у нас нет. То, что делает WASC и Whitehat Security менее адекватно, поскольку содержит либо смесь черного и белого ящика (WASC), либо только черный с ручной верификацией (Whitehat).
Экстраполяции, предсказания и прочая мистика не использовались, только опыт. Что касается практического применения, то многие факты из исследования могут быть использованы в количественных методиках анализа рисков, что, согласитесь, достаточно полезно.
Ну, это как проанализировать количество косяков в Ламборджини и каком-нибудь Форд Фокусе.
Первых выходит в тысячу раз меньше, чем вторых — они более элитные и менее доступные. Конечно, и ломаются реже.
На PHP, хочется вам того или нет, написано, по разным оценкам, от 10 до 50% веб-приложений вообще. На Яве тоже очень много, а на довольно привязанном к M$ дотнете (и более молодом) — сильно меньше.
И именно популярность показывает процент исследованности на возможные косяки, а не абсолютную величину косячности, которая якобы коррелирует с языком.
Это, увы, так, хотя и печально. Вот я, к примеру, пишу это с Убунты 11.04. И как бы мне не хотелось считать, что эта система в миллион раз лучше Винды благодаря архитектуре без эти C:\, благодаря пакетному менеджеру, благодаря open-source и миллиону других вещей, это не так.
Я вынужден признать, что, стань Линукс такой же популярной, как и Винда, под нее напишут миллионы программ, и миллионы вирусов, и славу она обретет ничуть не менее дурную.
А знаете почему? Потому что не молоток — еблан, а еблан тот, кто этим молотком бьет себе по пальцу. Язык, или Ось — это только инструмент. И как нет защиты в любом Линуксе против бабы, вводящей свой рут-пароль в прогу «введи рут-пароль и просмотри СМСки мужа», так и нет защиты против говнокодеров, которых за сто выстрелов не то что к программированию — к станку подпускать нельзя.
Первых выходит в тысячу раз меньше, чем вторых — они более элитные и менее доступные. Конечно, и ломаются реже.
На PHP, хочется вам того или нет, написано, по разным оценкам, от 10 до 50% веб-приложений вообще. На Яве тоже очень много, а на довольно привязанном к M$ дотнете (и более молодом) — сильно меньше.
И именно популярность показывает процент исследованности на возможные косяки, а не абсолютную величину косячности, которая якобы коррелирует с языком.
Это, увы, так, хотя и печально. Вот я, к примеру, пишу это с Убунты 11.04. И как бы мне не хотелось считать, что эта система в миллион раз лучше Винды благодаря архитектуре без эти C:\, благодаря пакетному менеджеру, благодаря open-source и миллиону других вещей, это не так.
Я вынужден признать, что, стань Линукс такой же популярной, как и Винда, под нее напишут миллионы программ, и миллионы вирусов, и славу она обретет ничуть не менее дурную.
А знаете почему? Потому что не молоток — еблан, а еблан тот, кто этим молотком бьет себе по пальцу. Язык, или Ось — это только инструмент. И как нет защиты в любом Линуксе против бабы, вводящей свой рут-пароль в прогу «введи рут-пароль и просмотри СМСки мужа», так и нет защиты против говнокодеров, которых за сто выстрелов не то что к программированию — к станку подпускать нельзя.
Конечно, отчасти вы правы. С увеличением популярности среди пользователей, растет и популярность среди вирусописателей. Но эта зависимость не всегда значит то, что «никто не пишет вирусы, потому что не нужно». Возьмите, например, MacOS. Да будет вам известно, что в европе/США большая половина всех предпринимателей, глав корпораций, просто работников различных контор, а так же студентов хороших ВУЗов используют продукцию Apple в качестве десктопов/ноутбуков/нетбуков/планшетных компьютеров. Это продукция достаточно обеспеченной аудитории, часто очень обеспеченной, которые довольно часто платят в интернете, у них могут храниться данные, которые можно использовать против них самих и так далее. Как правило, это более «активные» пользователи, чем домохозяйки с виндой. Прямо-таки рай для вирусов и троянцев, казалось бы. А как обстоит дело на самом деле?
И да, и нет. Просто есть инструменты, более подходящие для решения цели, а есть менее подходящие. У первых как правило возможность стукнуть себе по пальцу минимизирована уже «из коробки». Чтобы эффективно использовать вторые нужно быть экспертом в обхождении подводных камней и знать все нюансы имплементации.
Не хочу обидеть автора, но не понимаю смысла таких статей и исследований, в которых имеет место быть подмена понятий и неправильная установка акцентов. Ведь эти статьи потом находят в интернете люди, понимающие в программировании еще меньше, чем программисты, которые делают уязвимые сайты на 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 лет иногда находили уязвимости архитектуры, или уязвимости в участках кода, который успешно эксплуатировался несколько лет и даже был покрыт тестами.
Когда потенциальные заказчики проводят собственные «исследования» вопроса, касательно сайтов, они могут найти статью, подобную этой, и сделать вывод, что сайты не нужно делать на 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 лет иногда находили уязвимости архитектуры, или уязвимости в участках кода, который успешно эксплуатировался несколько лет и даже был покрыт тестами.
Sign up to leave a comment.
Веб-уязвимости. Невероятное — очевидно