Slashdot пишет о том, что SANS Institute опубликовал список 25 самых опасных ошибок программирования по мнению экспертов (из Oracle, Microsoft, Red Hat и др.). Также есть более подробное описание на сайте Common Weakness Enumeration.

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

К>Slashdot пишет о том, что SANS Institute опубликовал список 25 самых опасных ошибок программирования по мнению экспертов (из Oracle, Microsoft, Red Hat и др.). Также есть более подробное описание на сайте Common Weakness Enumeration.

Перевод: http://habrahabr.ru/blogs/development/50148/

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

К>Slashdot пишет о том, что SANS Institute опубликовал список 25 самых опасных ошибок программирования по мнению экспертов (из Oracle, Microsoft, Red Hat и др.). Также есть более подробное описание на сайте Common Weakness Enumeration.

это основные ошибки не программирования, а защиты веб-серверов (при их программировании, конечно)

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

BZ>это основные ошибки не программирования, а защиты веб-серверов (при их программировании, конечно)

Аргументы будут?

А то, во-первых, не веб-серверов, а веб-приложений. И не защиты, а программирования. А во-вторых, ошибок, которые применимы исключительно к веб-приложениям я там насчитал ровно 2.

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

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

BZ>>это основные ошибки не программирования, а защиты веб-серверов (при их программировании, конечно)

KV>Аргументы будут?

KV>А то, во-первых, не веб-серверов, а веб-приложений. И не защиты, а программирования. А во-вторых, ошибок, которые применимы исключительно к веб-приложениям я там насчитал ровно 2.

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

основные ошибки при программировании на С — это null, неинициализация, пропуск обработки варианта, +-1. они там даже не упомянуты. с другой стороны, там есть ошибки чисто вебовские. поэтому я и сделал вывод, что это список ошибок *защиты*, составленный веб-разработчиком

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

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

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

BZ>>>это основные ошибки не программирования, а защиты веб-серверов (при их программировании, конечно)

KV>>Аргументы будут?

KV>>А то, во-первых, не веб-серверов, а веб-приложений. И не защиты, а программирования. А во-вторых, ошибок, которые применимы исключительно к веб-приложениям я там насчитал ровно 2.

BZ>ты ведь защитник, насколько я понимаю, а не программист?

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

BZ>ну вот, поверь на слово — я когда начал читать этот список, на первом пункте подумал "а, это веб-специфичная хрень", на втором — то же самое, потом понял, что там весь список такой

Ну во-первых, это просто несерьезно — не ознакомившись со всеми ошибками, делать вывод о них по первым двум. А во-вторых:

1. Недостаточная проверка ввода
Убедитесь, что ваши входные данные правильны. Если вы ожидаете число, там не должно быть букв. Равно как и цена нового автомобиля не может быть равна доллару. Неправильная проверка ввода может привести к уязвимости, когда злоумышленник может изменять вводимые данные неожиданным способом. Многих наиболее общих уязвимостей известных сегодня можно избежать или хотя бы сократить с помощью строгой проверки ввода.

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

Собственно, если нажать на заголовок ошибки, то можно попасть на ее подробное описание. Там отнюдь не все примеры имеют отношение к веб: http://cwe.mitre.org/data/definitions/20.html

BZ>основные ошибки при программировании на С — это null, неинициализация, пропуск обработки варианта, +-1. они там даже не упомянуты.

Вообще-то упомянуты в №10, причем с примерами именно на С: http://cwe.mitre.org/data/definitions/119.html

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

KV>А точнее можешь сформулировать, что есть "защитник"? А то, если следовать твоей же логике, то я более профессионально владею вопросами обеспечения безопасности кода, а ты вопросами его написания (в общем-то так и есть, как я подозреваю). Но коли так, то получается, что в предметную область этого топика я погружен чуть глубже чем ты

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

KV>Разве входные данные имеют место только в веб-приложениях?

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

BZ>>основные ошибки при программировании на С — это null, неинициализация, пропуск обработки варианта, +-1. они там даже не упомянуты.

KV>Вообще-то упомянуты в №10, причем с примерами именно на С: http://cwe.mitre.org/data/definitions/119.html

вот и читаем здесь "When software permits read or write operations on memory located outside of an allocated range, an attacker"

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

BZ>вот и читаем здесь "When software permits read or write operations on memory located outside of an allocated range, an attacker"
И что? Атакующий может сидеть за компом под гостевым аккаунтом и пытаться получить админа. Атакующим может быть троян, который тоже хочет получить админа.
Были уже примеры elevation of privilege через дыру в авире, работающим под системным аккаунтом.

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

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

KV>>А точнее можешь сформулировать, что есть "защитник"? А то, если следовать твоей же логике, то я более профессионально владею вопросами обеспечения безопасности кода, а ты вопросами его написания (в общем-то так и есть, как я подозреваю). Но коли так, то получается, что в предметную область этого топика я погружен чуть глубже чем ты

BZ>программисты зовут тебя каждый раз, когда программа не работает?

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

BZ>ты путаешь отладку ПО с частной задачей — обеспечением безопасности

Ты сейчас с каким тезисом споришь?

KV>>Разве входные данные имеют место только в веб-приложениях?
BZ>ещё раз — он пишет о проблемах безопасности веб-приложений. это не означает, что эти ошибки не встречаются в других местах, но его список составлен именно таким образом

Он (Jeff Atwood) пишет что "if you work on software in any capacity, at least skim this list". И никакого упоминания о том, что этот список составлен "именно таким образом", что представляет из себя "проблемы безопасности веб-приложений". Ты сам признаешь, что многие из этих ошибок вполне возможны и не в веб-приложениях, так откуда тогда взялось это мнение?

BZ>>>основные ошибки при программировании на С — это null, неинициализация, пропуск обработки варианта, +-1. они там даже не упомянуты.
KV>>Вообще-то упомянуты в №10, причем с примерами именно на С: http://cwe.mitre.org/data/definitions/119.html
BZ>вот и читаем здесь "When software permits read or write operations on memory located outside of an allocated range, an attacker"

А что смущает? Любые ошибки кодирования (вообще, в принципе) можно разделить на те, которым глубоко пофиг на факт существования атакующего и те, через которые атакующий может извне, по отношению к приложению, изменять логику его работы на нужную ему. Второй класс ошибок существенно опаснее (надо объяснять почему?) и список top 25 подобных ошибок и был приведен в этой статье.

Я не совсем понимаю, с чем ты споришь? И с чем постоянно согласен столь молчаливый minorlogic?

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

KV>Я не совсем понимаю, с чем ты споришь? И с чем постоянно согласен столь молчаливый minorlogic?

у тебя просто восприятие программирования с точки зрения безопасника

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

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

KV>>Я не совсем понимаю, с чем ты споришь? И с чем постоянно согласен столь молчаливый minorlogic?

BZ>у тебя просто восприятие программирования с точки зрения безопасника

А у тебя — восприятие безопаности с точки зрения программиста

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

KV>Я не совсем понимаю, с чем ты споришь? И с чем постоянно согласен столь молчаливый minorlogic?

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

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

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

KV>>Я не совсем понимаю, с чем ты споришь? И с чем постоянно согласен столь молчаливый minorlogic?

M>Не берусь утверждать что это 25 ошибок веб приложения , но это точно не 25 ошибок програмирования. Собственно я большей частью пишу софт , который не предполагает какую либо защиту от вероломного атакующего.

А все, теперь вспомнил. Мы еще в теме про сказку об этом начали...

А вот скажи, к примеру, использование параметризованных SQL-запросов вместо конкатенации строк, является мерой по "защите от вероломного атакующего"? А проверка (в коде) за выход границы массива или целочисленного переполнения? А типобезопасность?

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

KV>А вот скажи, к примеру, использование параметризованных SQL-запросов вместо конкатенации строк, является мерой по "защите от вероломного атакующего"? А проверка (в коде) за выход границы массива или целочисленного переполнения? А типобезопасность?

основные меры безопасности при путешествии по Западной Европе: во-первых, опасайтесь людоедов...

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


KV>А вот скажи, к примеру, использование параметризованных SQL-запросов вместо конкатенации строк, является мерой по "защите от вероломного атакующего"?
Не знаю.

KV> А проверка (в коде) за выход границы массива или целочисленного переполнения? А типобезопасность?
Наверное не является?