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

Вы можете использовать комбинацию MergeCursor и MatrixCursor с вашей БД cursor следующим образом:

MatrixCursor extras = new MatrixCursor(new String[] { "_id", "title" });
extras.addRow(new String[] { "-1", "New Template" });
extras.addRow(new String[] { "-2", "Empty Template" });
Cursor[] cursors = { extras, cursor };
Cursor extendedCursor = new MergeCursor(cursors);
17
задан Gavin 12 August 2009 в 08:02
поделиться

10 ответов

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

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

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

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

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

13
ответ дан 30 November 2019 в 12:13
поделиться

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

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

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

4
ответ дан 30 November 2019 в 12:13
поделиться

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

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

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

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

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

3
ответ дан 30 November 2019 в 12:13
поделиться

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

3
ответ дан 30 November 2019 в 12:13
поделиться

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

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

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

2
ответ дан 30 November 2019 в 12:13
поделиться

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

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

2
ответ дан 30 November 2019 в 12:13
поделиться

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

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

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

3
ответ дан 30 November 2019 в 12:13
поделиться

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

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

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

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

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

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

1
ответ дан 30 November 2019 в 12:13
поделиться

Многие MVC такие же, как и WebForms - они оба находятся на Asp.net, как уже сказал @GuyIncognito, большая часть из них одинакова.

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

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

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

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

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

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

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

просто сейчас проще попробовать этот тип взлома в MVC.

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

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

просто сейчас проще попробовать этот тип взлома в MVC.

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

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

2
ответ дан 30 November 2019 в 12:13
поделиться

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

0
ответ дан 30 November 2019 в 12:13
поделиться
Другие вопросы по тегам:

Похожие вопросы: