Курс Mit «Безопасность Компьютерных Систем». Лекция 9: Безопасность Веб-Приложений, Часть 2

Массачусетский Институт Технологий.
Курс лекций №6.858. «Безопасность компьютерных систем».
Николай Зельдович, Джеймс Микенс.
2014 год Безопасность компьютерных систем — это курс, посвященный проектированию и внедрению безопасных компьютерных систем.
Лекции охватывают модели угроз, атаки, ставящие под угрозу безопасность, а также методы обеспечения безопасности, основанные на последних научных работах.
Темы включают безопасность операционной системы (ОС), возможности, управление информационными потоками, языковую безопасность, сетевые протоколы, аппаратную безопасность и безопасность веб-приложений.
Лекция 1: «Введение: модели угроз» Часть 1 / Часть 2 / Часть 3 Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3 Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3 Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3 Лекция 5: «Откуда берутся ошибки системы безопасности» Часть 1 / Часть 2 Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3 Лекция 7: «Нативная клиентская песочница» Часть 1 / Часть 2 / Часть 3 Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3 Лекция 9: «Безопасность веб-приложений» Часть 1 / Часть 2 / Часть 3 Например, Django возьмет эти угловые скобки, переведет их в форму HTML и переделает остальные символы.
То есть, если значение имени пользователя содержит угловые скобки, двойные кавычки и т.п.
, все эти символы будут исключены.
Это гарантирует, что контент не будет интерпретироваться как HTML-код на стороне браузера клиента.

Итак, теперь мы знаем, что это не очень надежная защита от некоторых атак с использованием межсайтовых сценариев.
Причина, как мы показали в примере, в том, что эти грамматики для HTML, CSS и JavaScript настолько сложны, что могут очень легко запутать парсер браузера.
Например, у нас есть очень распространенная вещь, которая делается в Django. Итак, у вас есть функция div, и мы хотим присвоить ей динамический класс.
Мы присваиваем классу значение var и так далее и тому подобное.
Идея состоит в том, что когда Django обрабатывает это, он должен определить текущий стиль и затем вставить его сюда.
В этом случае злоумышленник может создать строку, определяющую этот класс, например, написать «класс 1».
До этого момента все идет хорошо, потому что это выглядит как допустимое выражение CSS. Но затем злоумышленник помещает сюда оператор onclick, аналогичный коду JavaScript, который выполняет системный вызов.

Поскольку это неверно, браузеру следует просто остановиться на этом этапе.
Но проблема в том, что если вы когда-либо видели HTML-код настоящей веб-страницы, он весь сломанный и запутанный, даже для законных, «благонамеренных» сайтов.
Поэтому, если браузер останавливается при каждом ошибочном операторе HTML, ни один веб-сайт, который вам нравится, просто никогда не будет работать.
Если вам когда-нибудь захочется отказаться от мира, а я вам недостаточно помог, просто откройте консоль JavaScript в браузере во время просмотра сайта, чтобы увидеть, сколько ошибок он вам выдает. Вы можете, например, зайти на сайт CNN и просто посмотреть, сколько ошибок вы получите.
Да, CNN в принципе работает, но очень неравномерно.
Например, для открытия Acrobat Reader требуется постоянно генерировать исключения нулевого указателя, и при этом вы чувствуете себя немного обманутым жизнью.
Но в Интернете мы научились принимать это без особого возмущения.
Итак, поскольку браузеры должны быть вполне терпимы к такого рода вещам, они попытаются превратить вредоносный код во что-то, что им покажется разумным.
И в этом кроется уязвимость безопасности.
Вот как работает очистка контента, и это все равно лучше, чем ничего.
Она может подхватить много нехорошего, но защититься от всего не сможет. Еще одна вещь, о которой следует подумать, — это использование менее выразительного языка разметки.
Давайте посмотрим, что это значит. Аудитория: что делать, если очистка контента не работает? Профессор: да, такое возможно, например, в этом случае Джанго не сможет статически определить, что это плохо.
Например, в данном конкретном случае.
Но в случае, когда я вставляю вредоносный тег изображения.
Аудитория: в этом конкретном случае я ожидаю, что назначение класса будет заключено в кавычки и в этом случае не должно иметь никакого эффекта.
Профессор: Ну, видите ли, там есть маленькие хитрости.
Если мы предположим, что грамматика HTML и CSS тщательно определена, то мы можем представить себе мир, в котором идеальные парсеры могли бы каким-то образом уловить эти проблемы или каким-то образом преобразовать их в нормальные вещи.
Но на самом деле грамматики HTML и CSS страдают от неточностей.
Кроме того, браузеры не реализуют эту спецификацию.
Поэтому, если мы будем использовать менее выразительную грамматику, нам будет гораздо легче очистить контент. Здесь используется термин Markdown — «удобно читаемая разметка» вместо термина Markup — обычная разметка.
Основная идея Markdown заключается в том, что он спроектирован как язык, который, например, позволяет пользователям оставлять комментарии, но не включает в себя возможность использования пустого тега, поддержку апплетов и тому подобное.
Таким образом, в Markdown на самом деле гораздо проще однозначно определить грамматику, а затем просто применить ее.

Гораздо проще провести санацию на простом языке, чем на полноценном HTML, CSS и JavaScript. В каком-то смысле это похоже на разницу между пониманием кода C и кода Python. На самом деле есть большая разница в понимании более выразительного языка.
Таким образом, ограничивая выразительность, вы часто повышаете безопасность.
CSP, политика безопасности контента, также используется для защиты от атак с использованием межсайтовых сценариев.
Идея CSP заключается в том, что он позволяет веб-серверу.
Аудитория: Мне просто интересно узнать об этом языке Markdown. Все ли браузеры умеют анализировать язык? Профессор: нет нет нет. Просто в HTML можно конвертировать разные типы языков, но браузеры их не понимают в исходном виде.
Другими словами, у вас есть система отправки комментариев, и она использует Markdown. То есть комментарии перед отображением на странице попадают в компилятор Markdown, который переводит их в формат HTML. Аудитория: так почему бы не всегда использовать Markdown? Профессор: Markdown допускает встроенный HTML, и, насколько мне известно, есть способ отключить его в компиляторе.
Но я могу ошибаться на этот счет. Дело в том, что не всегда можно использовать ограниченную лексику, да и не все хотят это делать.
Итак, продолжим разговор о том, как повысить безопасность с помощью Content Security Policy. Эта политика позволяет серверу сообщать веб-браузеру, какие типы контента можно загружать на страницу, которую он отправляет обратно, а также откуда этот контент должен поступать.
Например, в ответе HTTP сервер может использовать что-то вроде этого: он включает заголовок Content – Security – Policy, источник self по умолчанию и будет принимать данные от *.
mydomain.com.

С помощью оператора self сервер указывает, что контент с этого сайта должен поступать только из домена определенной страницы или любого поддомена mydomain.com. Это означает, что если бы мы самостоятельно привязались к foo.com, сервер отправил бы эту страницу обратно в браузер.
Допустим, атака с использованием межсайтового скриптинга пытается создать ссылку на bar.com. В этом случае браузер увидит, что bar.com не является собственным и не является доменом mydomain.com, и не будет передавать этот запрос дальше.
Это довольно мощный механизм, в котором можно указать более детальное управление.
Вы задаете параметры, которые указывают, что ваши изображения должны быть из такого-то источника, скрипты из такого-то и так далее.
На самом деле это удобно.
Кроме того, эта политика фактически запрещает встроенный JavaScript, поэтому вы не можете открыть тег, написать какой-либо скрипт и закрыть тег, поскольку все, что может войти в браузер, должно происходить только из проверенного источника.
CSP предотвращает такие опасные вещи, как использование аргумента функции eval(), которая позволяет веб-странице выполнять динамически генерируемый код JavaScript. Поэтому, если установлен заголовок CSP, браузер не будет выполнять функцию eval().
Аудитория: Это все, от чего защищает CSP? Профессор: Нет. Существует целый список ресурсов, которые он действительно защищает, и вы можете настроить защиту от множества нежелательных вещей, например указать, откуда именно вам разрешено принимать исходящий CSS, и множество других вещей.
Аудитория: но помимо eval() есть и другие вещи, угрожающие безопасности? Профессор: да, они существуют. Поэтому всегда возникает вопрос о полноте защиты.
Так, например, не только eval может динамически генерировать код JavaScript. Также есть конструктор функций, есть определенные способы вызвать заданный таймаут, вы переходите на строку и таким образом можете анализировать код. CSP может отключить все эти опасные векторы атак.
Но это не панацея для полной изоляции вредоносных эксплойтов.
Аудитория: Правда ли, что CSP можно настроить так, чтобы предотвратить проверку всех внутренних скриптов на странице? Профессор: да, это помогает предотвратить выполнение динамически сгенерированного кода, а встроенный код следует игнорировать.
Браузер всегда должен получать код из исходного атрибута.
На самом деле я не знаю, все ли браузеры делают это.
Личный опыт показывает, что браузеры ведут себя по-разному.
В целом интернет-безопасность сродни естественной науке, поэтому люди просто выдвигают теории о том, как работают браузеры.
И тогда вы увидите, как это происходит на самом деле.
А реальная картина может разочаровать, ведь нас учат, что существуют алгоритмы, доказательства и тому подобное.
Но эти браузеры настолько плохи, что их результаты могут быть непредсказуемыми.
Разработчики браузеров стараются быть на шаг впереди злоумышленников, и примеры этого вы увидите далее в лекции.
CSP на самом деле очень крутая штука.
Еще одна полезная вещь заключается в том, что сервер может установить HTTP-заголовок под названием X-Content-Type-Options, значение которого равно nosniff.

Этот заголовок не позволяет MIME отбрасывать ответ из объявленного типа контента, поскольку заголовок инструктирует браузер не переопределять тип контента ответа.
При использовании опции nosniff, если сервер сообщает, что содержимое имеет формат text/html, браузер отобразит его как text/html. Проще говоря, этот заголовок не позволяет браузеру «обнюхивать» ответ от объявленного типа контента, чтобы не возникало ситуации, когда браузер говорит: «Да, я учуял несоответствие между расширением файла и фактическим содержимым.
поэтому я превращу этот контент во что-то другое, понятное».
вещь для меня.
» В этом случае окажется, что вы внезапно отдали ключи от королевства варварам.
Таким образом, устанавливая этот заголовок, вы говорите браузеру не делать ничего подобного.
Это может существенно смягчить последствия некоторых типов атак.
Вот краткий обзор некоторых уязвимостей к атакам с использованием межсайтовых сценариев.
Теперь давайте посмотрим на другой популярный вектор атаки — SQL. Вы, наверное, слышали об атаке под названием SQL-инъекция.
Суть этих атак заключается в использовании базы данных сайта.
Для динамического построения страницы, показываемой пользователю, необходимы запросы к базе данных, отправляемые на этот внутренний сервер.
Представьте, что у вас есть запрос на выборку всех значений из определенной таблицы, где поле User ID равно тому, что определено в Интернете из потенциально ненадежного источника.

Мы все знаем, чем закончится эта история – она закончится очень плохо, выживших здесь не останется.
Потому что то, что исходит из непроверенного источника, может доставить массу неприятностей.
В качестве альтернативы вы можете присвоить строке идентификатора пользователя следующее значение: user id = « 0; УДАЛЕНИЕ ТАБЛИЦЫ.
Так что же здесь произойдет? По сути, база данных сервера скажет: «Хорошо, я установлю идентификатор пользователя равным нулю, а затем введу команду «удалить таблицу».
И все, вы закончили! Говорят, пару лет назад появилось некое вирусное изображение.
Некоторые люди в Германии ставят на автомобили номерные знаки с надписью 0; УДАЛЕНИЕ ТАБЛИЦЫ.
Идея заключалась в том, что дорожные камеры используют оптическое распознавание символов OCR для распознавания вашего номерного знака, а затем помещают этот номер в базу данных.
В общем, люди из Volkswagen решили воспользоваться этой уязвимостью, разместив на своих номерных знаках вредоносный код. Я не знаю, сработало ли это, потому что это звучит забавно.
Но мне хотелось бы верить, что это правда.
Итак, еще раз, идея очистки состоит в том, чтобы предотвратить показ контента из ненадежных источников на вашем сайте.

Поэтому обратите внимание, что некоторые простые вещи могут работать не так, как должны.
Итак, вы можете подумать: «Хорошо, почему я не могу просто поставить еще одну кавычку в начале строки, а другую в конце, тем самым не позволяя злоумышленнику выполнить вредоносный код между тройными кавычками»? идентификатор пользователя = '' + идентификатор пользователя + '' Но это не сработает, поскольку злоумышленник всегда может просто поставить кавычки внутри строки атаки.
Так что в большинстве случаев такого рода «полувзлом» не принесет вам такой безопасности, как вы ожидаете.
Решение здесь заключается в том, что вам необходимо тщательно зашифровать свои данные.
Опять же, когда вы получаете информацию из ненадежного источника, не вводите ее в систему как есть.
Убедитесь, что он не сможет покинуть песочницу, если вы поместите его туда для выполнения вредоносного эксплойта.
Например, вы хотите вставить escape-функцию, чтобы предотвратить использование оператора запятой в исходном виде.
Чтобы добиться этого, многие веб-фреймворки, такие как Django, имеют встроенные escape-библиотеки SQL, чтобы предотвратить подобные вещи.
Эти структуры поощряют разработчиков никогда напрямую не взаимодействовать с базой данных.
Например, сам Django предоставляет высокоуровневый интерфейс, который выполняет очистку за вас.
Но людей всегда беспокоит производительность, и иногда они думают, что эти веб-фреймворки слишком медленные.
Итак, как вы вскоре увидите, люди по-прежнему будут выполнять необработанные SQL-запросы, что может привести к проблемам.
Проблемы могут возникнуть, если веб-сервер принимает пути от ненадежных изображений.
Представьте, что где-то на вашем сервере вы делаете что-то вроде этого: открываете с помощью «www/images/» + имя файла, где имя файла представлено чем-то вроде .
/.
/.
/.
/etc/password.

То есть вы даете команду на открытие изображения по этому адресу из недоверенного пользовательского файла, что в реальности может вам серьезно навредить.
Итак, если вы хотите использовать веб-сервер или веб-фреймворк, вы должны иметь возможность обнаруживать эти опасные символы и экранировать их, чтобы предотвратить выполнение этих необработанных команд. Давайте отвлечемся от обсуждения очистки контента и поговорим немного о файлах cookie. Файлы cookie — это очень популярный способ управления сеансами, позволяющий привязать пользователя к набору ресурсов, существующих на стороне сервера.
Многие фреймворки, такие как Django или Zoobar, с которыми вы познакомитесь позже, фактически помещают в файл cookie случайный идентификатор сеанса.
Идея состоит в том, что этот идентификатор сеанса является индексом некоторой серверной таблицы: таблица [идентификатор сеанса] = информация о пользователе.
То есть идентификатор сеанса равен некоторой информации о пользователе.
В результате этот идентификатор сеанса и файлы cookie по их расширению являются очень конфиденциальными вещами.
Многие атаки включают кражу файлов cookie для получения этого идентификатора сеанса.
Как мы обсуждали в прошлой лекции, та же самая политика происхождения может в определенной степени помочь вам в борьбе с некоторыми из этих атак, связанных с кражей файлов cookie. Потому что существуют правила, основанные на той же политике происхождения, которые предотвращают произвольное изменение файлов cookie. Тонкость в том, что не следует делить домен или поддомен с кем-то, кому вы не доверяете.
Потому что, как мы говорили в прошлой лекции, существуют правила, которые позволяют двум доменам или поддоменам одного и того же происхождения получать доступ к файлам cookie друг друга.
Таким образом, если вы доверяете домену, которому не следует доверять, он может напрямую установить идентификатор сеанса в тех файлах cookie, к которым у вас обоих есть доступ.
Это позволит злоумышленнику заставить пользователя использовать идентификатор сеанса по выбору злоумышленника.

Предположим, злоумышленник устанавливает файл cookie пользователя Gmail. Пользователь входит в Gmail и вводит несколько писем.
Затем злоумышленник может использовать этот файл cookie, в частности использовать этот идентификатор сеанса, загрузить Gmail, а затем получить доступ к Gmail, как если бы он или она был пользователем-жертвой.
Таким образом, с помощью этих файлов cookie можно выполнить множество тонкостей для управления сеансами.
О некоторых из них мы поговорим сегодня и в последующих лекциях.
Может быть, вы думаете, что можно просто избавиться от файлов cookie? Ведь они приносят больше проблем, чем пользы.
Почему их нельзя оставить? Давайте представим себе существование файлов cookie без сохранения состояния, чтобы каким-то образом полностью избавиться от концепции сеансов и предотвратить этот неприятный вектор атаки, который, кажется, доминирует во всех наших обсуждениях.
Итак, основная идея заключается в том, что если вы не хотите сохранять состояние запроса, вы должны аутентифицировать каждый запрос.
Таким образом, полезное свойство файлов cookie заключается в том, что они следуют за вами, куда бы вы ни пошли.
Итак, вы проходите аутентификацию один раз, а затем в каждом последующем запросе у вас есть этот маленький токен.
Но если вы хотите избавиться от этих вещей, вам, по сути, необходимо иметь доказательства своего авторитета в каждом вашем запросе.
Один из способов сделать это — использовать так называемый MAC — коды аутентификации сообщений или коды аутентификации сообщений.
Это своего рода хэш, для которого требуется ключ.
Этот код содержит хэш определенного ключа HCK и некоторого сообщения m. Основная идея заключается в том, что клиент, пользователь и сервер разделяют друг с другом секретный ключ K. Таким образом, клиент использует этот ключ для создания подписи сообщения, которое он отправляет на сервер.
И тогда сервер, который также знает этот ключ, может затем использовать эту же функцию для проверки действительности подписи.

Давайте посмотрим на конкретном примере, как это работает. Некоторые из реальных сервисов, использующих файлы cookie без сохранения состояния, — это интернет-сервисы Amazon, например x3. По сути, веб-сервис Amazon, назовем его AWS, дает каждому пользователю две вещи.
Первый — это секретный ключ K, второй — идентификатор пользователя AWS, который не является секретным.

И поэтому каждый раз, когда вы хотите отправить запрос в AWS через HTTP, вам придется отправлять его в специальном формате.
Например, если вы хотите получить доступ к фотографиям кошек, неудивительно, что ваша первая строка будет такой: ПОЛУЧИТЬ /фотографии/кот; .
jpg HTTP/1.1, за которым следует строка с хоста с именем какого-либо сервера AWS: HOST: — — — — — и третья строка с датой, например: ДАТА: Пн, 4 июня, и в самом конце у вас будет строка с полем авторизации, местом, где находится код аутентификации сообщения.
Он состоит из части, которая представляет ваш идентификатор пользователя, и части, которая выглядит как случайная строка букв и представляет собой подпись.

Так как же выглядит эта подпись? По сути, эта подпись находится над строкой, которая инкапсулирует множество деталей этого запроса из трех верхних строк.
По сути, строка авторизации String To Sign выглядит примерно так: — HTTP-глагол, в нашем случае это GET; — контрольная сумма содержимого сообщения MDS; — тип контента, например изображение html или jpg; - Дата; — это имя ресурса, которое, по сути, является путем, который вы видите здесь.

Другими словами, эта строка представляет сообщение, которое вы передаете на HCK MAC. Обратите внимание, что сервер видит все это в запросе в открытом виде.
Это позволяет серверу проверить правильность кода аутентификации сообщения, поскольку сервер делится этим ключом с пользователем.
Таким образом, этот метод позволяет серверу проверять данный тип материала.
Ясно? В данном случае для контента это выглядит как пустая строка, но вы можете представить это как сообщение или что-то в этом роде.
Вчера я проверил документацию Amazon и убедился, что они по-прежнему используют файлы cookie без сохранения состояния, поскольку алгоритм хеширования MD5 — не лучший вариант в данном случае.
Чтобы избежать путаницы, основная идея состоит в том, что мы хотим избавиться от концепции постоянного файла cookie, который повсюду следует за пользователем.
Но это создает проблему: серверу теперь нужен способ определить, с каким клиентом он разговаривает. Для этого вам необходимо предоставить каждому клиенту уникальный ключ, который он будет использовать вместе с сервером.
Всякий раз, когда клиент отправляет сообщение серверу, он отправляет вместе с ним специальную криптографическую операцию «HCK, m».

В обычном мире вместо авторизации здесь использовались бы файлы cookie. Но теперь мы избавляемся от них и вставляем в запрос открытое текстовое сообщение GET /photos/cat; .
jpg HTTP/1.1 и шифрование, позволяющее серверу определить, от кого эта вещь.
Таким образом, сервер знает, кто является пользователем, поскольку это встроено в запрос.
Это не секрет, правда? Но это позволяет серверу сказать: «Да, я знаю, какой секретный ключ должен был использовать этот пользователь для выполнения этого запроса, если это настоящий пользователь».
56:15 Курс MIT «Безопасность компьютерных систем».
Лекция 9: Безопасность веб-приложений, часть 3 Доступна полная версия курса Здесь .
Спасибо, что остаетесь с нами.
Вам нравятся наши статьи? Хотите увидеть больше интересных материалов? Поддержите нас, разместив заказ или порекомендовав друзьям, Скидка 30% для пользователей Хабра на уникальный аналог серверов начального уровня, который мы придумали для вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от 20$ или как правильно расшарить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40 ГБ DDR4).
VPS (KVM) E5-2650 v4 (6 ядер) 10 ГБ DDR4 240 ГБ SSD 1 Гбит/с бесплатно до декабря при оплате на срок от шести месяцев и более вы можете заказать здесь .
Dell R730xd в 2 раза дешевле? Только здесь 2 x Intel Dodeca-Core Xeon E5-2650v4 128 ГБ DDR4 6x480 ГБ SSD 1 Гбит/с 100 ТВ от 249 долларов США в Нидерландах и США! Прочтите об этом Как построить корпоративную инфраструктуру класса, используя серверы Dell R730xd E5-2650 v4 стоимостью 9000 евро за копейки?

Теги: #информационная безопасность #программирование #ИТ-инфраструктура #Анализ и проектирование систем #csp #heartbleed #shellshock #веб-безопасность #межсайтовый скриптинг #межсайтовый скриптинг #межсайтовый скриптинг #Атака с помощью SQL-инъекций #Атака с помощью SQL-инъекций # файлы cookie без сохранения состояния #cookie без сохранения состояния