По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
А пока не начали - почитайте материал про одноадресные пути без петель.
Простое правило кратчайшего пути используется для построения описания набора путей, а не одного пути в реальных сетях. Хотя для представления набора путей через топологию или сеть можно использовать ряд различных видов деревьев, для описания компьютерных сетей обычно используются два: Minimum Spanning Tree - MST и Shortest Path Tree - SPT. Разница между этими двумя видами деревьев часто неуловима. Сеть, показанная на рисунке 3, будет использоваться для иллюстрации MST и SPT.
На рисунке 3 несколько различных путей будут касаться каждого узла, например, с точки зрения А:
[A, B, E, D, C] и [A, C, D, E, B], каждая общей стоимостью 10
[A, B, E] стоимостью 5 и [A, C, D] стоимостью 3, общая стоимость 8
[A, C, D, E] стоимостью 6 и [A, B] стоимостью 1, общая стоимость - 7
MST - это дерево, которое посещает каждый узел в сети с минимальной общей стоимостью (обычно измеряется как сумма всех линий связи, выбранных в сети).
Алгоритм, вычисляющий MST, выберет вариант 3, поскольку он имеет наименьшую общую стоимость по набору граней, необходимых для достижения каждого узла в сети.
SPT описывает кратчайший путь к каждому пункту назначения в сети, независимо от общей стоимости графа. Алгоритм, вычисляющий SPT, с точки зрения A выбрал бы:
От [A, B] до B со стоимостью 1, так как этот путь короче, чем [A, C, D, E, B] со стоимостью 10
[A, B, E] в E стоимостью 5, так как это короче, чем [A, C, D, E] стоимостью 6
От [A, C] до C со стоимостью 1, так как это короче, чем [A, B, E, D, C] со стоимостью 10
[A, C, D] в D стоимостью 3, так как это короче, чем [A, B, E, D] стоимостью 8
Сравнивая набор кратчайших путей с набором путей, которые будут касаться каждого узла, приведенный выше алгоритм, вычисляющий SPT, выберет вариант 2, а не 3 в вышеуказанном списке. Другими словами, SPT будет игнорировать общую стоимость граней в MST, чтобы найти кратчайший путь к каждому достижимому месту назначения (в данном случае к узлам), тогда как MST будет игнорировать кратчайший путь к каждому достижимому месту назначения, чтобы минимизировать стоимость всего графа.
Плоскости управления сетью чаще всего вычисляют SPT, а не MST, используя какую-либо форму greedy алгоритма. Хотя SPT не оптимальны для решения всех проблем, связанных с потоками сетевого трафика, они, как правило, лучше, чем MST, в типах проблем потока трафика, которые должны решать плоскости управления сетью.
Greedy алгоритм
Greedy алгоритмы выбирают локально оптимальные решения для решения больших проблем. Например, при вычислении кратчайшего пути через сеть Greedy алгоритм может выбрать посещение более близких соседних узлов (может быть достигнуто через линию связи с более низкой стоимостью) перед узлами, которые находятся дальше (могут быть достигнуты через линию связи с более высокой стоимостью). Таким образом, можно сказать, что Greedy алгоритмы ослабляют вычисления, обычно игнорируя или приближая глобальную оптимизацию.
Иногда Greedy алгоритмы могут потерпеть неудачу. Когда они действительно дают сбой, они могут потерпеть впечатляющую неудачу, обеспечивая худшее из возможных решений. Например, при правильном наборе метрик жадный алгоритм, такой как алгоритм Дейкстры, может вычислить набор самых длинных путей через сеть, а не набор самых коротких. Поэтому Greedy алгоритмы иногда считаются эвристическими, поскольку они приближают решение сложной задачи или могут решить ее в ограниченных средах, а не фактически решают общую задачу.
В реальном мире компьютерные сети спроектированы таким образом, чтобы эти алгоритмы вычисляли наилучшее возможное решение поставленной проблемы в каждом случае, а именно нахождение кратчайшего набора путей через сеть.
А дальше интереснее - почитайте про альтернативные пути без петель.
Если вы начинающий веб-разработчик, возможно вы уже знаете, как работает всемирная сеть, по крайней мере, на базовом уровне.
Но когда начинаете кому-то объяснять принцип работы веб-сайта, то терпите неудачу. Что такое IP-адрес? Как работает модель «клиент-сервер» на самом деле?
В наши дни есть достаточно мощные фреймворки, которые можно использовать в своих проектах. Настолько мощные, что начинающие разработчики легко могут запутаться в принципах работы веб.
Базовый веб-поиск
Начнем с того места, где мы все были раньше: введите «www.github.com» в адресную строку браузера и просмотрите загрузку страницы.
С первого взгляда может показаться, что тут происходит какая-то магия. Но давайте заглянем глубже.
Определение частей web
Из-за обилия жаргонных слов, понимание работы интернета поначалу пугает. Но к сожалению, для дальнейшего погружения в тему, придется разобраться с ними.
Клиент: Приложение, например, Chrome или Firefox, которое запущено на компьютере и подключено к Интернету. Его основная роль состоит в том, чтобы принимать пользовательские команды и преобразовывать их в запросы к другому компьютеру, называемому веб-сервером. Хотя мы обычно используем браузер для доступа к Интернету, вы можете считать весь ваш компьютер «клиентом» модели клиент-сервер. Каждый клиентский компьютер имеет уникальный адрес, называемый IP-адресом, который другие компьютеры могут использовать для идентификации.
Сервер: Компьютер, который подключен к Интернету и также имеет IP-адрес. Сервер ожидает запросов от других машин (например, клиента) и отвечает на них. В отличие от вашего компьютера (т.е. клиента), который также имеет IP-адрес, на сервере установлено и работает специальное серверное программное обеспечение, которое подсказывает ему, как реагировать на входящие запросы от вашего браузера. Основной функцией веб-сервера является хранение, обработка и доставка веб-страниц клиентам. Существует множество типов серверов, включая веб-серверы, серверы баз данных, файловые серверы, серверы приложений и многое другое. Подробнее про сервера можно прочитать тут
IP-адрес: Internet Protocol Address. Числовой идентификатор устройства (компьютера, сервера, принтера, маршрутизатора и т.д.) в сети TCP/IP. Каждый компьютер в Интернете имеет IP-адрес, который он использует для идентификации и связи с другими компьютерами. IP-адреса имеют четыре набора чисел, разделенных десятичными точками (например, 244.155.65.2). Это называется «логический адрес». Для определения местоположения устройства в сети логический IP-адрес преобразуется в физический адрес программным обеспечением протокола TCP/IP. Этот физический адрес (т.е. MAC-адрес) встроен в оборудование. Подробнее про IP-адрес можно прочитать тут
Интернет-провайдер: Интернет-провайдер. Интернет-провайдер - посредник между клиентом и серверами. Для типичного домовладельца ИП обычно является «кабельной компанией». Когда браузер получает от вас запрос на переход к www.github.com, он не знает, где искать www.github.com. Это задание поставщика услуг Интернета - выполнить поиск DNS (системы доменных имен), чтобы спросить, на какой IP-адрес настроен сайт, который вы пытаетесь посетить.
DNS: система доменных имен. Распределенная база данных, которая хранит соответствие доменных имен компьютеров и их IP-адресов в Интернете. Не беспокойтесь о том, как сейчас работает «распределенная база данных»: просто знайте, что DNS существует, чтобы пользователи могли вводить www.github.com вместо IP-адреса. Подробнее про DNS можно прочитать тут
Имя домена: используется для идентификации одного или нескольких IP-адресов. Пользователи используют доменное имя (например, www.github.com) для доступа к веб-сайту в Интернете. При вводе имени домена в обозреватель DNS использует его для поиска соответствующего IP-адреса данного веб-сайта.
TCP/IP: Наиболее широко используется протокол связи. «Протокол» - это просто стандартный набор правил для чего-либо. TCP/IP используется в качестве стандарта для передачи данных по сетям. Подробнее про TCP/IP можно прочитать тут
Номер порта: 16-разрядное целое число, которое идентифицирует определенный порт на сервере и всегда связано с IP-адресом. Он служит способом идентификации конкретного процесса на сервере, на который могут пересылаться сетевые запросы.
Хост: Компьютер, подключенный к сети - это может быть клиент, сервер или любой другой тип устройства. Каждый хост имеет уникальный IP-адрес. Для веб-сайта, как www.google.com, хост может быть веб-сервером, который обслуживает страницы для веб-сайта. Часто между хостом и сервером происходит какая-то путаница, но заметьте, что это две разные вещи. Серверы - это тип хоста - это конкретная машина. С другой стороны, хост может ссылаться на всю организацию, которая предоставляет службу хостинга для обслуживания нескольких веб-серверов. В этом смысле можно запустить сервер с хоста.
HTTP: протокол передачи гипертекста. Протокол, используемый веб-браузерами и веб-серверами для взаимодействия друг с другом через Интернет.
URL: URL-адреса идентифицируют конкретный веб-ресурс. Простой пример https://github.com/someone. URL указывает протокол («https»), имя хоста (github.com) и имя файла (чья-то страница профиля). Пользователь может получить веб-ресурс, идентифицированный по этому URL-адресу, через HTTP от сетевого хоста, доменное имя которого github.com. Подробнее про URL можно прочитать тут
Переход от кода к веб-странице
Теперь у нас есть необходимая база, чтобы разобраться, что происходит за кулисами, когда мы вводим в строку поиска адрес Github:
1) Введите URL-адрес в браузере
2) Браузер анализирует информацию, содержащуюся в URL. Сюда входят протокол («https»), доменное имя («github.com») и ресурс («/»). В этом случае после «.com» нет ничего, что указывало бы на конкретный ресурс, поэтому браузер знает, как получить только главную (индексную) страницу.
3) Браузер связывается с поставщиком услуг Интернета, чтобы выполнить DNS-поиск IP-адреса для веб-сервера, на котором размещен веб-сервер www.github.com. Служба DNS сначала свяжется с корневым сервером имен, который просматривает https://www.github.com и отвечает IP-адресом сервера имен для домена верхнего уровня .com. Получив этот адрес служба DNS выполняет еще один запрос на сервер имен, который отвечает за домен .com и запрашивает адрес https://www.github.com.
4) Получив IP-адрес сервера назначения, Интернет-провайдер отправляет его в веб-браузер.
5) Ваш браузер берет IP-адрес и заданный номер порта из URL (протокол HTTP по умолчанию - порт 80, а HTTPS - порт 443) и открывает TCP-сокет. На этом этапе связь между веб-браузером и веб-сервер наконец-то установлена.
6) Ваш веб-браузер отправляет HTTP-запрос на веб-сервер главной HTML-страницы www.github.com.
7) Веб-сервер получает запрос и ищет эту HTML-страницу. Если страница существует, веб-сервер подготавливает ответ и отправляет его обратно в браузер. Если сервер не может найти запрошенную страницу, он отправляет сообщение об ошибке HTTP 404 (тот самый Error 404 Not Found), которое означает «Страница не найдена».
8) Ваш веб-браузер берет HTML-страницу, которую он получает, а затем анализирует ее, делая полный обзор, чтобы найти другие ресурсы, которые перечислены в ней: это адреса изображений, CSS файлов, JavaScript файлов и т.д.
9) Для каждого перечисленного ресурса браузер повторяет весь указанный выше процесс, делая дополнительные HTTP-запросы на сервер для каждого ресурса.
10) После того, как браузер закончит загрузку всех других ресурсов, перечисленных на странице HTML, страница будет загружена в окно браузера и соединение будет закрыто.
Пересечение Интернет-пропасти
Стоит отметить, как информация передается при запросе информации. Когда вы делаете запрос, эта информация разбивается на множество крошечных порций, называемых пакетами. Каждый пакет маркируется заголовком TCP, который включает в себя номера портов источника и назначения, и заголовком IP, который включает в себя IP-адреса источника и назначения. Затем пакет передается через сеть Ethernet, WiFi или сотовую сеть. Пакет может перемещаться по любому маршруту и проходить столько транзитных участков, сколько необходимо для того, чтобы добраться до конечного пункта назначения. И пакеты передаются отнюдь не в том, порядке, в котором они сформировались. Например, первый пакет может прийти третьим, а последний первым.
Нам на самом деле все равно, как пакеты туда попадут - важно только то, что они доберутся до места назначения в целости и сохранности! Как только пакеты достигают места назначения, они снова собираются и доставляются как единое целое.
Так как же все пакеты знают, как добраться до места назначения без потери? Ответ: TCP/IP.
TCP/IP - это двухкомпонентная система, функционирующая как фундаментальная «система управления» Интернета. IP означает Интернет-протокол; его задачей является отправка и маршрутизация пакетов на другие компьютеры с использованием заголовков IP (т.е. IP-адресов) каждого пакета. Вторая часть, протокол управления передачей (TCP), отвечает за разбиение сообщения или файла на меньшие пакеты, маршрутизацию пакетов к соответствующему приложению на целевом компьютере с использованием заголовков TCP, повторную отправку пакетов, если они теряются в пути, и повторную сборку пакетов в правильном порядке, как только они достигают другого конца.
Получение финальной картины
Но подождите - работа еще не закончена! Теперь, когда ваш браузер имеет ресурсы, составляющие веб-сайт (HTML, CSS, JavaScript, изображения и т.д.), он должен пройти несколько шагов, чтобы представить вам ресурсы в виде читабельной для нас с вами веб-страницы.
В браузере имеется механизм визуализации, отвечающий за отображение содержимого. Обработчик рендеринга получает содержимое ресурсов в небольших фрагментах. Затем существует алгоритм синтаксического анализа HTML, который сообщает браузеру, как анализировать ресурсы.
После анализа создается древовидная структура элементов DOM. DOM (Document Object Model) обозначает объектную модель документа и является условным обозначением для представления объектов, расположенных в HTML-документе. Этими объектами - или «узлами» - каждого документа можно управлять с помощью таких языков сценариев, как JavaScript.
После построения дерева DOM анализируются таблицы стилей, чтобы понять, как определить стиль каждого узла. Используя эту информацию, браузер проходит вниз по узлам DOM и вычисляет стиль CSS, положение, координаты и т.д. для каждого узла.
После того как в браузере появятся узлы DOM и их стили, он наконец готов соответствующим образом нарисовать страницу на экране. Результат – все, что вы когда-либо просматривали в интернете.
Итог
Интернет - это комплексная вещь, но вы только что закончили сложную часть!
О структуре веб-приложений мы расскажем в нашей следующей статье.
Разработчики программного обеспечения должны держать много информации у себя в голове. Существует множество вопросов, которые нужно задать, когда речь заходит о создании веб-сайта или приложения: Какие технологии использовать? Как будет настроена структура? Какой функционал нам нужен? Как будет выглядеть пользовательский интерфейс? Особенно на рынке программного обеспечения, где производство приложений больше похоже на гонку за репутацией, чем на хорошо обдуманный процесс, один из важнейших вопросов, который часто остается на дне “Списка важных”: Как наш продукт будет защищен?
Если вы используете надежный, открытый фреймворк для создания своего продукта (и, если он доступен и пригоден, почему бы и нет?), тогда базовые проблемы безопасности, как атаки CSFR и кодирование пароля, могут быть уже решены за вас.
Тем не менее, быстро развивающимся разработчикам будет полезно освежить свои знания о стандартных угрозах, дабы избежать ошибок новичка. Обычно самое слабое место в безопасности вашего программного обеспечения - это вы.
А кто может заниматься взломом?. Есть этичный хакер – это тот, кто ищет возможные слабости в безопасности и приватно рассказывает их создателям проекта.
А чёрный хакер, которого так же зовут “Взломщик (cracker)” – это тот, кто использует эти слабости для вымогательства или собственного блага.
Эти два вида хакеров могут использовать одинаковый набор инструментов и, в общем, пытаются попасть в такие места, куда обычный пользователь не может попасть. Но белые хакеры делают это с разрешением, и в интересах усиления защиты, а не уничтожения её. Черные хакеры – плохие ребята.
Вот некоторые примеры наиболее распространённых атаках, которые используют слабости в защите: Внедрение SQL-кода и межсайтовый скриптинг XXS.
SQL атаки
SQL-инъекция (SQLi) - это тип инъекционной атаки, которая позволяет выполнять вредоносные SQL команды, для получения данных или вывода из строя приложения. По сути, злоумышленники могут отправлять команды SQL, которые влияют на ваше приложение, через некоторые входные данные на вашем сайте, например, поле поиска, которое извлекает результаты из вашей базы данных. Сайты, закодированные на PHP, могут быть особенно восприимчивы к ним, и успешная SQL-атака может быть разрушительной для программного обеспечения, которое полагается на базу данных (например, ваша таблица пользователей теперь представляет собой пустое место).
Вы можете проверить свой собственный сайт, чтобы увидеть, насколько он восприимчив к такого рода атакам. (Пожалуйста, тестируйте только те сайты, которыми вы владеете, так как запуск SQL-кодов там, где у вас нет разрешения на это, может быть незаконным в вашем регионе; и определенно, не очень смешно.) Следующие полезные нагрузки могут использоваться для тестов:
' OR 1='1 оценивается как константа true, и в случае успеха возвращает все строки в таблице
' AND 0='1 оценивается как константа false, и в случае успеха не возвращает строк.
К счастью, есть способы ослабить атаки SQL-кода, и все они сводятся к одной основной концепции: не доверяйте вводимым пользователем данным.
Смягчение последствий SQL-кодов.
Чтобы эффективно сдержать атаки, разработчики должны запретить пользователям успешно отправлять необработанные SQL-команды в любую часть сайта.
Некоторые фреймворки сделают большую часть тяжелой работы за вас. Например, Django реализует концепцию объектно-реляционного отображения, или ORM с использованием наборов запросов. Мы будем рассматривать их в качестве функций-оболочек, которые помогают вашему приложению запрашивать базу данных с помощью предопределенных методов, избегая использование необработанного SQL.
Однако возможность использовать фреймворк никогда не является гарантией. Когда мы имеем дело непосредственно с базой данных, существуют и другие методы, которые мы можем использовать, чтобы безопасно абстрагировать наши SQL-запросы от пользовательского ввода, хотя они различаются по эффективности. Они представлены по порядку от более к менее важному:
Подготовленные операторы с переменной привязкой (или параметризованные запросы)
Хранимые процедуры
Белый список или экранирование пользовательского ввода
Если вы хотите реализовать вышеприведенные методы, то эти шпаргалки - отличная отправная точка для более глубокого изучения. Достаточно сказать, что использование этих методов для получения данных вместо использования необработанных SQL-запросов помогает свести к минимуму вероятность того, что SQL будет обрабатываться любой частью вашего приложения, которая принимает входные данные от пользователей, тем самым смягчая атаки SQL-кодов.
Межсайтовые скриптовые атаки (XSS)
Если вы являетесь хакером, то JavaScript - это в значительной степени ваш лучший друг. Правильные команды будут делать все, что может сделать обычный пользователь (и даже некоторые вещи, которые он не должен делать) на веб-странице, иногда без какого-либо взаимодействия со стороны реального пользователя.
Межсайтовые скриптовые атаки, или XSS, происходят, когда код JavaScript вводится на веб-страницу и изменяет ее поведение. Его последствия могут варьироваться от появления неприятных шуток до более серьезных обходов аутентификации или кражи учетных данных.
XSS может происходить на сервере или на стороне клиента и, как правило, поставляется в трех вариантах: DOM (Document Object Model - объектная модель документа) на основе хранимых и отображаемых XSS. Различия сводятся к тому, где полезная нагрузка атаки вводится в приложение.
XSS на основе DOM
XSS на основе DOM возникает, когда полезная нагрузка JavaScript влияет на структуру, поведение или содержимое веб-страницы, загруженной пользователем в свой браузер. Они чаще всего выполняются через измененные URL-адреса, например, в фишинговых письмах.
Чтобы увидеть, насколько легко было бы для введенного JavaScript манипулировать страницей, мы можем создать рабочий пример с веб-страницей HTML. Попробуйте создать файл в локальной системе под названием xss-test.html (или любым другим) со следующим кодом HTML и JavaScript:
<html>
<head>
<title>My XSS Example</title>
</head>
<body>
<h1 id="greeting">Hello there!</h1>
<script>
var name = new URLSearchParams(document.location.search).get('name');
if (name !== 'null') {
document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
}
</script>
</h1>
</html>
На этой веб-странице будет отображаться заголовок "Hello!” если только он не получает параметр URL из строки запроса со значением name. Чтобы увидеть работу скрипта, откройте страницу в браузере с добавленным параметром URL, например:
file:///path/to/file/xss-test.html?name=Victoria
Наша небезопасная страница принимает значение параметра URL для имени и отображает его в DOM. Страница ожидает, что значение будет хорошей дружественной строкой, но что, если мы изменим его на что-то другое? Поскольку страница принадлежит нам и существует только в нашей локальной системе, мы можем тестировать ее сколько угодно. Что произойдет, если мы изменим параметр name, скажем, на:
<img+src+onerror=alert("pwned")>
Это всего лишь один пример, который демонстрирует, как может быть выполнена атака XSS. Смешные всплывающие оповещения могут быть забавными, но JavaScript может принести много вреда, в том числе помогая злоумышленникам украсть пароли и личную информацию.
Хранимые и отраженные XSS
Хранимые (stored) XSS возникают, когда полезная нагрузка атаки хранится на сервере, например, в базе данных. Атака влияет на жертву всякий раз, когда эти сохраненные данные извлекаются и отображаются в браузере.
Например, вместо того чтобы использовать строку URL-запроса, злоумышленник может обновить свою страницу профиля на социальном сайте, чтобы внедрить скрытый сценарий, скажем, в раздел “Обо мне”. Сценарий, неправильно сохраненный на сервере сайта, будет успешно выполняться всё время, пока другой пользователь просматривает профиль злоумышленника.
Одним из самых известных примеров этого является червь Samy, который практически захватил MySpace в 2005 году. Он распространялся путем отправки HTTP-запросов, которые копировали его на страницу профиля жертвы всякий раз, когда просматривался зараженный профиль. Всего за 20 часов он распространился на более чем миллион пользователей.
Отраженные (reflected) XSS аналогично возникают, когда введенные данные перемещаются на сервер, однако вредоносный код не сохраняется в базе данных. Вместо этого он немедленно возвращается в браузер веб-приложением.
Подобная атака может быть осуществлена путем заманивания жертвы для перехода по вредоносной ссылке, которая отправляет запрос на сервер уязвимого веб-сайта. Затем сервер отправит ответ злоумышленнику, а также жертве, что может привести к тому, что злоумышленник сможет получить пароли или совершить действия, которые якобы исходят от жертвы.
Ослабление XSS
Во всех этих случаях XSS могут быть сдержаны с помощью двух ключевых стратегий: проверка полей формы и предотвращение прямого ввода данных пользователем на веб-странице.
Проверка полей формы
Фреймворки снова могут нам помочь, когда речь заходит о том, чтобы убедиться, что представленные пользователем формы находятся в актуальном состоянии. Один из примеров - встроенные классы полей Django, которые предоставляют поля, проверяющие некоторые часто используемые типы, а также задают нормальные значения по умолчанию.
Например, поле электронной почты Django использует набор правил, чтобы определить, является ли предоставленный ввод действительным письмом. Если отправленная строка содержит символы, которые обычно не присутствуют в адресах электронной почты, или если она не имитирует общий формат адреса электронной почты, то Django не будет считать это поле допустимым и форма не будет отправлена.
Если вы не можете полагаться на фреймворк, можете реализовать вашу собственную проверку входных данных. Это можно сделать с помощью нескольких различных методов, включая преобразование типа, например, гарантируя, что число имеет тип int(); проверка минимальных и максимальных значений диапазона для чисел и длин строк; использование заранее определенного массива вариантов, который позволяет избежать произвольного ввода, например, месяцев года; и проверка данных на соответствие строгим регулярным формулировкам.
К счастью, нам не нужно начинать все с нуля. Помогут доступные ресурсы с открытым исходным кодом, такой как валидация репозитория регулярных выражений OWASP, который предоставляет шаблоны для сопоставления их с некоторыми распространенными формами данных. Многие языки программирования предлагают библиотеки проверки, специфичные для их синтаксиса, и мы можем найти множество таких библиотек на GitHub.
Хотя это и может показаться утомительным, правильно реализованная проверка ввода может защитить наше приложение от восприимчивости к XSS.
Предотвращение прямого ввода данных
Элементы приложения, которые непосредственно возвращают пользовательский ввод в браузер, при обычной проверке могут быть неочевидны. Мы можем определить области приложения, которые могут быть подвержены риску, изучив несколько вопросов:
Как происходит поток данных через приложение?
Что ожидает пользователь, когда он взаимодействует с этими входными данными?
Где на нашей странице появляются данные? Становятся ли они встроенными в строку или атрибут?
Вот некоторые примеры полезных нагрузок, с которыми мы можем поиграть, чтобы проверить входные данные на нашем сайте (опять же, только на нашем собственном сайте!). Успешное выполнение любого из этих образцов может указывать на возможную уязвимость к XSS из-за прямого ввода данных.
"><h1>test</h1>
'+alert(1)+'
"onmouserover="alert(1)
http://"onmouseover="alert(1)
Как правило, если вы можете обойти прямой ввод данных, сделайте это. Кроме того, убедитесь, что вы полностью понимаете эффективность выбранных методов; например, использование innerText вместо innerHTML в JavaScript гарантирует, что содержимое будет задано как обычный текст вместо (потенциально уязвимого) HTML.
Аккуратнее с вводом!
Разработчики программного обеспечения явно находятся в невыгодном положении, когда речь заходит о конкуренции с черными хакерами. Несмотря на всю проделанную работу по защитите каждого ввода, который потенциально может скомпрометировать наше приложение, злоумышленнику достаточно только найти тот, который мы пропустили. Это все равно что установить засовы на всех дверях, но оставить окно открытым!
Однако, научившись мыслить в том же ключе, что и злоумышленник, мы можем лучше подготовить наше программное обеспечение к противостоянию плохим парням. Как бы ни было интересно добавлять функции как можно быстрее, мы избежим большого количества долгов по кибербезопасности, если заранее продумаем поток нашего приложения, проследим за данными и обратим внимание на наши входные данные.