Проблемы безопасности при работе с новыми технологиями

Question

Считаете ли вы, что когда вы работаете с новой технологией, вы никогда не знаете, какая безопасность мешает вам оставить свой код?

Я работаю с ASP.Net Web Forms уже около 5 лет и уверен, что мой код по крайней мере достаточно безопасен, чтобы остановить большинство известных атак. Оглядываясь назад, в своем раннем коде я неосознанно оставил пробелы во многих областях безопасности, особенно в строках запросов и представлениях, но я чувствую, что со временем я узнал, что такое уязвимости, и убедился, что я больше не повторю те же ошибки.

Однако недавно я начал новый проект в ASP.Net MVC, и я действительно не знаю, какие дыры в безопасности я оставляю открытыми. Одна только эта причина почти отталкивает меня от этого. Я читаю об этом, как о сумасшедшем, но уверен, что я недостаточно выучил, чтобы сделать его настолько безопасным, насколько я мог, с помощью веб-форм. Что вы, ребята, делаете, чтобы убедиться, что вы не оставляете себя открытым для атаки?

Редактировать: Начиная Баунти как любопытно посмотреть, есть ли еще мнения

Answer 1

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

1. Имейте в виду следующее: существует три типа уязвимостей. Уникальные для используемой вами среды (например, проблемы с публичными контроллерами Ruby on Rails), уникальные для типа создаваемого приложения (например, веб-приложения должны беспокоиться о XSS) и уникальные для вашего приложения. в частности.
2. Определите, как новая технология, которую вы используете, уменьшает уязвимости типа приложений. Например, как ASP.Net MVC смягчает XSS? Как это смягчает инъекцию SQL? Если в документации нет ответа, выясните, как вы собираетесь устранять эти распространенные классы уязвимостей. Кроме того, сделайте паузу, потому что, если платформа не устраняет эти проблемы, то, возможно, разработчики платформ не отдали приоритет безопасности и, возможно, не написали очень надежную платформу.
3. Выясните, почему вам нужна безопасность и что вы пытаетесь защитить. Например: требует ли ваше приложение авторизацию перед просмотром конфиденциальных данных? Если это так, определите, какие функции предоставляет инфраструктура для авторизации.
4. Ищите раздел безопасности в документации. Часто известные проблемы документируются, но люди так много внимания уделяют решению своей проблемы, что не ищут ее.
5. Используйте защитный код и помните, как используется пользовательский ввод. Будьте щедры в определении того, что является вводом пользователя. Например, строки запроса или записи очевидны, но во многих средах MVC URL-адрес определяет, какой код выполняется (например, см. Уязвимость Ruby Routes). Быть в курсе того, как обрабатываются данные
6. Проведите стресс-тестирование вашей бизнес-логики и выясните, как ею можно злоупотреблять.

Итак, вкратце: аккуратно обрабатывайте вводимые пользователем данные, читайте существующую документацию, определяйте, какую защиту вам требуется, и выясняйте, как среда смягчает общие классы уязвимостей. Осознание того, что безопасность является приоритетом, и уделение внимания - это 50% борьбы.

Answer 2

Я думаю, что многое из того, что вы узнали о ASP.NET, можно перенести в ASP.NET MVC. Это все еще HTML (эксплойты: XSS) через HTTP (эксплойты: все входные данные [куки, параметры URL, ввод формы, заголовки] могут быть подделаны, перехват сеанса, CSRF) с помощью базы данных (эксплойты: инъекция SQL).

Я бы порекомендовал Книгу Стива Сандерсона на ASP.NET MVC под названием Pro ASP.NET MVC Framework . Целая глава посвящена этим темам.

Ознакомьтесь с главой 13 «Безопасность и уязвимость» из Оглавление для книги.

Answer 3

Технологии, которые вы используете, могут измениться, но основные проблемы безопасности - нет. Во всяком случае, я ожидаю, что в коде, использующем более новые библиотеки, будет меньше дыр в безопасности, поскольку они разработаны с учетом распространенных атак. Например, SQL-инъекция просто не происходит с классами, которые VS2008 генерирует через DBML.

Answer 4

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

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

РЕДАКТИРОВАТЬ: ASP.NET MVC OSS ?? Посмотрите на исходный код nerddinner.com и поиграйте с ним. Авторы на высшем уровне, и я предполагаю, что они должны были подумать о безопасности при создании этого!

Answer 5

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

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

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

не позволяйте этому удерживать вас от изучения чего-то нового, просто делайте все возможное, читайте об угрозах безопасности для вашей технологии и уходите. (попробуйте http://www.securityfocus.com)

экспертные оценки могут помочь в этом, и существуют инструменты, которые могут упростить поиск дыр в безопасности.

Answer 6

Большинство MVC - это то же самое, что и веб-формы - они оба находятся на Asp.net, как уже сказал @GuyIncognito, большинство из них одинаковые.

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

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

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

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

В любом случае, все это является наилучшей практикой в ​​WebForms, теперь проще попробовать этот тип взлома в MVC.

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

Все остальное (кодирование всех сгенерированных пользователем выходных данных, параметризация всех входных данных Sql и т. Д.) Одинаково.

Answer 7

Опять же, специфично для ASP.NET MVC, действительно следите за использованием связывания моделей. Вы должны всегда явно указывать свойства, которые будут связаны.

Невыполнение этого требования может привести к неожиданным побочным эффектам (как я выяснил ...!) И может позволить кому-то злонамеренно изменить свойства модели.

Answer 8

Совет специально для ASP.NET MVC:

В ваших представлениях максимально используйте методы HtmlHelper (например, Html.BeginForm, Html.TextBox, Html.ActionLink и т. Д.) По сравнению с необработанными тегами HTML. Помощники автоматически HTML-кодируют значения, которые вы передаете в него, уменьшая вероятность создания уязвимости XSS.

Для всех других входных данных, которые вы воспроизводите в своем представлении, всегда используйте Html.Encode.

Answer 9

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

ASP.NET MVC имеет несколько полезных функций для проверки ваших данных, особенно с v2. Вот пост Скотта Гу о v2 , который показывает, как сделать проверку действительно аккуратным способом. Также обратите внимание, что вы можете легко реализовать свои собственные методы проверки таким же образом.

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

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

Answer 10

Одно простое решение: предположим, что в вашем приложении есть дыры в безопасности, и подключите их вне вашего приложения. Например, ограничьте доступ (через IIS) к «небезопасным» URL-адресам с ограничениями SSL и / или IP.