Будет ли веб-браузер C # / .Net подвержен эксплойтам? - PullRequest
4 голосов
/ 30 марта 2009

Правильно ли говорить, что платформа .Net более безопасна, поскольку CLR защищает от атак переполнения буфера?

Если предположить, что в управляемой ОС запущен веб-браузер (например, Cosmos , SharpOS или Singularity ), технически возможно, что злоумышленник сможет добавить код IL в приложение?

Стоит ли беспокоиться о атаках, которые невозможны в неуправляемых приложениях?

Ответы [ 2 ]

7 голосов
/ 30 марта 2009

По большей части вы правы. Приложения с безопасной системой типов (не только .NET или Java) не позволяют приложению нарушать эти ограничения.

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

(Как примечание, C # все еще может выполнять небезопасные действия и настраивать себя на выполнение произвольного кода. Это просто довольно громоздко и вряд ли будет использоваться в реальном приложении.)

Бреши в безопасности, которые вы бы увидели в управляемом браузере, были бы, если бы он позволял загружать произвольный код, используя CLR в качестве безопасной среды. Хотя сгенерированный CLR код (т. Е. JIT-файл вашего приложения) будет безопасным, сами загрузчик и верификатор обычно пишутся на более низком языке. Было несколько (я думаю, 2 для .NET?) Брешей в безопасности, где злонамеренно сформированная сборка могла заставить реальный CLR выполнять произвольный код. Однако это относительно редкие проблемы, и площадь поверхности намного меньше, чем была бы в противном случае.

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

2 голосов
/ 30 марта 2009

CLR (и JVM) защищают от многих распространенных атак, но это не устраняет все угрозы. CLR или любая библиотека может содержать ошибки, которые допускают эксплойты. Ошибки приложения также могут допускать эксплойты. SQL-инъекция является примером атаки, которая возможна из-за отсутствия проверки ввода в приложении.

...