Массачусетский Институт Технологий.
Курс лекций №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 Что же произойдет, если браузер неправильно обработает объект и не сможет определить его тип? В этом случае у вас могут возникнуть проблемы с безопасностью.
Один из них называется MIME-атакой.
Вы, вероятно, знакомы с MIME — типом незашифрованного заголовка, например text/html, image.jpeg и т. д. Итак, старые версии браузера IE использовали это, потому что считали, что такое представление поможет пользователю.
Но иногда случается, что веб-серверы присваивают объектному файлу неправильное расширение.
Неправильно настроенный веб-сервер может прикрепить суффикс .
html к чему-то, что на самом деле имеет расширение .
jpeg, или наоборот, например, создав foo.jpg вместо foo.html. 
Итак, в былые времена IE пытался вам помочь.
То есть он пошел брать какой-то ресурс, при этом думая: «ОК, этот ресурс утверждает, что он такого-то типа, по расширению имени файла».
Но тогда он будет просматривать только первые 256 байтов данного объекта.
И если бы он находил там определенные магические значения, которые указывали на то, что для этого объекта существовал другой тип расширения, он бы просто говорил: «Эй, я нашел здесь кое-что крутое! Я думаю, что веб-сервер неправильно идентифицировал этот объект, поэтому позвольте мне рассматривать этот объект как тип, который я нашел в первых 256 байтах».
И тогда в выигрыше останутся все, потому что тип браузера помог разработчику веб-сервера, поскольку теперь их сайт будет отображаться правильно.
И пользователю это понравится, потому что он сможет разблокировать контент, который раньше был бы просто мусором.
Но это очевидная уязвимость! Предположим, что страница содержит некоторый пассивный контент, например изображение из домена, контролируемого злоумышленником.
Однако страница жертвы думает: «даже если это контент вредоносного хакерского сайта, это всего лишь пассивный контент. Он ничего не может мне сделать!» В крайнем случае неудавшееся изображение будет отображено, но оно не сможет открыть какой-либо код, поскольку пассивный контент не имеет разрешений.
Но дело в том, что IE может сначала «обнюхать» это изображение, его первые 256 байт. А злоумышленник может намеренно разместить там код HTML и JavaScript. Тогда оказывается, что сайт жертвы принесет то, что он считает изображением, а IE выполнит вредоносный код в контексте встроенной страницы.
Это своего рода пример того, насколько сложны браузеры и как добавление даже очень хороших намерений может привести к очень тонким ошибкам безопасности.
Итак, давайте подробнее рассмотрим, как браузер защищает различные ресурсы.
Давайте посмотрим на фреймы и объекты окна (объекты, представляющие окно, содержащее документ DOM).
Фреймы представляют собой независимые вселенные JavaScript, о которых мы здесь говорили.
Я имею в виду, что JavaScript — это экземпляр узла DOM, как показано на рисунке дерева DOM. Таким образом, фрейм будет существовать как объект узла DOM где-то в этой иерархии, видимой для JavaScript. В JavaScript объект окна фактически является псевдонимом глобального пространства имен.
Это звучит как глупая идея.
То есть, если бы вы искали имя глобальной переменной x, вы также смогли бы получить к ней доступ через имя window.x. Таким образом, фреймы и объекты окон являются очень мощными ссылками, предоставляющими вам доступ.
И они содержат указатели друг на друга.
Фрейм может содержать указатель на связанный объект окна и наоборот. По сути, эти две вещи эквивалентны.
И фреймы, и оконные объекты получают источник из фрейма URL-адреса, или, поскольку они всегда находятся в защищенной части сети, они могут получить суффикс исходного доменного имени, то есть его исходное происхождение.
Например, кадр может начинаться так: .
x.y.z.com, здесь на секунду можно игнорировать схему и протокол.
В этом случае источником происхождения (document.domain) можно считать суффикс y.z.com. Аналогично, источником происхождения этого документа будет выражение z.com. Это возможно, поскольку z.com является суффиксом y.z.com. 
Единственное, что не может служить таким источником, — это выражение .
a.y.z.com, поскольку оно является неверным суффиксом происхождения.
Кроме того, правильный суффикс происхождения не должен быть просто .
com, потому что тогда сайт может каким-то образом повлиять на файлы cookie или что-то подобное на любом сайте .
com, что может быть весьма вредным.
Мотивация того, почему подобные вещи допустимы, заключается в том, что они связаны с неким типом существующих доверительных отношений.
Похоже, что с тремя верхними параметрами все в порядке, и единственная проблема — это .
com. Аудитория: получается, что подобные разбиения можно сделать в любой точке или конечной точке? Например, можно ли изменить ваш x.y.z.com на z.com? Профессор: нет, это работает только для каждого балла.
Аудитория: Есть ли причина, по которой не было сделано так, чтобы можно было указать супер- или поддомен, но им как-то приходилось договариваться, откуда будет поступать информация? Допустим, я хочу принимать только вещи, имеющие то же происхождение, что и мое, чтобы любой из этих ресурсов мог на меня напасть.
Более того, мы бы сделали это взаимодействие симметричным, чтобы я тоже мог на него влиять.
В конце концов, исходный суффикс .
com означает, что на меня может повлиять все, что имеет такой же суффикс .
com. Профессор: Да, это сложно, поэтому на этот вопрос есть несколько ответов.
Во-первых, люди были очень обеспокоены возможностью атаки через домен .
com. Поэтому они хотели сделать язык манипулирования предметной областью простым для понимания.
Таким образом, они не позволили сбить настройки.
Через секунду я расскажу об одной вещи, которая позволяет вам делать то, о чем вы говорите, но только в отношении суффиксов домена.
А пока хочу отметить, что интерфейс Post Message позволяет доменам общаться друг с другом, если они согласны на это.
Таким образом, на практике люди используют Post Message для междоменной связи, если они не могут установить одно и то же происхождение, используя приемы, описанные выше.
Таким образом, браузеры могут ограничивать домены в соответствии с этими суффиксами исходного домена.
И еще здесь есть небольшой интересный нюанс — браузеры понимают, когда (document.domain) можно записать, а когда нельзя.
Для этого есть причина, о которой мы поговорим через секунду.
Таким образом, два кадра могут обращаться друг к другу, если выполняется хотя бы одно из двух условий:
- для обоих наборов фреймов (document.domain) установлено одно и то же значение;
- ни один из этих фреймов не может измениться (document.domain), несмотря на то, что значение этого документа в обоих фреймах одинаковое.
Основная идея этих правил заключается в том, что они защищают домен от атак, вызванных его собственными ошибками или вредоносностью одного из поддоменов.
Представьте, что у вас есть домен x.y.z.com, который пытается атаковать домен y.z.com, поскольку первый домен содержит ошибку или является вредоносным.
Он попытается сократить домен y.z.com до .
com, а затем начнет возиться с состоянием JavaScript, файлами cookie или другими вещами.
Итак, эти два правила означают, что если y.z.com не хочет позволять кому-либо взаимодействовать с ним, то он никогда не изменит значение (document.domain).
Поэтому, когда фрейм x.y.z.com захочет его укоротить, браузер скажет: «да, вы хотите его укоротить, но у вас нет на это права!» Здесь есть некоторое совпадение, но домен y.z.com не указал, что хочет участвовать.
Ясно? В этом случае вы можете видеть, что в основном фреймы работают с одной и той же политикой происхождения.
Теперь мы можем увидеть, как обрабатывается наш узел DOM. Это довольно просто.
Обычно узлы DOM получают свое происхождение из окружающего их фрейма.
В случае с файлами cookie все несколько сложнее.
У файлов cookie есть домен и путь.
Например, вы можете представить, что файл cookie может быть связан со следующей информацией, например *.
mit.edu/6.858. В этом случае файл cookie имеет домен *.
mit.edu/ и путь 6.858. 
Обратите внимание, что этот домен может быть полным суффиксом страниц текущего домена.
Таким образом, вы можете проделывать с ним те же трюки, о которых мы говорили ранее.
Обратите внимание, что этот путь 6.858 также может быть представлен в виде косой черты, за которой не следует ничего, что указывает на то, что все пути в домене должны иметь доступ к расположенному здесь файлу cookie. Но в данном случае у нас есть конкретный адрес пути.
Таким образом, тот, кто устанавливает эти файлы cookie, получает возможность увидеть, как выглядят домен и путь.
Причем эти значения можно задавать как на стороне сервера, так и на стороне клиента.
На стороне клиента у вас будет объект JavaScript с именем document.cookie. Это формат, который используется для указания всех путей к похожим объектам.
Для файла cookie можно установить флаг безопасности, чтобы указать, что это файл HTTPS. В таком случае HTTP-контент не должен иметь доступа к этому файлу cookie. Это основная идея файлов cookie. Обратите внимание, что всякий раз, когда браузер генерирует запрос к определенному веб-серверу, он включает в этот запрос все соответствующие файлы cookie. Существуют своего рода строки сопоставления и алгоритмы, позволяющие определить, что это именно те файлы cookie, которые следует отправлять в ответ на запрос, поскольку с суффиксами доменов могут быть странные вещи и так далее.
Аудитория: так могут ли фреймы получать доступ к файлам cookie друг друга, если они соответствуют этим правилам? Профессор: да, фреймы могут это сделать.
Но это зависит от того, как установлены document.domain, домен cookie и путь.
Итак, фреймы могут получать доступ к файлам cookie друг друга, поэтому возникает вопрос: будет ли проблема, если мы позволим произвольному фрейму записывать произвольные файлы cookie людям? Скажем так, будет плохо.
Причина, по которой это плохо, заключается в том, что эти файлы cookie позволяют клиентской стороне приложения хранить пользовательские данные.
Итак, вы можете себе представить: если злоумышленник смог контролировать или переопределить файлы cookie пользователя, то он мог бы, например, изменить файл cookie для Gmail, чтобы пользователь входил в систему с учетной записью Gmail, принадлежащей этому злоумышленнику.
В этом случае любое письмо пользователя может быть прочитано злоумышленником.
Можете ли вы себе представить, что кто-то сможет украсть файлы cookie с Amazon.com, чтобы положить в вашу корзину всевозможные нелепые покупки и тому подобное? Таким образом, файлы cookie являются очень важным ресурсом защиты.
И многие атаки на сетевую безопасность направлены на их кражу и использование для причинения вреда.
Есть еще один интересный вопрос, связанный с файлами cookie. Допустим, у вас есть сайт foo.co.uk. Что, если сайт с этим именем хоста сможет установить файлы cookie для сайта co.uk? 
Здесь есть тонкость, связанная с правилами, о которых мы говорили ранее, потому что первый сайт должен иметь возможность сокращать свой домен и устанавливать куки для второго, тут вроде все легально.
Но с человеческой точки зрения мы относимся к этому с подозрением, поскольку понимаем, что co.uk — это единый атомный домен.
Однако он эквивалентен .
com. Можно сказать, что британцы облажались, что они должны быть в этом правы.
Но это не их вина.
С моральной точки зрения это единая сфера, которую нельзя разбить.
Поэтому нам нужна специальная инфраструктура для правильной настройки файлов cookie. У Mozilla есть сайт publicsuffix.org, который содержит списки правил сокращения файлов cookie, происхождения и доменов, признавая, что в некоторых вещах могут быть точки, хотя на самом деле их следует рассматривать как единое атомарное целое.
Поэтому, когда ваш браузер выяснит, как ему следует обрабатывать различные файлы cookie, ему придется проверить эту сторону проблемы.
Или как-то сделать так, чтобы foo.co.uk не мог сократить домен до co.uk. Так что здесь очень деликатный вопрос.
Есть еще много интересных проблем веб-безопасности, которые мы обнаруживаем в процессе работы, поскольку большая часть исходной инфраструктуры была разработана специально для английского языка.
Например, текст ASCII или что-то в этом роде.
Первоначально он не был предназначен для использования международным сообществом.
Но по мере того, как Интернет становился все более популярным, люди начали говорить: «Эй, вначале мы создали довольно большой дизайн решения, а теперь нам нужно сделать его пригодным для использования людьми, которые вынуждены использовать наше узкое понимание того, что означает этот язык».
Итак, сейчас мы столкнулись со всеми этими сумасшедшими проблемами.
Давайте посмотрим, как ответы XML HTTP обрабатываются той же политикой происхождения.
По умолчанию JavaScript может сгенерировать один из них, только если он построен на исходном сервере.
Однако существует новый интерфейс под названием Cross Origin Request или CORS.
Итак, это одно и то же происхождение, если только сервер не включил эту функцию CORS. По сути, добавляется новый заголовок ответа HTTP под названием Access-Control-Allow-Origin. 
Допустим, JavaScript с сайта foo.com хочет отправить HTTP-запрос XML на bar.com. Как описано в правилах, здесь происходит перекрестное происхождение.
И если сервер bar.com захочет это разрешить, он вернет свой HTTP-ответ с заголовком: «да, я разрешаю foo.com отправлять мне эти XML HTTP-запросы с перекрестным происхождением».
Фактически сервер bar.com может ответить «нет», то есть отклонить запрос.
В этом случае браузер не сможет выполнить HTTP-запрос XML. Так что это своего рода новая вещь, которая возникла в основном из-за смешанного применения.
Он нужен приложениям от разных разработчиков и разных доменов, чтобы они могли обмениваться данными друг с другом.
Таким образом, вместо foo.com здесь могут быть звездочки, если кто-то хочет получить данные из разных источников и так далее.
Я думаю, это довольно просто.
Есть масса других ресурсов, на которые мы могли бы обратить внимание, например изображения.
С помощью Access-Control-Allow-Origin фрейм может загружать изображения из любого источника, который пожелает. Но он не может проверить биты этого образа, поскольку считается, что при разных политиках происхождения проверять содержимое файлов друг друга нецелесообразно.
Хотя фрейм не может проверять биты, он все равно может определить размер изображений, поскольку видит, как они расположены на странице.
Итак, это еще один из странных случаев, когда одна и та же политика происхождения якобы пытается предотвратить все утечки информации.
Но на самом деле оно не может предотвратить всего этого, поскольку встроенное наследование по сути раскрывает определенные типы информации.
CSS похож на изображения, поэтому в фрейм можно встроить CSS из любого источника.
Однако он не может напрямую проверить текст внутри файла CSS, если он взят из другого источника.
Но он может распознать, что делает этот CSS, потому что он просто создает группу узлов, а затем наблюдает за изменением их стиля.
И это выглядит немного странно.
JavaScript — мой любимый пример того, как эта же политика происхождения пытается поддерживать любой тип интеллектуальной согласованности.
Идея здесь в том, что если вы выполняете перекрестную выборку JavaScript, то это разрешено.
Вы можете разрешить запуск внешнего JavaScript в контексте вашей страницы, но не сможете просматривать исходный код. 
Таким образом, если у вас есть источник тега сценария, равный чему-то за пределами вашего домена, то при выполнении этого источника вы можете вызывать для него функции.
Однако вы не сможете просмотреть в нем исходный код JavaScript. Все выглядит очень хорошо, но имеет много дыр.
Например, JavaScript — это динамический язык сценариев.
А функции — это первоклассные объекты.
Таким образом, для любой функции f вы можете просто использовать функцию f.tostring(), и это даст вам исходный код функции f. И люди делают это постоянно: динамически переписывают и тому подобное.
Таким образом, хотя политика происхождения не позволяет вам напрямую просматривать содержимое тега скрипта, вы можете просто выполнить указанную операцию и получить исходный код.
Точно так же вы можете получить свой домашний сервер из своего домена, чтобы просто загрузить на него исходный код, а затем отправить его обратно вам.
По сути, вы просто попросили свой домашний сервер запустить программу Wget, чтобы таким образом получить исходный код. Так это тоже выглядит немного глупо, то есть политика происхождения здесь немного странная.
Аудитория: Давайте предположим, что причина, по которой они это делают, заключается в том, чтобы запретить пользователю получать JavaScript, поскольку тогда файлы cookie также могут быть отправлены.
То есть пользователь сможет адаптировать полученный JavaScript под свои нужды.
Профессор: Да, это.
Аудитория: поэтому, если вы заставите свой сервер делать что-то подобное, он не сможет предоставить вам специальные файлы cookie. Профессор: Это правда, хотя на практике необработанный исходный код не предназначен для изменения пользователем.
Но вы правы, это предотвратит некоторые атаки.
Таким образом, поскольку пользователь или приложение могут легко получить исходный код JavaScript, во время развертывания этот же код маскируется и минимизируется.
Поэтому, если вы когда-нибудь пытались посмотреть, как работает веб-страница, то есть пытались взглянуть на ее механизм, вы могли бы увидеть просто сплошной белый прямоугольник.
Иногда люди также меняют все имена переменных на очень короткие, которые будут выглядеть как символы восклицательного знака, подобно тому, как анимированные персонажи ругаются в мультфильмах.
Так что это своего рода обманная форма управления цифровыми правами.
Но в конечном итоге все это не имеет большого значения, поскольку вы можете запустить этот код в своем браузере.
Если люди используют какую-то обфускацию веб-страницы или что-то подобное, они часто пытаются скрыть некоторые секреты в своем HTML или JavaScript. Возможно, они хотят скрыть протокол, если клиент использует его для связи с сервером.
Часто минимизация имен переменных используется просто для уменьшения времени загрузки страницы.
Итак, с JavaScript мы разобрались, а теперь посмотрим, что такое плагины.
Они похожи на Java, поэтому фрейм может легко запускать плагин из любого источника.
В наши дни плагины подобны динозаврам, потому что в HTML5 встроено множество новых функций, таких как видеотеги и тому подобное, которые могут делать то же, что и автономные плагины Java. Поэтому неясно, как долго плагины смогут просуществовать.
Помните, что когда ваш браузер отправляет HTTP-запрос, он автоматически включает соответствующие файлы cookie. Что же произойдет, если вредоносный сайт сгенерирует URL-адрес, похожий на этот? 
Например, он создает новый дочерний фрейм с URL-адресом bank.com. Затем он пытается смоделировать действия браузера при переводе денег пользователя кому-то другому.
Итак, в этом URL-адресе, в этом кадре, который пытается создать хакер, он хочет инициировать команду на перевод 500 долларов пользователя на его банковский счет. Теперь пользователь вынужден посетить страницу злоумышленника, поскольку хакер перенаправил его туда.
Но что интересно, даже если страница злоумышленника не сможет увидеть содержимое этого дочернего фрейма, поскольку он будет иметь другое происхождение, страница bank.com все равно будет делать то, что хочет злоумышленник, поскольку браузер отправляет все файлы cookie пользователя вместе с этим запросом.
Он посмотрит на эту команду и скажет: «Да, наверное, пользователь просит меня перевести 500 долларов этому загадочному пользователю по имени злоумышленник! Хорошо, я это сделаю".
Вот тут-то и возникает проблема.
Эта атака работает, потому что, по сути, злоумышленник может на опыте определить, как должна выглядеть эта команда.
В этой команде нет случайности.
По сути, злоумышленник может попробовать это на своем собственном банковском счете, выяснить, как выглядит протокол, а затем каким-то образом обманом заставить браузер пользователя выполнить действие по переводу на имя злоумышленника.
Это то, что называется подделкой межсайтовых запросов, сокращенно CSRF. Вы можете исключить возможность такого типа атаки, включив некоторую случайность в сгенерированный URL-адрес.
Случайность такого типа, которую злоумышленник не может угадать статически.
Представьте, что на веб-странице банка есть форма.
Форма — это то, что фактически генерирует тот же запрос, что и в нашем случае:
И внутри этой формы у нас будут входные данные, которые обычно используются для ввода текста, нажатий клавиш, щелчков мыши и тому подобного.<form action = “/transfer.cdi”…>
Фактически, мы можем сделать этот ввод скрытым, чтобы он не отображался на странице пользователя: input type="hidden", присвойте ему имя атрибута="csrf" и случайное значение value="a72f.".
Эта форма будет создана на сервере.
Поэтому, когда пользователь заходит на эту страницу, на стороне сервера сервер генерирует это значение случайности = "a72f." и встраивает его в HTML, который получает пользователь.
Итак, когда пользователь заполняет эту форму, этот URL-адрес выглядит так: bank.com/xferЭamount=500&to=злоумышленник
Завершено случайным жетоном: http://bank.com/xferЭamount=500&to=attacker/&csrf=a72f .
Это означает, что злоумышленник теперь должен иметь возможность угадать конкретный токен, который сервер генерирует для пользователя каждый раз, когда он заходит на страницу банка.
То есть если у нас достаточно случайное значение, то хакер не сможет ничего подделать, потому что если он укажет неверный токен, то правила сервера отклонят его запрос.
58:00 мин.
Продолжение: Курс MIT «Безопасность компьютерных систем».
Лекция 8: Модель сетевой безопасности, часть 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 евро за копейки? Теги: #информационная безопасность #программирование #ИТ-инфраструктура #Анализ и проектирование систем #Интернет-безопасность #Интернет-безопасность #Интернет-безопасность #Атака переполнения буфера #Атака переполнения буфера #Атака переполнения буфера #MIME #MIME #MIME
-
Чпу Становится Мейнстримом
19 Oct, 24 -
Клетка
19 Oct, 24 -
Ро.ри.ре
19 Oct, 24 -
Http/1.1 Обновлен
19 Oct, 24 -
Covid-Индустрия И Системы Распознавания
19 Oct, 24 -
Marmalade Framework (Режим Паузы)
19 Oct, 24
