предисловие
Эта серия изначально была подготовлена для моего собственного интервью, потом я обнаружил, что сортировок становится все больше и больше, почти 120 000 символов, и, наконец, решил поделиться со всеми.
Чтобы поделиться ими и упорядочить их, я потратил много времени, по крайней мере, в три раза больше времени, которое я только использовал.Если вам это нравится, добро пожаловать, чтобы собрать и подписаться на меня!Спасибо!
Ссылка на статью
- Интервью на начальном этапе для проверки утечек и заполнения вакансий -- (1) Защита от встряски и дросселирование
- Предварительное интервью для проверки пропусков -- (2) Механизм сбора мусора
- Предварительные собеседования для проверки и заполнения вакансий -- (3) Междоменные и общие решения
- Предварительное собеседование для проверки и заполнения вакансий -- (4) Переднее локальное хранилище
- Предварительное собеседование для проверки утечек и заполнения вакансий -- (5) Механизм рендеринга, перерисовка и перекомпоновка
- Интервью переднего плана для проверки пропусков -- (6) Кэш браузера
- Начальное собеседование для проверки и заполнения вакансий — (7) XSS-атака и CSRF-атака
- Предварительное собеседование для проверки и заполнения вакансий -- (8) Переднее шифрование
- Предварительное собеседование для проверки и заполнения вакансий — (9) HTTP и HTTPS
- Предварительное собеседование для проверки и заполнения вакансий -- (10) Передняя аутентификация
- Начальное собеседование для проверки и заполнения вакансий — (11) Образец архитектуры программного обеспечения внешнего интерфейса MVC/MVP/MVVM
- Предварительное собеседование для проверки упущений и заполнения вакансий — (12) Весь процесс от ввода URL-адреса до просмотра страницы (включая три рукопожатия и четыре волны для подробного объяснения)
- Предварительное собеседование для проверки утечек и заполнения вакансий -- (13) Утечки памяти
- Предварительные собеседования для проверки и заполнения вакансий--(14) Алгоритмы и сортировка
- Предварительные собеседования для проверки и заполнения вакансий -- (15) Event Loop
Коллекция:
Предварительные собеседования для проверки пропусков и заполнения вакансий — индекс (набор из 120 000 слов)Содержит более дюжины других статей из серии, которые были написаны до сих пор.Последующие новые статьи с добавленной стоимостью больше не будут добавлять ссылки на каждую статью.Настоятельно рекомендуется ставить лайк и следить за коллекцией!!!!, спасибо!~
Последующий план обновления
Будет продолжать добавлять в будущемШаблоны проектирования,Фронтенд-инжиниринг,процесс проекта, развертывание, замкнутый цикл,Vue часто проверяет очки знанийДождитесь контента. Если вы считаете, что контент хорош, добро пожаловать, собирайте и подписывайтесь на меня! Спасибо!
Спросите инсайдера
В настоящее время я тоже готовлюсь к смене работы, надеюсь, вы и HR дамы порекомендуете надежную.УханьФронтальный пост! Электронная почта: bupabuku@foxmail.com. Спасибо!~
XSS-атака
Что такое XSS.
Межсайтовый скриптинг (сокращенно XSS) — этоатака путем внедрения кода. Злоумышленники внедряют вредоносные скрипты на целевой веб-сайт для запуска в браузере пользователя. Используя эти вредоносные скрипты, злоумышленники могут получить конфиденциальную информацию о пользователе, такую как Cookie, SessionID и т. д., тем самым ставя под угрозу безопасность данных.
Итак, какие части веб-страницы могут вызвать XSS-атаку?Проще говоря, все, что можно ввести, может вызвать ее, включая URL-адреса!
Общие методы внедрения XSS:
- Вредоносный контент внедряется в виде тегов сценария в текст, встроенный в HTML.
- Во встроенном JavaScript объединенные данные нарушают исходные ограничения (строки, переменные, имена методов и т. д.).
- В атрибутах тегов вредоносный контент содержит кавычки, чтобы обойти ограничения значений атрибутов и внедрить другие атрибуты или теги.
- В href, src и другие атрибуты тега включите
javascript:(псевдопротокол) и другой исполняемый код. - В событиях onload, onerror, onclick и т. д. внедрить неконтролируемый код.
- В атрибуте стиля и теге включите что-то вроде
background-image:url("javascript:...");кода (новые версии браузеров уже могут помешать). - В атрибуте стиля и теге включите что-то вроде
expression(...)Код выражения CSS (более новые версии браузеров уже могут это предотвратить).
Классификация XSS-атак
По источнику атаки XSS-атаки можно разделить на три типа: тип хранилища, тип отражения и тип DOM.
Сохраненный XSS
Сохраненные шаги атаки XSS:
- Злоумышленники отправляют вредоносный код в базу данных целевого веб-сайта.
- Когда пользователь открывает целевой веб-сайт, сервер веб-сайта извлекает вредоносный код из базы данных, встраивает его в HTML и возвращает браузеру.
- После получения ответа пользовательский браузер разбирается и выполняет его, а вредоносный код, смешанный в нем также выполнен.
- Вредоносный код крадет пользовательские данные и отправляет их на сайт злоумышленника или имитирует поведение пользователя и вызывает интерфейс целевого веб-сайта для выполнения операции, указанной злоумышленником.
Сохраненные XSS-атаки (также известные как постоянные XSS-атаки) распространены в функциях веб-сайта с данными, сохраненными пользователем, такими как сообщения на форуме, обзоры продуктов и личные сообщения пользователей.
Это самый опасный тип межсайтового скриптинга, по сравнению с рефлексивным XSS и DOM-типом XSS, он имеет более высокую скрытность, поэтому он более вреден, потому чтоЭто не требует, чтобы пользователь вручную запускал.Любая веб-программа, которая позволяет пользователям хранить данные, могут хранить уязвимости XSS, когда злоумышленник отправляет фрагмент кода XSS, он принимается и сохраняется сервером, когдаВсе браузеры будут атакованы XSS при посещении страницы.
Отраженный XSS
Этапы атаки отраженного XSS:
- Злоумышленники создают специальные URL-адреса, содержащие вредоносный код.
- Когда пользователь открывает URL-адрес с вредоносным кодом, сервер веб-сайта извлекает вредоносный код из URL-адреса, объединяет его в HTML и возвращает браузеру.
- После получения ответа браузер пользователя разбирает и выполняет его, а также выполняется подмешанный в него вредоносный код.
- Вредоносный код крадет пользовательские данные и отправляет их на сайт злоумышленника или имитирует поведение пользователя и вызывает интерфейс целевого веб-сайта для выполнения операции, указанной злоумышленником.
Разница между отраженным XSS и сохраненным XSS заключается в том, что вредоносный код сохраненного XSS хранится в базе данных, а вредоносный код отраженного XSS хранится в URL-адресе.
Отраженные XSS-уязвимости (также известные как непостоянные XSS-уязвимости) обычно встречаются в функциях, которые передают параметры через URL-адреса, такие как поиск на веб-сайте, перенаправления и т. д.
Поскольку пользователям необходимо активно открывать вредоносные URL-адреса, чтобы они вступили в силу, злоумышленники часто комбинируют различные средства, чтобы побудить пользователей щелкнуть мышью.
Содержимое POST также может инициировать отраженный XSS, но условия его срабатывания относительно жесткие (должна быть создана страница отправки формы, и пользователь должен щелкнуть ее), поэтому это происходит очень редко.
XSS типа DOM
Этапы атаки XSS типа DOM:
- Злоумышленники создают специальные URL-адреса, содержащие вредоносный код.
- Пользователь открывает URL с вредоносным кодом.
- После получения ответа браузер пользователя анализирует и выполняет его, а интерфейсный JavaScript извлекает вредоносный код из URL-адреса и выполняет его.
- Вредоносный код крадет пользовательские данные и отправляет их на сайт злоумышленника или имитирует поведение пользователя и вызывает интерфейс целевого веб-сайта для выполнения операции, указанной злоумышленником.
Разница между XSS типа DOM и первыми двумя типами XSS: в атаках XSS типа DOM извлечение и выполнение вредоносного кода осуществляется браузером, что является уязвимостью безопасности самого интерфейса JavaScript, в то время как два других типа XSS являются уязвимостями безопасности на стороне сервера.
Уведомление:
DOM обычно представляет объекты в формате html, xhtml и xml.Использование DOM позволяет программам и сценариям динамически получать доступ и обновлять содержимое, структуру и стиль документа. Не требует прямого участия сервера в разборе ответа, срабатывании XSSИспользование синтаксического анализа DOM на стороне браузера, так что остерегайтесьТип DOM XSS полностью входит в обязанности внешнего интерфейса, мы должны обратить на это внимание!!!.
В сравнении:
| Типы | зона хранения | точка вставки |
|---|---|---|
| Сохраненный XSS | серверная база данных | HTML |
| Отраженный XSS | URL | HTML |
| XSS типа DOM | Серверная база данных/интерфейсное хранилище/URL | Фронтенд JavaScript |
Защита от XSS
Пока есть место для ввода данных, может существовать опасность XSS.
Общие профилактические методы
-
httpOnly:После установки атрибута HttpOnly в файле cookie сценарий js не сможет прочитать информацию о файле cookie.
-
Входной фильтр:Обычно используется для проверки формата ввода, например: почтовый ящик, номер телефона, имя пользователя, пароль и т. д., и ввода в соответствии с указанным форматом. Не только внешний интерфейс отвечает, но и серверная часть также должна выполнять те же проверки фильтрации. Потому что злоумышленник может полностью обойти обычный процесс ввода и напрямую использовать соответствующий интерфейс для отправки настроек на сервер.
-
Экранировать HTML:Если сращивание HTML необходимо, котировки, угловые скобки и скольжения должны быть сбежать, но это не идеально. Чтобы полностью избежать точек вставки в HTML-шаблонах, вам необходимо использовать подходящую библиотеку Escape., (Вы можете увидеть этобиблиотекаили китайский)
function escape(str) { str = str.replace(/&/g, '&') str = str.replace(/</g, '<') str = str.replace(/>/g, '>') str = str.replace(/"/g, '&quto;') str = str.replace(/'/g, ''') str = str.replace(/`/g, '`') str = str.replace(/\//g, '/') return str } -
белый список:Для отображения форматированного текста описанный выше метод не может экранировать все символы, поскольку при этом также будет отфильтрован требуемый формат. В этом случае обычно используется метод фильтрации по белому списку.Конечно, его можно фильтровать и по черному списку, однако, учитывая, что тегов и атрибутов тегов для фильтрации слишком много, более рекомендуется использовать метод белого списка.
Предотвратить сохраненные и отраженные XSS-атаки
Как сохраненные, так и отраженные XSS вставляются в ответный HTML-код после извлечения вредоносного кода с сервера.Преднамеренно написанные злоумышленником «данные» встраиваются в «код» и выполняются браузером.
Существует два общепринятых метода предотвращения этих двух типов уязвимостей:
- Перейдите на чисто внешний рендеринг, чтобы разделить код и данные.
- Полностью избежать HTML.
Об экранировании HTML уже говорилось ранее, здесь просто чистый интерфейсный рендеринг.
Процесс чистого внешнего рендеринга:
- Сначала браузер загружает статический HTML-код, не содержащий никаких бизнес-данных.
- Затем браузер выполняет JavaScript в HTML.
- JavaScript загружает бизнес-данные через Ajax и вызывает API DOM для их обновления на странице.
В чистом интерфейсном рендеринге мы явно сообщаем браузеру: содержимое, которое будет установлено ниже, — это текст (.innerText), или свойства (.setAttribute), или стиль (.style)так далее. Браузеры не так-то просто заставить выполнять неожиданный код.
Тем не менее, чистый внешний рендеринг также требует внимания, чтобы избежать XSS-уязвимостей типа DOM (таких какonloadсобытия иhrefсерединаjavascript:xxxи т. д., см. раздел «Предотвращение XSS-атак типа DOM» ниже).
Во многих внутренних системах и системах управления очень подходит чистый интерфейсный рендеринг. Однако для страниц с высокими требованиями к производительности или требованиям SEO нам все еще приходится сталкиваться с проблемой сплайсинга HTML, а в настоящее время нам нужно полностью избежать HTML.
Предотвращение XSS-атак типа DOM
Атака XSS типа DOM на самом деле заключается в том, что код JavaScript на внешнем интерфейсе веб-сайта недостаточно строг, а ненадежные данные выполняются как код.
В использовании.innerHTML,.outerHTML,document.write()Будьте особенно осторожны, чтобы не вставлять ненадежные данные на страницу в виде HTML, а вместо этого используйте.textContent,.setAttribute()Ждать.
Если вы используете стек Vue/React и не используетеv-html/dangerouslySetInnerHTMLфункция, просто избегайте ее на этапе внешнего рендерингаinnerHTML,outerHTMLСкрытые опасности XSS.
Встроенные прослушиватели событий в DOM, такие какlocation,onclick,onerror,onload,onmouseoverЖдать,<a>помеченhrefсвойства, JavaScripteval(),setTimeout(),setInterval()и т. д., может запускать строки как код. Если ненадежные данные объединяются в строки и передаются этим API, это может легко создать угрозу безопасности, поэтому обязательно избегайте их.
<!-- 内联事件监听器中包含恶意代码 -->
<img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">
<!-- 链接内包含恶意代码 -->
<a href="UNTRUSTED">1</a>
<script>
// setTimeout()/setInterval() 中调用恶意代码
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")
// location 调用恶意代码
location.href = 'UNTRUSTED'
// eval() 中调用恶意代码
eval("UNTRUSTED")
</script>
Подделка межсайтовых запросов CSRF
Что такое CSRF
Подделка межсайтовых запросов (английский язык: Подделка межсайтовых запросов), также известная как атака одним щелчком мыши или сеансовая подмена, часто сокращенно CSRF или XSRF, представляет собой метод принуждения пользователя к выполнению непреднамеренных действий на вошедшем в данный момент веб-приложение Метод оперативной атаки. Например, злоумышленник побуждает жертву зайти на сторонний веб-сайт, а на стороннем веб-сайте отправляет межсайтовый запрос на атакуемый веб-сайт. Используя регистрационные данные, которые жертва получила на атакованном веб-сайте, аутентификация пользователя в фоновом режиме обходится, и достигается цель выдачи себя за пользователя для выполнения операции на атакуемом веб-сайте.
Процесс атаки CSRF
Следующая картинка цитируется этим большим человекомГоворя о режиме атаки CSRF,благодарный!
Как видно из рисунка выше, для завершения CSRF-атаки жертва должна последовательно выполнить два шага:
- 1. Войдите на доверенный веб-сайт А и создайте файлы cookie локально.
- 2. Посетите опасный веб-сайт B, не выходя из системы A.
В этот момент вы можете сказать: «Если я не выполню одно из двух вышеперечисленных условий, CSRF не будет атаковать меня». Да, это так, но вы не можете гарантировать, что не произойдет следующее:
- 1. Вы не можете гарантировать, что после входа на веб-сайт вы больше не откроете вкладку и не посетите другой веб-сайт.
- 2.Вы не можете гарантировать, что срок действия ваших локальных файлов cookie истечет сразу после закрытия браузера., ваша последняя сессия закончилась. (На самом деле закрытие браузера не завершает сеанс, но большинство людей ошибочно полагают, что закрытие браузера эквивалентно выходу из системы/завершению сеанса...)
- 3. Так называемый атакующий веб-сайт на картинке выше может быть надежным и часто посещаемым веб-сайтом с другими уязвимостями.
Распространенные типы CSRF-атак
-
ПОЛУЧИТЬ тип CSRF
Использование CSRF типа GET очень просто, требуется только один HTTP-запрос, и обычно он используется следующим образом:
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >
После того, как жертва зайдет на страницу, содержащую этот img, браузер автоматическиhttp://bank.example/withdraw?account=xiaoming&amount=10000&for=hackerСделайте HTTP-запрос. bank.example получит перекрестный запрос, содержащий данные для входа жертвы.
-
CSRF типа POST
Этот тип CSRF обычно эксплуатируется с использованием автоматически отправляемой формы, например:
<form action="http://bank.example/withdraw" method=POST>
<input type="hidden" name="account" value="xiaoming" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
После посещения страницы форма будет автоматически отправлена, что эквивалентно имитации выполнения пользователем операции POST.
Атаки типа POST, как правило, немного более строгие, чем GET, но все же менее изощренные. Любой личный веб-сайт, блог или веб-сайт, загруженный хакерами, может быть источником атаки.Бэкенд-интерфейсы не могут полагаться на безопасность только при разрешении POST..
-
Тип ссылки CSRF
CSRF типа ссылки не является распространенным явлением.По сравнению с двумя другими случаями, когда пользователи открывают страницу и попадают в ловушку, этот тип CSRF требует, чтобы пользователь щелкнул ссылку для срабатывания. Этот тип обычно встраивает вредоносные ссылки в изображения, размещенные на форумах, или побуждает пользователей в виде рекламы.Злоумышленники обычно обманом заставляют пользователей щелкать преувеличенными словами, такими как:
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
重磅消息!!
<a/>
Особенности CSRF
- Атаки, как правило, запускаются на сторонние веб-сайты, а не на атакуемый веб-сайт. Скомпрометированный веб-сайт не может предотвратить атаку.
- атакаИспользуйте учетные данные жертвы на атакованном веб-сайте, чтобы выдать себя за жертву и выполнить операцию.; Вместо непосредственно кража данных.
- В течение всего процесса злоумышленник не может получить учетные данные жертвы для входа, а только «мошенническое использование».
- Межсайтовые запросы можно выполнять различными способами: URL-адреса изображений, гиперссылки, CORS, отправка форм и многое другое. Некоторые методы запросов могут быть напрямую встроены в сторонние форумы и статьи, которые трудно отследить.
CSRF обычно является междоменным, потому что злоумышленникам обычно легче контролировать внешний домен. Однако, если есть функции, которые легко использовать в этой области, такие какФорумы и области комментариев, где можно размещать изображения и ссылки, атаки могут проводиться непосредственно под этим доменом, и этот вид атаки более опасен.
Разница между CSRF и XSS
- Вообще говоря, CSRF реализуется с помощью XSS, а CSRF часто называют XSRF (CSRF также может быть реализован путем прямой выдачи запросов через командную строку и т. д.).
- По сути, XSS — это проблема внедрения кода,CSRF — это проблема HTTP.XSS — это нефильтрованный контент, который заставляет браузер интерпретировать ввод злоумышленника как выполнение кода.CSRF связан с тем, что браузер автоматически создает файл cookie при отправке HTTP-запроса, а сеанс общего веб-сайта существует в файле cookie (проверку токена можно избежать).
защита
-
Captcha; обеспечивает взаимодействие пользователя с приложением для выполнения окончательного запроса. Этот метод может хорошо обуздать csrf, но пользовательский опыт относительно плохой.
-
Referer check; запросить ограничение по источнику, этот метод имеет наименьшую стоимость, но не гарантирует 100% эффективность, так как сервер не может постоянно получать Referer, а младшая версия браузера имеет риск подделки Referer.
-
жетон;Защитный механизм проверки токена CSRF признан наиболее подходящим решением.(Подробности см. в подробном описании токена в этой серии интерфейсной аутентификации)Если на сайте есть еще и XSS-уязвимости, то этот метод — пустая болтовня.
Другие более подробные способы защиты можно посмотреть:Вторая серия безопасности внешнего интерфейса: как предотвратить атаки CSRF?
спасибо и ссылка
- Серия Front-end Security (1): как предотвратить XSS-атаки?(действительно очень подробно!)
- Вторая серия безопасности внешнего интерфейса: как предотвратить атаки CSRF?(действительно очень подробно! +1)