[Интервью] Веб-безопасность, которую вы должны знать при приеме на работу зимой

JavaScript

С развитием Интернета различные веб-приложения становятся все более и более сложными, и, удовлетворяя различные потребности пользователей, также следуют различные проблемы сетевой безопасности. Как фронтенд-инженеры, мы не можем избежать этой проблемы.Сегодня давайте рассмотрим проблемы безопасности веб-интерфейса и то, как мы можем их обнаружить и предотвратить. Не фронтальные атаки в этой статье обсуждаться не будут (такие как SQL-инъекция, DDOS-атаки и т. д.), все-таки бэкенд — это не моя область знаний.

Известные веб-сайты, такие как QQ Mail, Sina Weibo, YouTube, WordPress и Baidu, были атакованы.Если у вас никогда не было проблем с безопасностью, это не потому, что веб-сайт, который вы разработали, Трафик очень низкий или не стоит атаковать.

В этой статье в основном обсуждаются следующие методы атак: XSS-атака, CSRF-атака и кликджекинг.

Другие статьи можно нажать: GitHub.com/Иветт Л.А. Ю/Б…

Я надеюсь, что после прочтения этой статьи вы сможете хорошо ответить на следующие вопросы интервью.

1. Каковы внешние методы атаки?

2. Что такое XSS-атака? Сколько типов XSS-атак существует? Как предотвратить XSS-атаки?

3. Что такое CSRF-атака? Как предотвратить CSRF-атаки

4. Как проверить, безопасен ли сайт?

Перед началом предлагаю сначала клонировать код.Я подготовил для вас пример кода и написал подробные комментарии.Вы можете сравнить код,чтобы понять каждую атаку и как ее предотвратить.Ведь сколько бы слов вы не прочитали , все Вместо практики. (Этапы работы подробно описаны в ReadMe):GitHub.com/Иветт Л.А. Ю/Б…

1. XSS-атака

XSS (Cross-Site Scripting) — это атака путем внедрения кода. Злоумышленник внедряет вредоносный код на целевой веб-сайт, и этот вредоносный код выполняется, когда злоумышленник входит на веб-сайт.Эти сценарии могут считывать файлы cookie, токены сеанса или другую конфиденциальную информацию веб-сайта, осуществлять фишинг для пользователей и даже запускать червей. атака и др.

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

XSS-классификация

В зависимости от источника атаки XSS-атаки можно разделить на три типа: тип хранилища (постоянный), тип отражения (непостоянный тип) и тип DOM. Давайте подробнее рассмотрим эти три атаки XSS:

1.1 Отраженный XSS

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

Этапы атаки отраженного XSS:

  1. Злоумышленник строит спец.URL, который содержит вредоносный код.
  2. Пользователь открывает вредоносный кодURL, сервер веб-сайта отправляет вредоносный код сURLВыньте его, вставьте в HTML и верните в браузер.
  3. После получения ответа браузер пользователя разбирает и выполняет его, а также выполняется подмешанный в него вредоносный код.
  4. Вредоносный код крадет пользовательские данные и отправляет их на сайт злоумышленника или имитирует поведение пользователя и вызывает интерфейс целевого веб-сайта для выполнения операции, указанной злоумышленником.

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

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

Посмотреть пример рефлексивной атаки

Пожалуйста, нажмите:GitHub.com/Иветт Л.А. Ю/Б…

в соответствии сREADME.md(В реальном случае необходимо побудить пользователя щелкнуть мышью, а приведенный выше код используется только для демонстрации).

УведомлениеChromeиSafariв состоянии обнаружитьurlАтака xss в Интернете заблокирует веб-страницу, но другие браузеры не могут, напримерFirefox

Если вы не хотите, чтобы передняя часть получала файл cookie, задняя часть может установитьhttpOnly(Но это неXSS攻击решение, может только уменьшить объем повреждений)

Как предотвратить отраженные XSS-атаки

Кодировать строку.

Экранируйте параметры запроса URL-адреса перед выводом на страницу.

app.get('/welcome', function(req, res) {
    //对查询参数进行编码，避免反射型 XSS攻击
    res.send(`${encodeURIComponent(req.query.type)}`); 
});

1.2 XSS типа DOM

Атака XSS типа DOM на самом деле является внешним интерфейсомJavaScriptКод недостаточно строг, и на страницу вставляется ненадежный контент. в настоящее время использует.innerHTML,.outerHTML,.appendChild,document.write()Будьте очень осторожны при ожидании API, не вставляйте ненадежные данные в виде HTML на страницу, попробуйте использовать.innerText,.textContent,.setAttribute()Ждать.

Этапы атаки XSS типа DOM:

  1. Злоумышленники создают специальные данные, содержащие вредоносный код.
  2. Вредоносный код выполняется браузером пользователя.
  3. Вредоносный код крадет пользовательские данные и отправляет их на сайт злоумышленника или имитирует поведение пользователя и вызывает интерфейс целевого веб-сайта для выполнения операции, указанной злоумышленником.

Как предотвратить XSS-атаки типа DOM

Предотвращение XSS-атак Core DOM — это тип входного содержимого, которое необходимо экранировать (встроенный прослушиватель событий и ссылки на DOM могут переходить по строке в качестве кода для запуска, вам необходимо проверить их содержимое).

1. Дляurlссылки (например, изображенияsrcсвойство), затем используйте непосредственноencodeURIComponentСбежать.

2. Неurl, мы можем закодировать это так:

function encodeHtml(str) {
    return str.replace(/"/g, '"')
            .replace(/'/g, ''')
            .replace(/</g, '&lt;')
            .replace(/>/g, '&gt;');
}

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

Посмотреть пример атаки XSS типа DOM (проверить согласно подсказке readme)

Пожалуйста, нажмите:GitHub.com/Иветт Л.А. Ю/Б…

1.3 Сохраненный XSS

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

Сохраненные шаги атаки XSS:

  1. Злоумышленники отправляют вредоносный код в базу данных целевого веб-сайта.
  2. Когда пользователь открывает целевой веб-сайт, сервер веб-сайта извлекает вредоносный код из базы данных, встраивает его в HTML и возвращает браузеру.
  3. После получения ответа браузер пользователя разбирает и выполняет его, а также выполняется подмешанный в него вредоносный код.
  4. Вредоносный код крадет пользовательские данные и отправляет их на сайт злоумышленника или имитирует поведение пользователя и вызывает интерфейс целевого веб-сайта для выполнения операции, указанной злоумышленником.

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

Как предотвратить XSS-атаки на хранилище:

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

Ознакомьтесь с сохраненным примером атаки XSS (следуйте подсказке Readme)

Пожалуйста, нажмите:GitHub.com/Иветт Л.А. Ю/Б…

Помимо тщательного экранирования, нам нужны другие средства для защиты от XSS-атак:

1.Content Security Policy

Использование HTTP на стороне сервераContent-Security-Policyзаголовок, чтобы указать стратегию, или установить ее во внешнем интерфейсеmetaЭтикетка.

Например, следующая конфигурация позволяет загружать ресурсы только в том же домене:

Content-Security-Policy: default-src 'self'

<meta http-equiv="Content-Security-Policy" content="form-action 'self';">

Эффект от настройки CSP на интерфейсной стороне и на стороне сервера одинаков, ноmetaНедоступноreport

Дополнительные настройки можно посмотретьContent-Security-Policy

Строгий CSP может играть следующие роли в предотвращении XSS:

  1. Запрещено загружать сторонний код для предотвращения сложной логики атаки.
  2. Отправка на внешний домен запрещена, после атаки на сайт данные пользователя не попадут на внешний домен.
  3. Выполнение встроенного скрипта запрещено (правила более строгие и в настоящее время используются GitHub).
  4. Отключить несанкционированное выполнение скрипта (новая функция, используемая в Google Maps для мобильных устройств).
  5. Разумное использование отчета может вовремя обнаружить XSS, что способствует скорейшему устранению проблемы.

2. Контроль длины входного содержимого

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

3. Ограничения на ввод контента

Для частичного ввода можно ограничиться отсутствием специальных символов или вводом только цифр.

4. Другие меры безопасности

  • Куки-файл только для HTTP: JavaScript запрещено читать некоторые конфиденциальные куки-файлы, и злоумышленники не могут украсть этот куки-файл после внедрения XSS.
  • Captcha: не позволяет сценариям выдавать себя за пользователей и выполнять опасные действия.

1.4 Обнаружение XSS

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

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

1. Вручную обнаруживать уязвимости XSS, используя общие строки атаки XSS.

как:jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

Он может обнаруживать уязвимости XSS в различных контекстах, таких как атрибуты HTML, текстовое содержимое HTML, комментарии HTML, ссылки перехода, встроенные строки JavaScript, встроенные таблицы стилей CSS и т. д. Он также может обнаруживать eval(), setTimeout(), XSS типа DOM. такие уязвимости, как setInterval(), Function(), innerHTML, document.write() и т. д., и могут обходить некоторые фильтры XSS.

<img src=1 onerror=alert(1)>

2. Сканировать с помощью стороннего инструмента (подробности см. в последней главе)

2. CSRF

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

Типичный поток атаки CSRF:

  1. Жертва входит на сайт А и сохраняет учетные данные для входа (файлы cookie).
  2. Злоумышленник побуждает жертву посетить Сайт B.
  3. Сайт B отправляет запрос сайту A, и браузер по умолчанию будет хранить информацию о файлах cookie сайта A.
  4. После того, как сайт A получает запрос, он проверяет запрос и подтверждает, что это учетные данные жертвы, принимая его за запрос, отправленный невиновной жертвой.
  5. Сайт A выполняет запрос сайта B от имени жертвы.
  6. Атака завершена, и злоумышленник завершает атаку, выдавая себя за жертву без ведома жертвы.

Одна картинка стоит тысячи слов:

Особенности CSRF

1. Атаки обычно инициируются на сторонних веб-сайтах, таких как сайт B на рисунке, но сайт A не может предотвратить атаки.

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

3. Межсайтовые запросы могут быть сделаны различными способами: URL-адреса изображений, гиперссылки, CORS, отправка формы и т. д. (ссылки неизвестного происхождения, не нажимайте)

Запустите код, чтобы понять его более интуитивно

Банковский депозит пользователя loki 10W.

Пользователь yvette вносит 1000 в банк.

Посмотрим, как проходит ИветтCSRFАтакуйте, тайно переводите деньги loki на свой счет и следуйте инструкциям, чтобы узнать, как защититься от CSRF-атак.

Пожалуйста, нажмите:GitHub.com/Иветт Л.А. Ю/Б…[Согласно разделу CSRF в файле readme]

Защита от CSRF-атак

1. Добавьте проверочный код (неудачный опыт)

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

2. Определяем источник запроса: обнаруживаем Referer (небезопасно, Referer можно поменять)

`Referer` 可以作为一种辅助手段，来判断请求的来源是否是安全的，但是鉴于 `Referer` 本身是可以被修改的，因为不能仅依赖于  `Referer`

3. Используйте токен (мейнстрим)

CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开。跟验证码类似，只是用户无感知。

- 服务端给用户生成一个token，加密后传递给用户
- 用户在提交请求时，需要携带这个token
- 服务端验证token是否正确

4. Атрибут файла cookie того же сайта

Чтобы решить эту проблему из источника, Google разработал черновик для улучшения протокола HTTP, добавив атрибут Samesite в заголовок ответа Set-Cookie, который используется для указания, что этот файл cookie является «файлом cookie того же сайта», и файл cookie того же сайта можно использовать только в качестве первого Односторонний файл cookie нельзя использовать в качестве стороннего файла cookie. У Samesite есть два значения атрибута, а именно Strict и Lax.

Он прост в развертывании и может эффективно защищать от CSRF-атак, но есть проблемы с совместимостью.

Samesite=Strict

Samesite=StrictИзвестный как строгий режим, это означает, что этот файл cookie ни при каких обстоятельствах не может использоваться в качестве стороннего файла cookie и имеет возможность предотвращать все атаки CSRF. На этом этапе, если мы инициируем какой-либо запрос к сайту A на сайте B, файл cookie сайта A не будет включен в заголовок запроса файла cookie.

**Samesite=Lax**

`Samesite=Lax` 被称为是宽松模式，与 Strict 相比，放宽了限制，允许发送安全 HTTP 方法带上 Cookie，如 `Get` / `OPTIONS` 、`HEAD` 请求.

但是不安全 HTTP 方法，如： `POST`, `PUT`, `DELETE` 请求时，不能作为第三方链接的 Cookie

Чтобы лучше защититься от CSRF-атак, мы можем комбинировать вышеуказанные методы защиты.

3. Кликджекинг

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

Типичный алгоритм атаки кликджекинга

  1. Злоумышленник создал очень привлекательную веб-страницу [я не знаю, какой контент для вас привлекателен, поэтому не буду писать страницу, поленитесь]
  2. Поместите атакуемую страницу в текущую страницуiframeсередина
  3. Используйте стили для наложения фреймов поверх очень привлекательного контента.
  4. Установите iframe на 100% прозрачным
  5. Вас побуждают нажать на веб-контент, вы думаете, что нажимаете на ***, но на самом деле вы успешно атакованы.

Защита от кликджекинга

1. frame busting

Frame busting

if ( top.location != window.location ){
    top.location = window.location
}

Примечание: iframe в HTML5sandboxатрибут, iframe в IEsecurityАтрибуты и т. д. могут ограничивать выполнение скриптов JavaScript на странице iframe, что может сделать блокировку кадров недействительной.

2. X-Frame-Options

X-FRAME-OPTIONS — это http-заголовок, предложенный Microsoft для защиты от кликджекинга с использованием вложения iframe. И в IE8, Firefox3.6, Chrome4 и выше версии могут хорошо поддерживаться.

Можно установить следующие значения:

  • DENY: запретить любую загрузку домена

  • SAMEORIGIN: разрешить загрузку с гомологичных доменов

  • ALLOW-FROM: Вы можете определить адрес страницы, на которой разрешена загрузка фрейма.

Средство сканирования безопасности

Выше мы представили несколько общих уязвимостей безопасности внешнего интерфейса, а также понимаем некоторые превентивные меры, так как же мы обнаруживаем проблемы безопасности нашего собственного веб-сайта? Компании без отдела безопасности могут рассмотреть следующие инструменты сканирования с открытым исходным кодом:

1. Arachni

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

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

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

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

2. Mozilla HTTP Observatory

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

К основным направлениям осмотра относятся:

  • Cookie
  • Совместное использование ресурсов между источниками (CORS)
  • Политика безопасности контента (CSP)
  • Закрепление открытого ключа HTTP
  • Статус HTTP Strictly Secure Transport (HSTS)
  • Есть ли автоматическое перенаправление HTTP на HTTPs
  • Целостность субресурсов
  • X-Frame-Options
  • X-XSS-Protection

3. w3af

W3af — сканер безопасности веб-приложений на основе Python. Помогает разработчикам, помогает разработчикам и тестировщикам выявлять уязвимости в веб-приложениях.

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

План последующего письма (порядок написания варьируется)

1. «Нативный JS, который вы должны знать в зимний сезон поиска работы» (Часть 2)

2. «CSS, который вы должны знать в зимний сезон поиска работы»

3. «Некоторые знания о браузере, которые вы должны знать в зимний сезон поиска работы»

4. «Оптимизация производительности, о которой вы должны знать в зимний сезон поиска работы»

5. «Принцип веб-пакета, который вы должны понимать в зимний сезон поиска работы»

Для стека React:

1. Серия «Реакция, которую вы должны знать в зимний сезон поиска работы»

2. Серия «ReactNative, которую вы должны знать в зимний сезон поиска работы»

Хотя на написание этой статьи ушло много времени, я также многому научился в процессе. Спасибо за вашу готовность потратить свое драгоценное время на чтение этой статьи. Если эта статья немного поможет вам или вдохновит, пожалуйста, не будьте скупы на ваши, Зан и Стар, ваше утверждение - самая большая мотивация для меня двигаться вперед.GitHub.com/Иветт Л.А. Ю/Б…

Справочная статья:

[1] Как предотвратить CSRF-атаки?

[2] Расскажите о своем понимании веб-безопасности

[3] Что программисты должны знать о веб-безопасности

[4] Атрибут SameSite файла cookie

[5] GitHub.com/ow asp/cheat…

Подпишитесь на официальный аккаунт и присоединитесь к группе технического обмена

Категории