Блог Сергея Байдачного

Мой блог о технологиях

Archive for the ‘Security’ Category

Простые вещи о безопасности

with one comment

Сижу дома, болею, никого не трогаю. Но, изучая работу «песочницы» для SharePoint 2010, решил проверить, подписывает ли VS 2010 сборки для проектов, которые разворачивает в «песочницу» — подписывает. На фоне этого вспомнил о старых и «хорошо знакомых» вещах, связанных с цифровой подписью, о чем и написал предыдущий пост. И тут же получил комментарий – мол не интересно, все можно найти в MSDN. Оно конечно можно, но этот комментарий побудил меня написать еще один пост, связанный с безопасностью. Я об этом часто рассказываю, об этом написано в MSDN, об этом написано везде, но я сталкиваюсь с этим регулярно.

Итак, была у меня учетная запись в одной онлайн банковской системе. Назовем ее eBank. Система работала замечательно (хотя и была написана какими-то студентами) и позволяла делать много полезных вещей (создавать счета в разных валютах, оформлять переводы и т. д.). И вот, в один прекрасный день, систему решили улучшить. Ну, как у нас принято, переписатьJ Проблема в том, что те студенты уже ушли (в банках платят не очень, а любое повышение в 10 баксов выставляют как мега событие). Поэтому систему писали уже другие студенты. А Вы все знаете, что уровень нынешних студентов уже не тот…

Так вот, сижу я месяц – не работает, три – не работает. Месяцев через шесть, начинаю связываться со службой поддержки. Мол, так и так, когда заработает. А в службе поддержки мне отвечают, что работает уже как полгода. Мне от этого не жарко и не холодно – войти в систему я не могу, появляется страшная ошибка. Пообщавшись, некоторое время, с поддержкой, я получил рекомендацию: «переустановить операционную систему (мало ли что с моими настройками) и обновить браузер IE 6 на IE 5» (еще бы Оперу предложили).

Естественно, рекомендации я выполнять не стал, так как на тот момент уже немного умел программировать. Я просто попросил поменять пароль. Меняли пароль мне дня три. Процедура очень сложная. Отдали в запечатанном конверте, пароль был «123456». После этого я перестал пользоваться услугами этого банка.

В чем же была проблема? В конкатенации строк при построение запроса, который выглядел примерно следующим образом:

“Select count(*) from UserTable where Login=”+login+” and Password=“+password+”

Как вы знаете, текстовые значения в SQL заключаются в апострофы (одинарные кавычки), а мой пароль как раз и содержал апостроф (предположим 123’45). Следовательно, мой запрос выглядел примерно так:

Select count(*) from UserTable where Login=sbad and Password=12345

То есть, в качестве пароля подставлялось 123, а 45’ ассоциировалось с неизвестной командой, что и вызывало ошибку.

Конечно, можно было попробовать в качестве логина (или пароля) ввести одну из двух команд:

“1 or 1=1 —“ – входим в системуJ

“1; drop table UserTable —“ – проверим, случайно не администратор ли используется для входа в системуJ

Естественно, вторая команда работать не будет, если пользователь, под которым работает приложение, имеет минимум прав (то есть не умеет удалять таблицы).

А вот теперь запишем еще два правила, которые следуют из этой истории.

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

Правило 2. Не используйте конкатенацию строк для формирования запросов к БД. На мой взгляд, запросам в коде вообще делать нечего (поэтому я не люблю LINQ).

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

clip_image002

А если Вы используете и Team Foundation Server, то можете сделать прохождение кода через анализатор перед его выгрузкой в хранилище, обязательным правилом – пусть учатся.

Да, я злой:)

Реклама

Written by Sergiy Baydachnyy

29.01.2010 at 20:46

Опубликовано в Security

Tagged with ,

Сборки со строгим именем: повышение уровня безопасности приложения

5 комментариев

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

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

С появлением .NET Framework ситуация кардинально поменялась.

С одной стороны, практически все управляемые библиотеки начали размещать в Глобальном кеше сборок (GAC), который представляет собой целый набор вложенных директорий, количество которых зависит от количества развернутых сборок. Так, каждой сборки соответствует своя директория. При этом задача развертывания ложится на вспомогательные утилиты, такие как gacutil.

С одной стороны, чтобы избежать путаницы, характерной для неуправляемых библиотек, сборки начали делить на два типа: сборки со строгим именем и сборки с нестрогим именем. Сборки с нестрогим именем размещаются только в директории самого приложения и не могут использоваться другими продуктами. Сборки со строгим именем могут быть развернуты в GAC и использоваться всеми приложениями системы. Основное различие между двумя типами сборок состоит в том, что для сборок со строгим именем в качестве имени учитывается не только имя файла (.dll), но и ряд других параметров, которые содержатся внутри сборки: версия сборки, культура сборки (языковая принадлежность) и цифровой ключ. Данные параметры позволяют развернуть несколько сборок с одинаковым именем, но с различными версиями или культурой. Таким образом, более старые приложения могут ссылаться на старые версии сборки, а новые – на более новые. Цифровой ключ позволяет полностью исключить тот вариант, когда две компании поставляют сборки с одним именем, версией и культурой.

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

Правило 1. Всегда старайтесь создавать сборки со строгим именем.

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

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

Сам я принимал участие в создании нескольких приложений, где сборки загружались динамически (например, сборка могла содержать новые отчеты, которые автоматически интегрировались в систему). При таком подходе, сборку подменить очень легко.

Правило 2. Ключ эффективен, если он содержится в безопасном месте.

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

Выделить открытую часть ключа можно следующей командой:

Sn.exe –p «ключ.snk» «открытый ключ.snk»

Настроить компьютеры разработчиков для игнорирования подписи можно с помощью команды:

Sn.exe –Vr «имя сборки» «открытый ключ»

Кроме этого нужно прописать атрибут [assembly: AssemblyDelaySign(true)], говорящий об отложенном подписании сборки.

Written by Sergiy Baydachnyy

29.01.2010 at 15:08

Опубликовано в .NET Development, Security

Tagged with ,