Библиотека knigago >> Компьютеры: Языки и системы программирования >> C, C++, C# >> 19 смертных грехов, угрожающих безопасности программ

Дэвид Лебланк , Майкл Ховард , Джон Виега - 19 смертных грехов, угрожающих безопасности программ

19 смертных грехов, угрожающих безопасности программ
Книга - 19 смертных грехов, угрожающих безопасности программ.  Дэвид Лебланк , Майкл Ховард , Джон Виега  - прочитать полностью в библиотеке КнигаГо
Название:
19 смертных грехов, угрожающих безопасности программ
Дэвид Лебланк , Майкл Ховард , Джон Виега

Жанр:

Другие языки и системы программирования, Учебники и самоучители по компьютеру, Компьютерная безопасность, Современные российские издания, Литература ХXI века (эпоха Глобализации экономики), .NET Framework, Basic, Visual Basic, VB Script, VBA и т.п., C, C++, C#, PHP, Python, Java, Java Script

Изадано в серии:

неизвестно

Издательство:

неизвестно

Год издания:

-

ISBN:

неизвестно

Отзывы:

1 комментарий

Рейтинг:

Поделись книгой с друзьями!

Помощь сайту: донат на оплату сервера

Краткое содержание книги "19 смертных грехов, угрожающих безопасности программ"

Эта книга необходима всем разработчикам программного обеспечения, независимо от платформы, языка или вида приложений. В ней рассмотрены 19 грехов, угрожающих безопасности программ, и показано, как от них избавиться. Рассмотрены уязвимости на языках C/C++, C#, Java, Visual Basic, Visual Basic.NET, Perl, Python в операционных системах Windows, Unix, Linux, Mac OS, Novell Netware. Авторы издания, Майкл Ховард и Дэвид Лебланк, обучают программистов, как писать безопасный код в компании Microsoft. На различных примерах продемонстрированы как сами ошибки, так и способы их исправления и защиты от них. Если вы программист, то вам просто необходимо прочесть эту книгу.

Перевод: А. Слинкин

Читаем онлайн "19 смертных грехов, угрожающих безопасности программ" (ознакомительный отрывок). [Страница - 5]

здесь и этот случай.

Результатом переполнения буфера может стать что угодно – от краха программы до получения противником полного контроля над приложением, а если приложение запущено от имени пользователя с высоким уровнем доступа (root, Administrator или System), то и над всей операционной системой и другими пользователями. Если рассматриваемое приложение – это сетевая служба, то ошибка может привести к распространению червя. Первый получивший широкую известность Интернет–червь эксплуатировал ошибку в сервере finger, он так и назывался – «finger–червь Роберта Т. Морриса» (или просто «червь Морриса»). Казалось бы, что после того как в 1988 году Интернет был поставлен на колени, мы уже должны научиться избегать переполнения буфера, но и сейчас нередко появляются сообщения о такого рода ошибках в самых разных программах.

Быть может, кто–то думает, что такие ошибки свойственны лишь небрежным и беззаботным программистам. Однако на самом деле эта проблема сложна, решения не всегда тривиальны, и всякий, кто достаточно часто программировал на С или С++, почти наверняка хоть раз да допускал нечто подобное. Автор этой главы, который учит других разработчиков, как писать безопасный код, сам однажды передал заказчику программу, в которой было переполнение на одну позицию (off–by–one overflow). Даже самые лучшие, самые внимательные программисты допускают ошибки, но при этом они знают, насколько важно тщательно тестировать программу, чтобы эти ошибки не остались незамеченными.

Подверженные греху языки

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

В языках более высокого уровня, появившихся позже, программист уже не имеет прямого доступа к памяти, хотя за это и приходится расплачиваться производительностью. В такие языки, как Java, С# и Visual Basic, уже встроены строковый тип, массивы с контролем выхода за границы и запрет на прямой доступ к памяти (в стандартном режиме). Кто–то может сказать, что в таких языках переполнение буфера невозможно, но правильнее было бы считать, что оно лишь гораздо менее вероятно. Ведь в большинстве своем эти языки реализованы на С или С++, а ошибка в реализации может стать причиной переполнения буфера. Еще один потенциальный источник проблемы заключается в том, что на какой–то стадии все эти высокоуровневые языки должны обращаться к операционной системе, а уж она–то почти наверняка написана на С или С++. Язык С# позволяет обойти стандартные механизмы .NET, объявив небезопасный участок с помощью ключевого слова unsafe. Да, это упрощает взаимодействие с операционной системой и библиотеками, написанными на C/C++, но одновременно открывает возможность допустить обычные для C/C++ ошибки. Даже если вы программируете преимущественно на языках высокого уровня, не отказывайтесь от тщательного контроля данных, передаваемых внешним библиотекам, если не хотите пасть жертвой содержащихся в них ошибок.

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

Как происходит грехопадение

Классическое проявление переполнения буфера – это затирание стека. В откомпилированной программе стек используется для хранения управляющей информации (например, аргументов). Здесь находится также адрес возврата из функции и, поскольку число регистров в процессорах семейства х86 невелико, сюда же перед входом в функцию помещаются регистры для временного хранения. Увы, в стеке же выделяется память для локальных переменных. Иногда их неправильно называют статически распределенными в противоположность динамической памяти, выделенной из кучи. Когда кто–то говорит о переполнении статического буфера, он чаще всего имеет в виду переполнение буфера в стеке. Суть проблемы в том, что если приложение пытается писать за --">
Комментариев: 1
15-04-2024 в 22:00   #1568
Книга "19 смертных грехов, угрожающих безопасности программ" Дэвида Лебланка посвящена самым распространенным ошибкам в разработке программного обеспечения, которые могут привести к серьезным уязвимостям в безопасности. Это незаменимое руководство для разработчиков и специалистов по безопасности, стремящихся создавать надежные и защищенные приложения.



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

* Буферные переполнения
* Инъекции SQL
* Межсайтовый скриптинг
* Подделка межсайтовых запросов
* Обход проверки подлинности

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



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



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



Лебланк на протяжении всей книги подчеркивает соответствие стандартам и лучшим практикам безопасности, таким как OWASP Top 10 и NIST Cybersecurity Framework. Он показывает, как применять эти стандарты для создания более безопасных приложений.



Книга предназначена для широкой аудитории, включая:

* Разработчики программного обеспечения
* Специалисты по безопасности
* Тестировщики программного обеспечения
* Руководители проектов



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

Оставить комментарий:


Ваш e-mail является приватным и не будет опубликован в комментарии.