Web безопасность: от уязвимостей до мониторинга / Хабр

от уязвимостей до мониторинга / Хабр

Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.

OWASP TOP 10 (на всякий случай)

• А1 Инъекции — Уязвимости, связанные с внедрением SQL, NoSQL, OS и LDAP. Возникают, когда непроверенные данные отправляются интерпретатору в составе команды или запроса. Вредоносные данные могут заставить интерпретатор выполнить непредусмотренные команды или обратиться к данным без прохождения соответствующей авторизации.
• А2 Недостатки аутентификации — Функции приложений, связанные с аутентификацией и управлением сессиями, часто некорректно реализуются, позволяя злоумышленникам скомпрометировать пароли, ключи или сессионные токены, а также эксплуатировать другие ошибки реализации для временного или постоянного перехвата учетных записей пользователей.
• А3 Разглашение конфиденциальных данных — Многие веб-приложения и API имеют плохую защиту критичных финансовых, медицинских или персональных данных. Злоумышленники могут похитить или изменить эти данные, а затем осуществить мошеннические действия с кредитными картами или персональными данными. Конфиденциальные данные требуют дополнительных мер защиты, например их шифрования при хранении или передаче, а также специальных мер предосторожности при работе с браузером.
• А4 Внедрение внешних сущностей XML — Старые или плохо настроенные XML-процессоры обрабатывают ссылки на внешние сущности внутри документов. Эти сущности могут быть использованы для доступа к внутренним файлам через обработчики URI файлов, общие папки, сканирование портов, удаленное выполнения кода и отказ в обслуживании.
• А5 Недостатки контроля доступа — Действия, разрешенные аутентифицированным пользователям, зачастую некорректно контролируются. Злоумышленники могут воспользоваться этими недостатками и получить несанкционированный доступ к учетным записям других пользователей или конфиденциальной информации, а также изменить пользовательские данные или права доступа.
• А6 Некорректная настройка параметров безопасности — Некорректная настройка безопасности является распространенной ошибкой. Это происходит из-за использования стандартных параметров безопасности, неполной или специфичной настройки, открытого облачного хранения, некорректных HTTP-заголовков и подробных сообщений об ошибках, содержащих критичные данные. Все ОС, фреймворки, библиотеки и приложения должны быть не только настроены должным образом, но и своевременно корректироваться и обновляться.
• А7 Межсайтовое выполнение сценариев — XSS имеет место, когда приложение добавляет непроверенные данные на новую вебстраницу без их соответствующей проверки или преобразования, или когда обновляет открытую страницу через API браузера, используя предоставленные пользователем данные, содержащие HTML- или JavaScript-код. С помощью XSS злоумышленники могут выполнять сценарии в браузере жертвы, позволяющие им перехватывать пользовательские сессии, подменять страницы сайта или перенаправлять пользователей на вредоносные сайты.
• А8 Небезопасная десериализация — Небезопасная десериализация часто приводит к удаленному выполнению кода. Ошибки десериализации, не приводящие к удаленному выполнению кода, могут быть использованы для атак с повторным воспроизведением, внедрением и повышением привилегий.
• А9 Использование компонентов с известными уязвимостями — Компоненты, такие как библиотеки, фреймворки и программные модули, запускаются с привилегиями приложения. Эксплуатация уязвимого компонента может привести к потере данных или перехвату контроля над сервером. Использование приложениями и API компонентов с известными уязвимостями может нарушить защиту приложения и привести к серьезным последствиям.
• А10 Недостатки журналирования и мониторинга — Недостатки журналирования и мониторинга, а также отсутствие или неэффективное использование системы реагирования на инциденты, позволяет злоумышленникам развить атаку, скрыть свое присутствие и проникнуть в другие системы, а также изменить, извлечь или уничтожить данные. Проникновение в систему обычно обнаруживают только через 200 дней и, как правило, сторонние исследователи, а не в рамках внутренних проверок или мониторинга.

OWASP Top 10 в формате PDF.

Распространенные уязвимости

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

Инъекции

Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.

SQLi: http://example.com/?id=1' union select 1,2,version(),4
RCE: http://example.com/search.php?q=;+cat+/etc/passwd

XSS

Межсайтовый скриптинг — уязвимость, встречающаяся на данный момент куда реже, чем раньше, если верить рейтингу OWASP Top 10, но несмотря на это не стала менее опасной для веб-приложений и пользователей. Особенно для пользователей, ведь атака XSS нацелена именно на них. В общем случае злоумышленник внедряет скрипт в веб-приложение, который срабатывает для каждого пользователя, посетившего вредоносную страницу.

http://example.com/?search=<script>alert('xss')</script>

LFI/RFI

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

http://example.com/?search=/../../../../../../etc/passwd

Атаки через JSON и XML

Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.

JSON

JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.

JSON чаще всего ассоциируется с API, тем не менее, часто используется даже в обычных и хорошо известных веб-приложениях. Например, редактирование материалов в WordPress производится именно через отправку запросов в формате JSON:

POST /index. php?rest_route=%2Fwp%2Fv2%2Fposts%2F12&_locale=user HTTP/1.1
Host: wordpress.example.com
...
%Другие заголовки%
...

{"id":12,"title":"test title","content":"test body","status":"publish"}

JSON Injection

Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:

• Сервер хранит пользовательские данные в виде строки JSON, включая тип учетной записи;
• Имя пользователя и пароль берутся непосредственно из пользовательского ввода без очистки;
• Строка JSON формируется с помощью простой конкатенации:

  $json_string = '{"account":"user","user":"'.$_GET['user'].'","pass":"'.$_GET['pass'].'"}'</code>;</li>
  	<li>Злоумышленник добавляет данные к своему имени пользователя: 
  <code>john%22,%22account%22:%22administrator%22</code></li>
  	<li>Результирующая строка JSON:
         <code>
         {
         "account":"user",
         "user":"john",
         "account":"administrator",
         "pass":"password"
         }

• При чтении сохраненной строки парсер JSON (json_decode) обнаруживает две account-записи и берет последнюю, предоставляя права администратора пользователю john.

Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:

JSON Hijacking

Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:

• Атакующий создает в

о технологиях веб-безопасности / Блог компании RUVDS.com / Хабр

Автор материала, перевод которого мы публикуем сегодня, говорит, что существует множество причин изучать веб-безопасность. Например, вопросами безопасности интересуются пользователи веб-сайтов, которых беспокоит возможность кражи их персональных данных. Безопасность заботит веб-разработчиков, которые стремятся к повышению уровня защиты создаваемых ими проектов. То же самое можно сказать и о начинающих программистах, которые ищут работу и готовятся к собеседованиям. Цель этой статьи заключается в том, чтобы понятным языком рассказать о некоторых важных технологиях веб-безопасности. Прежде чем приступить к разговору об этих технологиях, при упоминании которых обычно оперируют сокращениями вроде CORS, CSP и HSTS, рассмотрим пару базовых концепций безопасности.

Две базовых концепции веб-безопасности

▍100% защита — это миф

В мире безопасности нет такого понятия, как «100% защита от взлома». Если кто-нибудь когда-нибудь скажет вам о таком уровне защиты, знайте, что он ошибается.

▍Одного уровня защиты недостаточно

Предположим, некто полагает, что реализовав CSP, он полностью защитил свой проект от XSS-атак. Возможно, кто-то воспринимает то, что абсолютной защиты не существует, как данность, но мысли, подобные вышеописанной, могут посетить кого угодно. Если вести речь о программистах, которые решили разобраться в вопросах безопасности, то, возможно, причиной возникновения таких мыслей является тот факт, что, при написании программного кода, они, в основном, оперируют такими понятиями, как «чёрное» и «белое», 1 и 0, «истинно» и «ложно». Но в безопасности не всё так просто.

Технологии веб-безопасности

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

▍CORS

Видели когда-нибудь такую ошибку:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Встретившись с подобным, вы думаете, что вы, уж точно, не первый, с кем это случилось. Погуглив, вы выясняете, что, для того, чтобы эту проблему решить, достаточно установить некое расширение. Ну не замечательно ли? Однако технология CORS (Cross-Origin Resource Sharing, совместное использование ресурсов между разными источниками) существует не для того, чтобы мешать разработчикам, а для того, чтобы защищать их проекты.

Для того чтобы понять, как CORS позволяет защищать веб-проекты, сначала поговорим о куки-файлах, в частности — о куки, используемых для аутентификации пользователей. Подобные куки используются, при работе с неким веб-ресурсом, для того, чтобы сообщить серверу о том, что пользователь вошёл в систему. Они автоматически отправляются с запросами, выполняемыми к соответствующему серверу.

Предположим, вы вошли в свою учётную запись на Facebook, при этом Facebook использует аутентификационные куки. Работая в интернете, вы щёлкаете по ссылке bit.ly/r43nugi, вас перенаправляют на некий вредоносный сайт, скажем, на что-то вроде superevilwebsite.rocks. Скрипт, загруженный вместе со страницей этого сайта, выполняет клиентский запрос к facebook.com, используя ваш аутентификационный куки-файл.

В мире, где не было бы CORS, скрипт с superevilwebsite.rocks мог бы скрытно внести изменения в ваш FB-профиль, мог бы украсть какую-то информацию, со всеми вытекающими отсюда последствиями. В таком мире легко могла бы возникнуть «эпидемия superevilwebsite.rocks», когда скрипт, захватывающий управление аккаунтом пользователя, публикует на его странице ссылку, перейдя по которой друзья этого пользователя, «заражаются» сами, а через ссылки, опубликованные на их страницах, эпидемия, в итоге, охватывает весь Facebook.

Однако в мире, где есть CORS, Facebook разрешал бы только запросы на изменение данных учётных записей с источником facebook.com. Другими словами, администрация сайта ограничила бы совместное использование ресурсов между разными источниками.

Тут у вас может возникнуть следующий вопрос: «Но ведь superevilwebsite.rocks может просто изменить заголовок источника в своих запросах, и они будут выглядеть так, будто идут от facebook.com?».

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

«А что если superevilwebsite.rocks выполнит подобный запрос с сервера?», — спросите вы.

В подобной ситуации CORS можно обойти, но никакого толку от этого не будет, так как, выполняя запрос с сервера, нельзя будет передать Facebook аутентификационный куки-файл. Поэтому скрипту, для успешного выполнения подобного запроса, необходимо выполняться на стороне клиента и иметь доступ к куки-файлам, хранящимся на клиенте.

▍CSP

Для того чтобы разобраться в том, что такое CSP (Content Security Policy, политика защиты контента), сначала надо поговорить об одной из самых распространённых веб-уязвимостей. Речь идёт о XSS (cross-site scripting, межсайтовый скриптинг).

При выполнении XSS-атаки злоумышленник внедряет специальный JavaScript-код в клиентскую часть некоего сайта. Можно подумать: «Ну и что будет делать этот скрипт? Менять цвета элементов страниц?».

Предположим, что некто успешно внедрил свой JS-скрипт в страницы сайта, на который вы зашли. Что опасного может сделать подобный скрипт? На самом деле, много всего:

• Он может выполнять HTTP-запросы к другим сайтам, притворяясь, что делаете их вы.
• Он может перенаправить вас на сайт, который выглядит точно так же как тот, на который вы вошли, но рассчитан, например, на кражу учётных данных.
• Он способен добавлять на страницы теги <script>, содержащие некий JavaScript-код или рассчитанные на на загрузку каких-то JS-файлов.
• Он может добавить на страницу элемент <iframe>, который будет, например, выглядеть в точности так же, как поля для ввода имени и пароля для входа на сайт. При этом настоящие поля для ввода таких данных будут скрыты.

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

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

• Ограничения на то, что может быть открыто в <iframe>.
• Ограничения на то, какие таблицы стилей могут быть загружены.
• Ограничения на то, какие запросы можно выполнять.

Как же работает CSP?

Когда вы щелкаете по ссылке или вводите URL веб-сайта в адресной строке браузера, браузер выполняет GET-запрос. Запрос приходит на сервер, который передаёт браузеру некий HTML-код вместе с HTTP-заголовками. Если вам интересно посмотреть на эти заголовки — откройте, в инструментах разработчика браузера, вкладку Network, и посетите несколько сайтов. Заголовок ответа может выглядеть примерно так:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Это — политика безопасности контента facebook. com. Преобразуем её к более удобному для чтения виду:

content-security-policy:
default-src * data: blob:;
script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';
style-src data: blob: 'unsafe-inline' *;
connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Рассмотрим представленные здесь директивы CSP:

• default-src — запрещает всё, что не задано в явном виде.
• script-src — вводит ограничения на загружаемые скрипты.
• style-src — вводит ограничения на загружаемые таблицы стилей.
• connect-src — вводит ограничения на URL, ресурсы с которых которые могут быть загружены с использованием скриптовых интерфейсов, таких, как fetch, XHR, ajax, и так далее.

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

Если CSP-заголовка у страницы нет, тогда никаких запретов к ней не применяется. Символы * в CSP-заголовке — это подстановочные знаки. Такой знак можно заменить чем угодно, и то, что получится, окажется разрешённым.

▍HTTPS

Наверняка вы слышали об HTTPS (HTTP Secure). Возможно, вам доводилось встречать примерно такие высказывания: «Зачем мне беспокоиться об HTTPS, если я просто играю в игру на сайте?». Или, возможно, вы сталкивались с такой идеей: «Если у вас нет HTTPS — то это просто безумие. На дворе 2018 год! Не верьте никому, кто говорит, что без HTTPS можно обойтись».

Возможно, вы слышали о том, что теперь Chrome маркирует сайт как небезопасный, если он не использует HTTPS.

Основное отличие HTTPS от HTTP заключается в том, что, при передаче данных по HTTPS они зашифровываются, а при передаче по HTTP — нет.

Почему на это стоит обращать внимание при передаче ценных данных? Всё дело в том, что при организации обмена данными по незащищённому каналу связи существует возможность MITM-атаки (Man In The Middle, атака посредника, или атака «человек посередине»).

Если вы, сидя в кафе, выходите в интернет через открытую точку доступа Wi-Fi, кто-то, довольно просто, может прикинуться маршрутизатором, через который идут все ваши запросы и ответы. Если ваши данные не зашифрованы, то посредник может сделать с ними всё, что ему вздумается. Скажем, он сможет редактировать HTML, CSS или JavaScript-код прежде чем он поступит с сервера в ваш браузер. Учитывая то, что мы уже знаем о XSS-атаках, вы можете представить, к каким последствиям это может привести.

«Как же это возможно: мой компьютер и сервер знают, как шифровать и дешифровать данные, которыми мы обмениваемся, а посредник-злоумышленник — нет?», — спросите вы. Это возможно благодаря использованию протокола SSL (Secure Sockets Layer) и более свежего протокола TLS (Transport Layer Security). TLS заменил SSL в 1999 году в качестве технологии шифрования, используемой в HTTPS. Обсуждение особенностей TLS выходит за рамки этого материала.

▍HSTS

Технология HSTS (HTTP Strict-Transport-Security, механизм принудительной активации защищённого соединения через протокол HTTPS) устроена довольно просто. В качестве примера снова рассмотрим соответствующий заголовок Facebook:

strict-transport-security: max-age=15552000; preload

Проанализируем его:

• max-age задаёт время, в течение которого браузер должен принудительно переводить пользователя на работу с веб-сайтом по HTTPS.
• preload — для наших целей это не важно.

Этот заголовок применяется только в том случае, если вы получаете доступ к сайту с использованием HTTPS. Если вы работаете с сайтом через HTTP, данный заголовок игнорируется. Причина этого весьма проста: обмен данными по HTTP защищён настолько слабо, что подобному заголовку нельзя доверять.

Снова прибегнем к примеру с Facebook для демонстрации практической полезности механизма HSTS. Предположим, вы в первый раз входите на facebook.com и при этом знаете, что HTTPS безопаснее, чем HTTP, поэтому вы используете такую ссылку: https://facebook.com. Когда ваш браузер получает HTML-код, он получает и заголовок, который сообщает браузеру о том, что он должен принудительно переводить вас на HTTPS при выполнении будущих запросов. Через месяц кто-то отправляет вам HTTP-ссылку на Facebook, http://facebook.com, и вы по ней щёлкаете. Так как месяц — это меньше, чем срок в 15552000 секунд, заданный директивой max-age, браузер отправит запрос по HTTPS, предотвращая потенциальную MITM-атаку.

Итоги

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

Уважаемые читатели! Сталкивались ли вы со случаями безответственного отношения к безопасности со стороны веб-разработчиков?

основы защиты сайтов, серверов и приложений

От автора: азы CORS, CSP, HSTS и всех акронимов веб-безопасности для веб-разработчиков!

Существует много причин узнать про веб безопасность больше:

Вы обеспокоенный пользователь, который боится кражи своих персональных данных

Вы заинтересованный веб-разработчик, который хочет сделать свои веб-приложения более безопасными

Вы — веб-разработчик, ищущий работу, и хотите быть готовым к тому, что ваши интервьюеры зададут вам вопросы о безопасности в Интернете.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

и так далее.

Ну, в этом посте мы объясним некоторые общие аббревиатуры веб-безопасности таким образом, который легко понять, но при этом точным.

Прежде чем мы это сделаем, давайте убедимся, что мы понимаем пару основных концепций безопасности.

Две основные концепции безопасности

Никто никогда не будет на 100% в безопасности.

Нет такого понятия, как 100-процентая защита от взлома. Если кто-нибудь когда-нибудь скажет вам это, они ошибаются.

Одного слоя защиты недостаточно.

Вы не можете просто сказать …

О, так как я реализовал CSP, я в безопасности. Я могу вычеркнуть межсайтовый скриптинг из списка уязвимостей своего сайта, потому что этого не может произойти сейчас.

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

Мы начнем с того, с чем все сталкиваются довольно рано в процессе веб-разработки.

Совместное использование ресурсов между разными источниками (Cross-Origin Resource Sharing — CORS)

Вы когда-нибудь получали ошибку, которая выглядела примерно так?

No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access.

Вы, конечно, в этом не одиноки. И тогда вы заходите в Google и ищете ответы, и кто-то говорит вам, что нужно установить это расширение, которое решит все ваши проблемы! Отлично, правда?

CORS предназначен для того, чтобы защитить вас, а не навредить вам!

Чтобы объяснить, как CORS помогает вам, давайте сначала поговорим о файлах cookie, в частности об аутентификационных файлах cookie. Аутентификационные файлы cookie используются, чтобы сообщить серверу, что вы вошли в систему, и они автоматически отправляются с любым запросом, который вы выполняете к этому серверу.

Допустим, вы вошли в систему Facebook, и они используют для аутентификации файлы cookie. Вы нажимаете на bit.ly/r43nugi, который перенаправляет вас на superevilwebsite.rocks. Скрипт в superevilwebsite.rocks выполняет клиентский запрос к facebook.com, который отправляет ваш файл cookie для аутентификации!

В мире без CORS они могут вносить изменения в ваш аккаунт, даже без вашего ведома. Затем они опубликуют bit.ly/r43nugi в вашей ленте, и все ваши друзья кликнут по этой ссылке, а затем bit.ly/r43nugi будет отправлено в ленты всех ваших друзей, и этот порочный круг расширится, пока весь мир не будет охвачен superevilwebsite.rocks.

Однако в мире CORS Facebook разрешает для редактирования данных на своем сервере только запросы с источником facebook.com. Другими словами, они ограничивают совместное использование ресурсов с помощью разных источников. Тогда вы можете спросить …

Ну может ли superevilwebsite.rocks просто изменить исходный заголовок на их запрос, чтобы он выглядело так, как будто он идет с facebook. com?

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

Хорошо, но что, если superevilwebsite.rocks сделал запрос на стороне сервера?

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

Политика безопасности контента (CSP)

Чтобы понять, что такое CSP, нам сначала нужно поговорить об одной из наиболее распространенных уязвимостей в Интернете: XSS, которая означает межсайтовый скриптинг (вау — еще одна аббревиатура).

XSS — это когда какой-то злой человек вводит JavaScript в ваш клиентский код. Вы можете подумать…

Что они собираются сделать? Изменить цвет с красного на синий?

Предположим, что кто-то успешно ввел JavaScript в клиентский код веб-сайта, который вы посещаете. Что они могут сделать, что навредит вам?

Они могут создать HTTP-запросы на другой сайт, притворяясь вами.

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

Они могут добавить тег скрипта со встроенным JavaScript.

Они могут добавить тег скрипта, который откуда-то извлекает удаленный файл JavaScript.

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

Возможности безграничны. CSP пытается предотвратить это, ограничивая:

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

что можно открыть в iframe

какие таблицы стилей можно загрузить

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

Итак, как это работает?

Когда вы нажимаете на ссылку или набираете URL-адрес веб-сайта в адресной строке браузера, ваш браузер выполняет GET-запрос. Он в конечном итоге пробивается к серверу, который обслуживает HTML вместе с некоторыми HTTP-заголовками. Если вам интересно, какие заголовки вы получаете, откройте вкладку «Сеть» в консоли и посетите любые веб-сайты.

Вы можете увидеть заголовок ответа, который выглядит так:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* ‘unsafe-inline’ ‘unsafe-eval’ *.atlassolutions.com blob: data: ‘self’;style-src data: blob: ‘unsafe-inline’ *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com ‘self’ chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

content-security-policy: default-src * data: blob:;script-src *. facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* ‘unsafe-inline’ ‘unsafe-eval’ *.atlassolutions.com blob: data: ‘self’;style-src data: blob: ‘unsafe-inline’ *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com ‘self’ chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Это политика безопасности контента на facebook.com. Давайте переформатируем этот код, чтобы его было легче читать:

content-security-policy:

default-src * data: blob:;

script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* ‘unsafe-inline’ ‘unsafe-eval’ *.atlassolutions.com blob: data: ‘self’;

style-src data: blob: ‘unsafe-inline’ *;

connect-src *. facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com ‘self’ chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

content-security-policy:   default-src * data: blob:;   script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* ‘unsafe-inline’ ‘unsafe-eval’ *.atlassolutions.com blob: data: ‘self’;   style-src data: blob: ‘unsafe-inline’ *;   connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com ‘self’ chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

Теперь давайте разложим директивы.

default-src ограничивает все другие директивы CSP, которые явно не указаны.

script-src ограничивает скрипты, которые могут быть загружены.

style-src ограничивает таблицы стилей, которые могут быть загружены.

connect-src ограничивает URL-адреса, которые могут быть загружены с использованием интерфейсов скриптов, XHR, ajax и т. д.

Обратите внимание, что здесь гораздо больше директив CSP, чем эти три. Браузер прочитает заголовок CSP и применит эти директивы ко всему в HTML-файлу, который был доставлен. Если директивы установлены надлежащим образом, они допускают только то, что необходимо.

Если заголовка CSP нет, тогда все разрешено, и ничего не ограничено. Везде, где вы видите *, это шаблон. Вы можете представить себе *, как замену на что угодно, и это будет разрешено.

HTTPS или HTTP Secure

Конечно, вы слышали о HTTPS. Возможно, вы слышали, как говорят некоторые люди …

Зачем мне обращать внимание на HTTPS, если я просто играю на сайте в игру.

Или, может быть, вы слышали другую сторону…

Вы сумасшедший, если на вашем сайте нет HTTPS. Это 2018 год! Не доверяйте никому, кто говорит иначе.

Возможно, вы слышали, что Chrome теперь будет помечать сайт как небезопасный, если на нем нет HTTPS.

По своей сути HTTPS довольно прост. HTTPS зашифрован, а HTTP — нет. Так почему это важно, если вы не отправляете конфиденциальные данные? Приготовьтесь к другому сокращению… MITM, что означает «Человек в середине».

Если вы используете в кафе общественный Wi-Fi без пароля, для кого-то очень просто сделать так, что он будет действовать, как ваш роутер, чтобы все запросы и ответы проходили через него. Если ваши данные не зашифрованы, они могут делать с ними все, что захотят. Они могут редактировать HTML, CSS или JavaScript, прежде чем те попадут в ваш браузер. Учитывая то, что мы знаем о XSS, вы можете себе представить, насколько это плохо.

Хорошо, но как получается, что мой компьютер и сервер знают, как шифровать / расшифровывать, а этот MITM не знает?

Вот где в дело вступает протокол SSL (Secure Sockets Layer), а в последнее время TLS (Transport Layer Security). TLS взяла на себя роль SSL в 1999 году в качестве технологии шифрования, используемой в HTTPS. Конкретно то, как работает TLS, выходит за рамки этой публикации.

HTTP Strict-Transport-Security (HSTS)

Это довольно просто. Давайте снова используем заголовок Facebook:

strict-transport-security: max-age=15552000; preload

strict-transport-security: max-age=15552000; preload

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

preload не важен для наших целей. Это сервис, размещенный Google, а не часть спецификации HSTS.

Этот заголовок применяется только в том случае, если вы получили доступ к сайту с помощью HTTPS. Если вы получили доступ к сайту через HTTP, заголовок игнорируется. Причина в том, что HTTP настолько небезопасен, что ему нельзя доверять.

Давайте используем пример Facebook, чтобы еще раз пояснить, насколько это полезно на практике. Вы впервые заходите на facebook.com, и знаете, что HTTPS безопаснее, чем HTTP, поэтому вы обращаетесь к нему через HTTPS, //facebook.com. Когда ваш браузер получает HTML-код, он получает и заголовок, который указывает вашему браузеру принудительно перенаправить вас на HTTPS для будущих запросов. Через месяц кто-то отправит вам ссылку на Facebook с HTTP, //facebook.com, и вы нажмете на нее. Поскольку один месяц меньше, чем 15552000 секунд, указанных в директиве max-age, ваш браузер отправит запрос в виде HTTPS, предотвращая потенциальную MITM-атаку.

Заключение

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

Автор: Austin Tackaberry

Источник: //medium.freecodecamp.org/

Редакция: Команда webformyself.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Безопасность и защита сайта от угроз и взлома

Прямо сейчас посмотрите видео

Смотреть

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

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

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

То есть причинами угроз безопасности — взломов и утечек данных — могут быть:

• Уязвимости самого сайта / приложения перед кибератакой — например, отсутствие защиты от перебора паролей, возможность внедрения стороннего кода (XSS, SQL-инъекции, отсутствие защиты от CSRF)
• Недостаточное быстродействие системы или повышенная ресурсоёмкость обработки запросов, что приводит к уязвимости к атакам типа «отказ в обслуживании» — (D)DoS
• Ошибки, допущенные администратором веб-сервера — несвоевременное обновление ПО или небезопасное конфигурирование сервисов
• Незнание или несоблюдение сотрудниками банальных правил безопасности — простые пароли, ввод данных на фишинговых сайтах, заражение вирусами ПК.

Рекомендации

• Доверяйте разработку требовательных к уровню безопасности сервисов опытным специалистам. Новички, как правило, могут добиться работоспособности приложения, но не в состоянии учесть риски взлома и атак типа «отказ в обслуживании».
• Администрированием сервера должен на регулярной основе заниматься компетентный специалист, большинство заражений сайтов вирусами происходит из-за того, что серверное ПО никто не обновляет, а очень много утечек данных связаны с неверным конфигурированием серверных служб (из банального — открытые «в мир» порты систем хранения).
• Обучайте пользователей основам информационной безопасности, урезайте права до необходимого для работы минимума и используйте мониторинг доступа к чувствительной информации. Огромное количество проблем связано именно с некомпетентностью нетехнического персонала, возникающих как из-за банальной некомпетентности (попался на фишинг, «случайно» удалил данные), так и по злому умыслу (хищение клиентской базы, слив заказов конкурентам и т. д.)
• Если вас мучают сомнения о безопасности вашего сайта, то закажите аудит безопасности у независимой компании. Мы на своей практике были по обе стороны этого процесса — и мы проверяли сторонние разработки на уязвимости, и разработанные нами системы проверяли — особенно много и тщательно в банковской / финансовой сфере.

Спасите сайт! 10 советов по безопасности веб-приложений

Занимаетесь развитием своего или чужого сайта? Ваш ресурс под угрозой! В этой статье об улучшении безопасности веб-приложений.

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

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

Тотальных способов защиты нет, но можно снизить риск. Здесь собрано 10 наиболее важных рекомендаций по безопасности веб-приложений. Обязательны к ознакомлению.

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

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

Единого плана не может быть, но если вы не знаете с чего начать, стоит опираться на чек-лист Synopsis. В нём рассказывается о шести ключевых этапах обеспечения безопасности.

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

Как много инструментов используется в работе компании? Не знаете? А зря: вероятно, вы тоже используете не совсем «чистые» приложения. Они незаметны до тех пор, пока всё работает хорошо. Рассчитывать на эффективную защиту, не зная точно, какие приложения использует ваша компания, опасно.

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

После инвентаризации существующих веб-приложений идет их сортировка в порядке важности. Разделите приложения на 3 категории: критические, важные, обычные.

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

Важные приложения − приложения могут быть внутренними или внешними и содержат конфиденциальную информацию.

Обычные приложения − не подвержены серьёзным уязвимостям, но стоит иметь в виду как потенциальный источник утечки.

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

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

Устранить все уязвимости из всех веб-приложений нереально! Не тратьте на это время. Даже после классификации ваших приложений в соответствии с их важностью потребуется много времени для их тестирования.

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

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

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

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

Что делать, если администратор заблокирует нужную функцию? Придётся сообщить ему об этом, объяснить, зачем функция нужна, подождать, пока он снова её активирует. Да, это долго, зато безопасно.

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

1. Заблокируйте некоторые функции в отдельных приложениях. Если какая-то из функций делает приложение более уязвимым для атак, отключите её на время. Конечно, если она не является основной в приложении.
2. Используйте брандмауэр веб-приложений (WAF) для защиты от самых неприятных уязвимостей. WAF фильтрует и блокирует нежелательный HTTP-трафик, поступающий в веб-приложение, помогает защитить от XSS, внедрения SQL и многого другого.

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

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

Хотя вам, разумеется, не нужно прекращать использование файлов cookie. Просто измените настройки, чтобы минимизировать риск атак.

1. Во-первых, никогда не используйте куки для хранения конфиденциальной или критически важной информации − для запоминания паролей пользователей, так как это позволяет хакерам невероятно легко получить несанкционированный доступ.
2. Кроме того, следует ограничить срок действия файлов cookie. Месяца вполне достаточно.
3. Наконец, рассмотрите возможность шифрования информации, хранящейся в используемых вами файлах cookie.

Есть еще несколько советов по безопасности веб-приложений, которые стоит рассмотреть. Решите для себя, какие из мер ниже подходят вам, а какие не очень:

• Реализуйте HTTPS и перенаправьте весь HTTP-трафик на HTTPS.
• Предотвратите атаки межсайтовых скриптов, используя HTTP-заголовки − x-xss-protection.
• Организуйте политику безопасной работы с контентом.
• Активируйте HTTP Public Key Pinning.
• Примените SRI к <script> или <link> элементам.
• Используйте обновленную версию TLS. Чтобы узнать больше, почитайте статью TLS 1.2 против TLS 1.1 и перестаньте использовать SSL.
• Это самое очевидное − используйте надежные пароли из разных символов. Для создания и хранения советуем использовать KeyPass.

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

Обученные сотрудники смогут сами обнаруживать базовые уязвимости. Информирование всех о важности безопасности веб-приложений − это простой способ вовлечь всех в процесс поиска и устранения уязвимостей. Наймите специалиста или договоритесь с кем-нибудь внутри команды, чтобы разъяснить основные принципы безопасности.

Отличный спо

30 ресурсов по безопасности, которые точно пригодятся

По мере развития индустрии специалисты по безопасности черпают все новую и новую информацию. Но как понять, что знаний достаточно?

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

В этой статье Кейд Кэрнс из ThoughtWorks и Дэниел Сомерфилд из New Relic описали восемь фишек безопасности при создании веб-приложений.

Эта статья поможет понять и разобраться в HTTPS и CSP, а также узнать, как определить, был ли взломан ваш сайт, и что с этим делать.

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

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

Эта часто рекомендуемая книга была написана специалистами по безопасности Microsoft Майклом Ховардом и Дэвидом Лебланом. Наряду с методами безопасного кодирования, книга охватывает следующие темы:

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

Джим Берд, технический директор BIDS Trading Technologies, говорит, что хоть книге и 15 лет, но основы безопасности программного обеспечения остаются неизменными.

В OWASP Top 10 перечислены наиболее распространенные на сегодняшний день угрозы безопасности в веб-приложениях. Несмотря на то, что некоторые специалисты уже устали слышать о Топ 10, есть веская причина, по которой эксперты по безопасности считают его одним из самых важных ресурсов в области безопасного кодирования. OWASP Top 10 является самым фундаментальным ресурсом по безопасности приложений, поэтому каждый уважающий себя специалист должен напрямую с ним работать. Список был обновлен в 2017 году, но он не сильно изменился за последнее десятилетие.

В OWASP также есть список Топ-10 угроз безопасности мобильных устройств. Мобильная безопасность требует уникального направления исследований, поэтому в дополнение к чтению этих ресурсов, не забудьте закрепить пройденный материал.

Эта книга написана работниками Microsoft и генеральным директором Capsule 8. Она посвящена стандартным угрозам, когда дело доходит до недостатков безопасности в вашем коде. В ней можно найти и некоторые угрозы из OWASP, а также несколько других угроз, которые не входят в Top 10 OWASP.

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

Это список наиболее распространенных угроз безопасности. Он включает в себя более 700 слабых мест, которые можно увидеть в исследованиях и разработках. Ресурс также полезен для разработчиков, которые хотят узнать о CVE.

Базовые знания безопасного кодирования безусловно важны, но также нужно знать, какие инструменты и процессы могут обеспечить безопасность кода на протяжении всего жизненного цикла разработки программного обеспечения. Эта книга от BIDS Trading Technologies’ Bird даст ясную практическую картину нескольких современных цепочек безопасного жизненного цикла и процессов, вдохновленных Etsy, Netflix и другими технически сильными, очень успешными компаниями.

Эта книга написана Лауром Белом, Ричем Смитом, Майклом Брунтоном-Споллом и Джимом Бердом. Она расширяет темы, описанные в книге DevSecOps, которая готовит специалистов ко многим техническим и организационным проблемам, с которыми они могут столкнуться при создании безопасного ПО.

Проверка кода — важный шаг в обнаружении уязвимостей системы безопасности. Изучение того, как искать эти самые уязвимости, повысит шансы разработчиков избегать подобных ошибок.

Моделирование угроз — это то, что могут понять даже гуманитарии, работающие в Вашей организации. Шон Галлахер, редактор по информационной безопасности в Ars Technica, написал эту статью, чтобы каждый мог смоделировать конкретные ситуации.

OWASP Application Threat Modeling — это ресурс моделирования угроз. Он работает в три этапа:

• анализ приложения
• определение степени угрозы
• определение мер устранения или смягчения проблемы.

Джоанна Куриэль, специалист по безопасности приложений в банковской сфере, рекомендует OWASP, так как ресурс охватывает широкий спектр тем в области безопасности: безопасность PHP, защита iOS и Android, XML, saml и многое другое.

В статье Дэнни Диллона, главного специалиста по безопасности EMC, объясняется, почему разработчикам необходимо пользоваться моделированием угроз. Автор описывает уникальный подход EMC к этому делу и объясняет, почему этот процесс должен быть полезен даже инженерам-программистам, у которых нет опыта в области безопасности.

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

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

Гайд по защитному программированию с примерами на C, C++, Java, Python, Shell/Bash, Go и Vala. Руководство от Red Hat также включает в себя инструкции о том, как реализовать, например, аутентификацию и авторизацию.

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

Диего Мариани – инженер-программист на сайте Busuu. Он совмещает несколько старых и современных идей о защитном программировании в короткую статью с примерами из PHP. В статье также рассматриваются ключевые моменты небезопасного защитного программирования.

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

Бесплатный онлайн-курс, который отлично подходит для начала обучения безопасному кодированию. Он начинается с основ кибербезопасности и общих уязвимостей веб-приложений, а затем переходит к обнаружению, устранению и созданию уязвимостей. Далее курс затрагивает такие темы:

• безопасная архитектура
• сетевая безопасность
• криптография
• тестирование на проникновение
• CTF

Есть тесты и задания для каждого раздела. Все примеры представлены на Java (но вы можете выполнять задания на любом языке).

Институт программной инженерии Карнеги-Меллон (SEI) собрал эти полезные правила и рекомендации по безопасному кодированию. Следует ознакомиться с безопасными стандартами кодирования для C, C++, Java, Perl и Android, а также прочитать о 10 лучших методах безопасного кодирования.

Cybrary – платформа с открытым исходным кодом, созданная для обучения безопасности и подготовки к сертификации. Контент бесплатный, но включает в себя бесценные материалы.

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

Один из самых надежных способов изучить основы в области безопасности – пройти курс колледжа MIT. Учебный план охватывает:

• моделирование угроз
• ксплойты
• сетевую безопасность
• аутентификацию
• мобильную безопасность
• экономику безопасности и т. д.

Аналогичные курсы по безопасности есть в Harvard edX, Stanford Online и Coursera.

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

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

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

Оригинал

Веб-безопасность — Веб-технологии для разработчиков

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

Безопасность контента

Политика безопасности контента (CSP)

Политика безопасности содержимого (CSP) — это дополнительный уровень безопасности, который помогает обнаруживать и смягчать определенные типы атак, включая атаки с использованием межсайтовых сценариев (XSS) и инъекции данных.Эти атаки используются для всего, от кражи данных до искажения сайта и распространения вредоносного ПО.

Безопасность подключения

Безопасность транспортного уровня (TLS)

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

HTTPS

HTTPS ( HyperText Transfer Protocol Secure ) — это зашифрованная версия протокола HTTP. Он использует SSL или TLS для шифрования всего обмена данными между клиентом и сервером. Это безопасное соединение позволяет клиентам быть уверенными, что они подключены к предполагаемому серверу, и обмениваться конфиденциальными данными.

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

HTTP-заголовок Strict-Transport-Security: позволяет веб-сайту указать, что к нему можно получить доступ только с помощью HTTPS.

Прозрачность сертификата

Прозрачность сертификатов — это открытая структура, предназначенная для защиты от неправильной выдачи сертификатов и контроля за ними. Недавно выпущенные сертификаты «регистрируются» для общедоступных, часто независимых журналов CT, которые поддерживают криптографически гарантированную запись выданных сертификатов TLS только для добавления.

Смешанное содержание

Страница HTTPS, которая включает содержимое, полученное с использованием открытого текста HTTP, называется страницей со смешанным содержимым .Такие страницы зашифрованы лишь частично, поэтому незашифрованный контент остается доступным для снифферов и злоумышленников.

Как исправить сайт с заблокированным смешанным контентом

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

Безопасные контексты

Безопасный контекст — это Window или Worker , для которого есть разумная уверенность в том, что контент был доставлен безопасно (через HTTPS / TLS), и для которого есть потенциал для взаимодействия с контекстами, которые не являются безопасными ограничено. Многие веб-API и функции доступны только в безопасном контексте. Основная цель безопасных контекстов — предотвратить доступ злоумышленников по типу «злоумышленник в середине» к мощным API-интерфейсам, которые могут еще больше скомпрометировать жертву атаки.

Функции, ограниченные безопасным контекстом

В этом справочнике перечислены функции веб-платформы, доступные только в безопасных контекстах.

Алгоритмы слабой подписи

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

Перенаправление с кодами ответа 301 и 302

записать

Безопасность данных

Использование файлов cookie HTTP

HTTP-куки (веб-куки, куки-файлы браузера) — это небольшой фрагмент данных, который сервер отправляет в веб-браузер пользователя.Браузер может сохранить его и отправить обратно с более поздними запросами на тот же сервер. Как правило, он используется, чтобы определить, поступили ли два запроса из одного и того же браузера, например, чтобы пользователь оставался в системе.

Локальное хранилище

Свойство Window.localStorage объекта Window — это способ для серверов хранить данные на клиенте, которые являются постоянными для всех сеансов.

Утечка информации

Политика заголовка Referer: вопросы конфиденциальности и безопасности

С HTTP-заголовком Referer связаны риски конфиденциальности и безопасности.В этой статье они описаны и даны советы по снижению этих рисков.

Robots.txt

записать

Карты сайта

записать

Целостность

Политика одинакового происхождения

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

Целостность подресурсов

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

HTTP Access-Control-Allow-Origin

Заголовок ответа Access-Control-Allow-Origin указывает, может ли ответ использоваться совместно с запрашивающим кодом из данного источника.

Параметры HTTP X-Content-Type

X-Content-Type-Options HTTP-заголовок ответа — это маркер, используемый сервером, чтобы указать, что типы MIME, объявленные в заголовках Content-Type , не должны изменяться и соблюдаться. Это способ отказаться от прослушивания типов MIME или, другими словами, сказать, что типы MIME настроены намеренно.

Защита от щелчка

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

Параметры HTTP X-Frame

X-Frame-Options HTTP-заголовок ответа может использоваться, чтобы указать, следует ли разрешить браузеру отображать страницу в ,