Как защититься от xss атаки и устранить уязвимость. Методы защиты от XSS-атак и SQL-инъекций Защита от xss атак php
Использование заголовков безопасности является важным звеном в защите сайта и его посетителей от хакерских атак. В прошлой статье про из рубрики по защите и безопасности я обещал регулярно публиковать записи на эту тему. Сегодня я расскажу про защиту от XSS атаки.
Что такое XSS-атакаМежсайтовый скриптинг (Cross Site Scripting) — это уязвимость, которая позволяет злоумышленнику внедрить вредоносный код (обычно HTML или JavaScript) в содержимое сайта. Вредоносный код выполняется в браузере пользователя, который просматривает зараженную страницу сайта.
Злоумышленники могут эксплуатировать различные уязвимости. Наибольшее распространение получили два типа атаки:
- Отражённая (Reflected XSS) — самый распространенный непостоянный тип атаки, требующий выполнения определённого действия со стороны пользователя.
- Хранимая (Persistent XSS) — постоянный тип атаки с внедрением вредоносного кода на сервер, не требует вмешательства пользователя.
Срабатывает при переходе пользователя по специально подготовленной ссылке, которая отправляет запрос на сайт с уязвимостью. Данная уязвимость обычно является результатом недостаточной фильтрации входящих запросов, что позволяет манипулировать функциями и активировать вредоносные скрипты.
Для успешного выполнения хранимой атаки злоумышленнику достаточно найти уязвимость на сайте и разместить на своём сервере вредоносный скрипт. Затем на сайте размещается тег , который загружает скрипт с с внешнего сайта, например, в комментариях. При загрузке заражённой страницы вредоносный скрипт каждый раз передаётся в браузер пользователя.
Заголовок X-XSS-Protection предназначен для включения фильтра межсайтового скриптинга, встроенного во всех современных браузерах. Он позволит, например, предотвратить выполнение тега в URL страницы.
Директива report для отправки отчётов действует аналогично директиве report-uri (или report-to) Content Security Policy (CSP), указывая браузеру пользователя сообщать о попытках нарушения политики безопасности контента. Об этом я расскажу в отдельной статье.
Отчёт о нарушениях формируется в формате JSON и отправляется POST-запросами по указанному адресу URL.
Возвращаясь к основной теме, рекомендую настроить сервер таким образом, чтобы HTTP заголовок включал фильтрацию и при XSS-атаке блокировал загрузку страницы с небезопасным содержимым. В файле дополнительной конфигурации.htaccess (или httpd.conf, если у вас есть полный доступ к серверу) веб-сервера Apache необходимо добавить следующую запись:
Header set X-XSS-Protection "1; mode=block"Для сервера Nginx дополните файл nginx.conf в разделе HTTP записью:
Add_header X-XSS-Protection "1; mode=block" ;
В том случае, если доступ к конфигурационным файлам сервера отсутствует, но есть поддержка PHP, тогда используйте функцию:
Cross Site Scripting, также известный как XSS, — это один из способов внедрения вредоносного кода, который исполняется на стороне клиента. Пользователь может заметить что-то неладное, например, необычное поведение страницы, иногда атака совершается абсолютно не заметно в фоновом режиме.
Надеюсь, теперь вы стали немного больше понимать в HTTP-заголовках сервера и X-XSS поможет предотвратить межсайтовый скриптинг. Я использую заголовки безопасности на всех своих сайтах и настоятельно рекомендую вам сделать тоже самое. Вместе мы можем сделать интернет более безопасным! 😉
Когда дело доходит до безопасности приложений, важно заботиться не только о железе и операционной системе, но и о написании защищённых скриптов. В данной статье вы узнаете, как обеспечить безопасность вашего приложения и сделать его менее уязвимым. Ниже приведён список мер, которые помогут вам защитить ваше приложение от всевозможных атак:
Во время проектирования приложения, вам нужно стремиться защитить его от “плохих” входящих данных. Правило, которому нужно следовать, звучит примерно так: “Никогда не верьте тому, что ввёл пользователь”. Несмотря на то что большинство пользователей не представляют угрозы, всегда есть вероятность того, что кто-то захочет хакнуть ваш сайт, используя “плохие” данные, вводимые через формы или адресную строку. Если вы всегда проверяете и фильтруете входящие данные, то у вас неплохие шансы написать безопасное приложение.
Всегда проверяйте ваши данные в PHP скриптах. Если же вы используете JavaScript для валидации данных, то в любой момент злоумышленник может отключить его в своём браузере. В таком случае ваше приложение в опасности. Никто не против JavaScript валидации, но для хорошей защиты вам необходимо перепроверять данные в PHP скриптах.
Защита от XSS атакМежсайтовый скриптинг или XSS атака - это атака, основанная на внедрении кода на потенциально уязвимых страницах. Опасность в том, что вредоносный код может быть введён через формы, а затем отображён в браузере.
Предположим, на вашем сайте есть форма для ввода комментариев, которые сразу же отображаются после добавления. Злоумышленник может ввести комментарий, содержащий JavaScript код. После отправки формы, данные переправляются на сервер и заносятся в базу данных. После этого данные извлекаются из базы и новый комментарий отображается на HTML странице, включая и внедрённый JavaScript код. Он может перенаправлять пользователя на какую-то вредоносную страницу или на фишинговый сайт.
Для защиты ваших приложений, пропускайте входящие данные через функцию strip_tags() , которая удалит все присутствующие теги. При отображении данных в браузере, применяйте функцию htmlentities() .
Защита от CSRF атакСледующий вид атаки, который мы рассмотрим, это CSRF атака или подделка межсайтовых запросов. Атакующий использует различные трюки для получения конфиденциальной информации или совершения сделки без ведома жертвы. В основном это происходит на плохо защищённых сайтах, где бизнес логика строится на работе GET запросов.
Вообще говоря, GET запросы идемпотентны. Идемпотентность, в данном контексте, означает, что доступ к одной и той же странице может быть осуществлён сколько угодно раз без всякого стороннего вмешательства. Именно поэтому GET запросы должны использоваться только для получения доступа к информации, но ни в коем случае не для осуществления различного рода транзакций.
Следующий простой пример показывает как незащищённый сайт может подвергнуться CSRF атаке: