Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Лучшие практики и рекомендации по охране php-приложений от XSS-атак

Anna | 29.05.2014 | нет комментариев

Лучшие практики и рекомендации по охране php-приложений от XSS-атак

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

Множество уязвимостей связано с неправильной обработкой данных, получаемых извне, либо неудовлетворительно суровой их проверкой. Одной из таких уязвимостей является межсайтовое выполнение сценариев (Сross Site Sсriрting, XSS), которая может привести к дефейсу сайта, перенаправлению пользователя на зараженный источник, вставке в веб-источник вредного кода, краже COOKIE-файлов, сессии и прочей информации. Противоборствовать XSS своими сила поможет использование наилучших практик и рекомендаций по безвредному программированию, о которых и пойдет речь ниже.

Лучшие практики и рекомендации:

1. Используйте экранирование выходных данных. Применяйте встроенные функции для чистки кода от вредных скриптов. К ним относятся такие функции как htmlspecialchar(), htmlentities() и strip_tags().
Примеры применения:

$name = strip_tags($_POST['name']); $name = htmlentities($_POST['name'], ENT_QUOTES, "UTF-8"); $name = htmlspecialchars($_POST['name'], ENT_QUOTES);

Встроенные функции PHP, в различие от самописных, работают значительно стремительней, а также имеют поменьше ошибок безопасности и уязвимостей, т.к. непрерывно совершенствуются. Также рекомендуется применять особые библиотеки, построенные на основе встроенных функций и фильтров. В качестве примера дозволено привести OWASP Enterprise Security API (ESAPI), HTML Purifier, Reform, ModSecurity.
Для того Дабы библиотека работала верно, её необходимо заранее настроить!

2. Используйте подход «белые списки». Подход работает по тезису «что не разрешено, то запрещено». Это типовой механизм валидации полей для проверки всех входных данных, включая заголовки, куки, строки запросов, спрятанные поля, а также длина полей форм, их тип, синтаксис, возможные символы и другие правила, раньше чем принять данные, которые будут сохраненные и отображены на сайте. Скажем, если в поле необходимо указать фамилию, нужно позволить только буквы, дефис и пробелы. Если отклонить все остальное, то фамилия д’Арк будет отклонена — отменнее отклонить подлинную информацию, чем принять вредные данные.
К сожалению, со своей задачей встроенные фильтры валидации данных PHP не справляются, следственно рекомендуется писать личные фильтры и «допиливать» их по мере необходимости. Таким образом, со временем ваши входные способы фильтрации будут улучшены. Стоит также не забывать, что существует слишком много типов энергичного содержимого и методов кодирования для обхода сходственных фильтров. По этой же причине не используйте проверку по «черному списку».

3. Указывайте кодировку на всякой веб-странице. Для всякой веб-страницы нужно указывать кодировку (скажем, ISO-8859-1 либо UTF-8) до каких-либо пользовательских полей.
Пример применения:

<?php header("Content-Type: text/html; charset=utf-8"); ?> <!DOCTYPE html> <html> <head> <title>Сharset</title> <meta charset="utf-8"> </head>

либо в файле .htaccess веб-сервера Apache дописать строчку:

AddDefaultCharset UTF-8

Если в http-заголовке либо в метатегах кодировка не указана, браузер пытается сам определить кодировку страницы. Эталон HTML 5 не рекомендует применять такие кодировки, которые включают JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), а также кодировки, основанные на ISO-2022 и EBCDIC. Помимо того, веб-разработчики не обязаны применять CESU-8, UTF-7, BOCU-1 и кодировки SCSU. Эти кодировки никогда не предназначались для веб-контента[1]. В случае если тег размещен до тега и заполняется пользовательскими данными, преступник может вставить вредный html-код в кодировке UTF-7, обойдя, таким образом, фильтрацию таких символов, как ‘<’ и ‘”’.

4. Установить флаг HttpOnly. Данный Флаг делает клиентские куки недостижимыми через языки сценариев, такие как JavaScript.
Данная настройка активируется
— в php.ini [2]:

session.cookie_httponly = True

— в скрипте через функцию session_set_cookie_params() [3]:

void session_set_cookie_params ( int $lifetime [, string $path [, string $domain [, bool $secure = false [, bool $httponly = true ]]]] )

— в веб-приложении через функцию setcookie() [4]:

bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = true ]]]]]] ) 

Эта функция поддерживается последними версиями распространенных браузеров. Впрочем ветхие версии некоторых браузеров через XMLHttpRequest и другие сильные браузерные спецтехнологии обеспечивают доступ для чтения HTTP-заголовков, в том числе и заголовка Set-Cookie, в котором установлен флаг HttpOnly[5].

5. Применять Content Security Policy (CSP). Это заголовок, тот, что разрешает в очевидном виде объявить «белый список» источников, с которых дозволено подгружать разные данные, скажем, JS, CSS, изображения и пр. Даже если преступнику удастся внедрить скрипт в веб-страницу, он не выполниться, если не будет соответствовать разрешенному списку источников.
Для того Дабы воспользоваться CSP, веб-приложение должно через HTTP-заголовок «Content-Security-Policy» посылать политику браузеру.
Пример применения:

Content-Security-Policy: default-src 'self'; script-src trustedscripts.example.com style-src 'self' ajax.googleapis.com; connect-src 'self' https://api.myapp.com realtime.myapp.com:8080; media-src 'self' youtube.com; object-src media1.example.com media2.example.com *.cdn.example.com; frame-src 'self' youtube.com embed.ly

‘Content-Security-Policy’ — это формальный http-заголовок, одобренный W3C, тот, что поддерживается браузерами Chrome 26 , Firefox 24 и Safari 7 . HTTP-заголовок «X-Content-Security-Policy» применяется для Firefox 4-23 и для IE 10-11, заголовок «X-Webkit-CSP» – для Chrome 14-25, Safari 5.1-7[6].

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

6. Регулярно проводите обзор безопасности кода и тестирование на проникновение. Используйте как ручной, так и автоматизированный подходы. Такие инструменты как Nessus, Nikto и OWASP Zed Attack Proxy помогут найти уязвимости XSS в вашем веб-приложении.

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

Пригодные ссылки:
1. HTML Standart. The elements of HTML.
2. PHP: Настройка во время выполнения.
3. PHP: session_set_cookie_params.
4. PHP: setcookie.
5. OWASP HttpOnly.
6. Can I use Content Security Policy.
7. PHP Security Guide. 
8. 2011 CWE/SANS Top 25 Most Dangerous Software Errors. CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’).
9. Introducing Content Security Policy. 
10. OWASP XSS.
11. OWASP Top 10 2013-A3-Cross-Site Scripting (XSS). 
12. OWASP XSS Filter Evasion Cheat Sheet.

Автор статьи: Нештатный работник PentestIT, Сергей Сторчак

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB