Здравствуйте, мыщъх, Вы писали:

KV>> Любые аналогии лживы и уводят обсуждение в сторону, если используются как аргументы.
М>хорошо, давайте без аналогий. крупные компании, пишушие на php крупные сайты, мне не известны, зато известны студенты и админы, подрабатывающие на php.

wikipedia, digg, flickr, yahoo, photobucket, морда facebook (с оговорками)...

М>неудивительно, что вы нашли дыры на php-сайтах. удивительно, что вы их не нашли на остальных. например, мне известно, что все сайты, написанные на java, при тестировании специально обученными людьми, просто кишели ошибками,

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

М>ибо программистам свойственно ошибаться и java сама по себе не обеспечивает безопасность автоматом.

Да ни один язык не обеспечивает автоматом безопасность. Просто есть языки, не дающие программистам наступать на определенные грабли, а есть гремучие смеси динамики и слабой типизации, типа PHP и JS.

KV>> Вот и все объяснение полученным цифрам
М>то есть, вы все же считаете, что проблемы безопасности php вызваны его динамической природой, а бюджетом разработки?

Я глубоко задумался на этим вопросом и конечно причины не только в типизации. Думаю, что скоро набросаю где-нибудь заметку на эту тему. Мыслей много. Более того, я уверен, что если взять очень большое количество веб-приложений, то количество серьезных уязвимостей там для различных будет отличаться на 10-20% максимум. Но это будет средняя температура по больнице, не говорящая ни о чем. В общем, эту мысль раскрою позже.

М>мы на php не пишем. у нас web на java. и пишут его профи, которые на этом собаку съели. думаете, что тестировщики не находят ошибок? у нас целый отдел проверяет сайт на информационную безопасность и там работают люди типа нас с вами.

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

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

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

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

Это точно.

М>ЗЫ. если я предложу свои написать код на php на меня посмотрят как на дурака, ибо php не сертифицирован ни в одной серьезной области. например, он не сертифицирован для работы с финансами и потому интернет-банк на php не напишешь. и отсутствие сертификата у php и его наличие у других языков, говорит намного больше цифр, т.к. сертификацией не идиоты занимаются.

А можно пример сертифицированного языка?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>То, что канонический питон написан на С не делает его более статическим языком, по сравнению с PyPy, написанным на самом питоне.

Где я такой бред утверждал?

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

Ага, конечно! Проблемы в модуле написанном на С++ для .NET, в котором утечки памяти тоже не имеют никакого значения. Они же написаны для взаимодействия с .NET в которой утечек памяти нет

KV>И проблемы, о которых мы говорим, возникают именно в ней (в нашем случае, когда она создает новый объект-типа), а не в самих модулях.

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

Здравствуйте, __lambda__, Вы писали:
___>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Любая уязвимость — это кривые руки. Вопрос только в пороговом радиусе кривизны, допускаемом языком. Но с чего бы ей быть глобальной?
___>Да, это моя не точность, более точнее сказать, что дефолтный параметр является мутабельным. И опять же, типизация тут вообще не причем, это семантика определенная для параметра по умолчанию и все.

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

KV>>Тут при чем внутренняя реализация аргументов по умолчанию в питоне, продиктованная динамической типизацией.
___>Вот выделенное тоже неверно. Ruby c динамической типизацией, но там оно не диктует такую семантику.

И что это доказывает? Что в ruby разработчики потратили больше времени на грамотную организацию деревьев объектов в исполняющей среде?

Здравствуйте, netch80, Вы писали:

N>отсутствие желания читать FAQ по типичным граблям.

А можно ссылки на исчерпывающие факи по граблям в питоне и яваскрипте?

Здравствуйте, __lambda__, Вы писали:
___>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Язык реализации модулей питона не имеет здесь никакого значения, т.к. пишутся они для того, чтобы с ними взаимодействовала динамическая среда исполнения.
___>Ага, конечно! Проблемы в модуле написанном на С++ для .NET, в котором утечки памяти тоже не имеют никакого значения. Они же написаны для взаимодействия с .NET в которой утечек памяти нет

Если утечка таки-случится в CLR, а не модуле на C++, то мы получим примерную аналогию того, что происходит в моем примере.

KV>>И проблемы, о которых мы говорим, возникают именно в ней (в нашем случае, когда она создает новый объект-типа), а не в самих модулях.
___>Ну даже если так, что проблемы при создании нового объекта-типа, тут нужно доказать, что это связано именно с динамической типизацией, а не определенной семантикой создания новых типов.

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

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, netch80, Вы писали:

N>>отсутствие желания читать FAQ по типичным граблям.

KV>А можно ссылки на исчерпывающие факи по граблям в питоне и яваскрипте?

Я вообще-то говорил про типичные, а не про исчерпывающие. Не думаю, что такие есть хоть по какому-нибудь языку.
А для типичных — хотя бы книга Dive into Python, там много таких разъяснено.
Про JS ничего не скажу, я его не знаю.

Здравствуйте, netch80, Вы писали:

KV>>А можно ссылки на исчерпывающие факи по граблям в питоне и яваскрипте?

N>Я вообще-то говорил про типичные, а не про исчерпывающие. Не думаю, что такие есть хоть по какому-нибудь языку.
N>А для типичных — хотя бы книга Dive into Python, там много таких разъяснено.
N>Про JS ничего не скажу, я его не знаю.

Я не для поспорить, думал, может есть где-нибудь в структурированном виде что-то типа http://stackoverflow.com/questions/1995113/strangest-language-feature

Здравствуйте, kochetkov.vladimir, Вы писали:

N>>Я вообще-то говорил про типичные, а не про исчерпывающие. Не думаю, что такие есть хоть по какому-нибудь языку.
N>>А для типичных — хотя бы книга Dive into Python, там много таких разъяснено.
N>>Про JS ничего не скажу, я его не знаю.

KV>Я не для поспорить, думал, может есть где-нибудь в структурированном виде что-то типа http://stackoverflow.com/questions/1995113/strangest-language-feature

Там интересный набор, но нет самого жуткого, на мой взгляд, примера — ALTER GOTO в Коболе.
А то, что JavaScript на первом месте по чудесам — очень показательно (это уже к соседнему постингу).

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>И проблемы, о которых мы говорим, возникают именно в ней (в нашем случае, когда она создает новый объект-типа), а не в самих модулях.
___>>Ну даже если так, что проблемы при создании нового объекта-типа, тут нужно доказать, что это связано именно с динамической типизацией, а не определенной семантикой создания новых типов.

KV>Тут есть один маленький нюанс: чем больше разработчиков на динамике, которые считают, что им необходимо что-то доказывать, тем гарантированней я обеспечен работой на весьма приличный срок. Если не очевидно, что это связано с тем, что объекты в динамической исполняющей среде представлены в виде изменяемых хэш-таблиц, то просто продолжайте обеспечивать меня работой, я буду только благодарен

Вообще-то совсем не очевидно, потому что
1) "хэш-таблиц" не всегда является верным (оно верно по умолчанию, но не всегда; см. хотя бы питоновские __slots__)
2) "изменяемых" тоже не абсолютно (кроме слотов, можно ввести явные ограничения)
3) не обязательно это влияет на безопасность

Правильно всё-таки сформулировать, что статически значимое большинство языков и реализаций на них — именно такие (с представлением объектов в изменяемых хэш-таблицах, без эффективного контроля назначения произвольных атрибутов), и это даёт определённую (порой заметную) часть проблем в реализации, включая защиту. Мнэээ... вот как загнул, самому завидно Актуальная проблема может быть выражена следующим образом:
1) Слишком большой вес набрали те из динамических языков, которые обладают наиболее диверсионными свойствами — как JavaScript и PHP. См. хотя бы твою ссылку про strangest language feature и множество примеров на JS. Питон по сравнению с ними ещё хороший пример (например, в нём в принципе нет автоконверсии между числом и строкой, как в перле, PHP или JS). Включение JS в нынешнем виде в HTML5 меня в этом смысле вообще ужасает.
2) Программисты на этих языках не получают адекватную подготовку, которая бы помогала компенсировать гибкость этих языков, чрезмерную для большинства практических задач. Каждый, кто пишет на таких языках, должен контролировать себя сильнее, чем там, где состав полей, названия функций и прочие места, где легко ошибиться, проверяются компилятором. Должны использоваться средства контроля имён, разнообразные чекеры с хитрой логикой, анализаторы, их подсказки должны тщательно проверяться. Никакая фича крупнее десятка строк, или оформленная как use-case для пользователя, не должна считаться законченной без теста, анализирующего реализацию во всех основных аспектах. Обязателен code review, для особо важных мест — парное написание. И так далее.

Только вот всё это пока что благие пожелания, увы. А вместо нормального подхода мы имеем яваскрипты в стандарте. Да уж, с тем, что тебе работы будет ещё лет на 20 минимум, я согласен