Ответ 1

Всегда есть способ взломать ваш код javascript и знать бэкдоры для ваших сервисов и API.

JavaScript представляет несколько новых проблем для сервисов и API, которые уже доступны в Интернете. Ваш сервер/служба не должны слепо доверять запросам из Интернета, поэтому использование javascript не изменяет вашу позицию безопасности, но это может усыпить людей ложным чувством безопасности, заставив их думать, что они управляют пользовательским агентом.

Основное правило защиты клиент/сервер остается прежним: не доверяет пользовательскому агенту; поместите сервер и клиент на разные стороны граница доверия.

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

Проверять все, что сервер получает от клиента, и, поскольку уязвимости XSS являются общими и позволяют клиентам получать доступ к информации, отправленной клиенту, отправлять как можно меньше конфиденциальной информации клиенту.

Когда вам нужно объединить данные с сервера на клиент и обратно, вы можете использовать различные методы.

• Криптографически подписать данные, чтобы сервер мог убедиться, что он не был изменен.
• Храните данные в боковой таблице и отправляйте непрозрачный неопознанный идентификатор.

Когда вам нужно отправить конфиденциальные данные клиенту, у вас также есть множество стратегий:

• Храните данные в файлах cookie, поддерживающих HTTP, которые привязаны к запросам, но которые не читаются JavaScript.
• Разделите своего клиента на iframe по отдельному происхождению и секвестрируйте конфиденциальную информацию в iframe, которая особенно тщательно проверена и имеет минимальную избыточную функциональность.

Заключение

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

Криптографическое подписание "сквозных" данных хорошо объясняется документами Django, которые также описывают, как их API можно использовать.

Золотое правило безопасности веб-приложений - никогда не доверять данным из ненадежных источников. Иногда бывает полезно передавать данные через ненадежную среду. Криптографически подписанные значения могут быть переданы через безопасный ненадежный канал, зная, что будет обнаружено какое-либо вмешательство.

Django предоставляет как низкоуровневый API для подписи значений, так и API высокого уровня для настройки и чтения подписанных файлов cookie, одного из наиболее распространенных способов использования подписи в веб-приложениях.

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

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

Непрозрачные идентификаторы

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

Боковые таблицы с непрозрачными, неопознанными, идентификаторами можно легко понять, посмотрев на эту диаграмму

     Server DB Table

+--------------------+---------------------+
| Opaque Primary Key | Sensitive Info      |
+--------------------+---------------------+
| ZXu4288a37b29AA084 | The king is a fink! |
| ...                | ...                 |
+--------------------+---------------------+

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

Если у клиента есть ключ, все, что им известно, это то, что у них есть случайное число, и, возможно, это то же самое, что и какое-то другое случайное число, которое они получили от вас, но не могут получать из него контент.

Если они меняют (отсылают другой ключ), то это не будет в вашей таблице (с очень высокой вероятностью), поэтому вы обнаружите фальсификацию.

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

HTTP файлы cookie

Когда вы отправляете секретный код для каждого пользователя, который не хочет, чтобы он случайно попадал в другие пользовательские агенты, то cookie только для HTTP является хорошим вариантом.

Если флаг HttpOnly (необязательный) включен в заголовок ответа HTTP, к файлу cookie не может быть обращена клиентская сторона script (опять же, если браузер поддерживает этот флаг). В результате, даже если существует недостаток межсайтового скриптинга (XSS), и пользователь случайно обращается к ссылке, которая использует этот недостаток, браузер (в первую очередь Internet Explorer) не будет показывать cookie третьей стороне.

HttpOnly файлы cookie широко поддерживаются в современных браузерах.

Последовательные iframe

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

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

Защитный шаблон: разделение [VM02]

Проблема

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

Решение

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

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

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

Но что, если вы хотите получить некоторые данные между двумя отдельными окнами? Например, документ zwibbler может быть длинным мегабайтом при преобразовании в строку. Я хочу, чтобы содержащая веб-страница могла получить копию этой строки, когда захочет, чтобы она могла ее сохранить. Кроме того, он должен иметь доступ к сохраненному PDF, PNG или SVG-изображению, которое пользователь производит. HTML5 предоставляет ограниченный способ связи между различными кадрами одного и того же окна, называемым window.postMessage().

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

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

Некоторые недостатки:

• Запуск приложения сложнее, потому что нет единого события "load".
• Для обмена iframe требуется передать строки, которые необходимо проанализировать, поэтому для чувствительного к безопасности кадра все еще необходимо использовать безопасные методы синтаксического анализа (нет eval строки из postMessage.)
• Рамки iframe являются прямоугольными, поэтому, если чувствительный к безопасности фрейм должен представить пользовательский интерфейс, то он может легко не подходить аккуратно к более широкому пользовательскому интерфейсу приложения.