Сообщение об этой угрозе можно увидеть, когда директория хранения файловых сессий PHP (session.save_path (phpinfo), по умолчанию /tmp) доступна для всех (other), например:

		 $ stat -c 'Perms: %A' /tmp Perms: drwxrwxrwt
	

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

Если настройка производится самостоятельно, то необходимо создать другую папку (можно даже внутри /tmp, в большинстве случаев) и выставить на неё корректные файловые права, затем указать её в настройках php. Настраивая этот параметр, учтите что у вас есть все шансы загубить авторизацию на сайте или же отключить garbage collector сессионых файлов. Посему - лучше обратитесь к специалисту или в ТП хостинга.

Подобное сообщение можно встретить, если несколько сайтов используют одну директорию для хранения сессий. Очень часто это можно встретить при использовании выделенных серверов, когда есть N сайтов и все они хранят свои сессии где-нибудь в /tmp/php_sess. Начиная с версии модуля main 12.5.0 это стало не столь критично, но, тем не менее, стоит это исправить, указав собственную директорию хранения сессий для каждого сайта.

Чем это опасно? При такой конфигурации сессии получаются "сквозные", т.е., допустим, есть сайт A и сайт B:
a) Мы регистрируемся на сайте B, получаем идентификатор пользователя 7;
b) Теперь зайдя на сайт A с идентификатором сессии от сайта B, мы окажемся авторизованными под пользователем с идентификатором 7, но сайта A (а что если пользователь с идентификатором 7 на сайте A администратор?).

Используя API Битрикс, пользователь сайта не может загрузить .php, .py, .psp, .pl и т.д. файлы без наличия необходимых прав. Но, к сожалению, как в пользовательском коде, так и в коде разработчиков "Маркетплейс" все еще встречается "кастомная" загрузка файлов, которая может позволить загрузить файлы с потенциально опасными расширениями. Именно поэтому лучше исключить эту возможность, корректно сконфигурировав ваш веб-сервер.

Аналогично предыдущему, только вектор атаки через загрузку файлов направлен на загрузку .htaccess файлов с "кастомными" конфигурациями. Например, такой:

		 <Files ~ "^\.ht"> Order allow,deny Allow from all </Files> AddHandler zend-enabler-script .htaccess <IfModule mod_mime.c> AddType application/x-httpd-php .htaccess </IfModule> #<?php assert($_GET[0]); ?>
	

		 $ find ./upload -type f -name '.htaccess' -print -exec cat {} \; ./upload/support/not_image/.htaccess Deny from all ./upload/.htaccess <IfModule mod_mime.c> RemoveHandler php .php3 .php4 .php5 .php6 .phtml .pl .asp .aspx .cgi .dll .exe .ico .shtm .shtml .fcg .fcgi .fpl .asmx .pht .py .psp AddType text/plain php .php3 .php4 .php5 .php6 .phtml .pl .asp .aspx .cgi .dll .exe .ico .shtm .shtml .fcg .fcgi .fpl .asmx .pht .py .psp </IfModule> <IfModule mod_php5.c> php_flag engine off </IfModule>
	

		 <Directory /home/bitrix/www/upload/support/not_image> AllowOverride none Order allow,deny Deny from all </Directory> <Directory /home/bitrix/www/upload> AllowOverride none AddType text/plain php .php3 .php4 .php5 .php6 .phtml .pl .asp .aspx .cgi .dll .exe .ico .shtm .shtml .fcg .fcgi .fpl .asmx .pht .py .psp php_value engine off </Directory>
	

Суть проблемы заключается в том, что в конфигурации Apache по умолчанию можно встретить такую строку:

		 AddHandler type-map .var
	

		 GIF89: any Content-language: ru Content-type: text/html; Body:----------ru-- <img src=x onerror=prompt(/XSS/)> ----------ru--
	

		 $ http -v http://bus-win.my/upload/test.var.gif GET /upload/test.var.gif HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate, compress Host: bus-win.my User-Agent: HTTPie/0.7.2 HTTP/1.1 200 OK Accept-Ranges: bytes Content-Language: ru Content-Length: 34 Content-Type: text/html Date: Sun, 27 Oct 2013 09:57:40 GMT Server: Apache/2.4.3 (Unix) OpenSSL/1.0.1c PHP/5.4.7 <img src=x onerror=prompt(/XSS/)>
	

Эта возможность придает гибкости Apache для обработки мультиязычной статики, но безопасности вашего сайта только вредит.

Чтобы оградить разработчика от "сюрпризов" и повысить безопасность сайта - allow_url_fopen должен быть Off.

Имеется в виду, что при установке cookie ваш сайт не передает дополнительный флаг httpOnly для HTTP-заголовка Set-Cookie, который указывает на запрет чтения/записи данных Cookie посредством JavaScript, отсюда и название. XSS атаки наиболее распространены, и получить пользовательские cookies это самый простой их вектор (сейчас все чаще XSS нападение используется для CSRF атак). Поэтому необходимо использовать любую возможность для уменьшения рисков. Флаг httpOnly рекомендуется указывать как минимум для ID сессии, для этого достаточно в настройках PHP указать:

		 session.cookie_httponly = On
	

Ссылки по теме:

• httpOnly (owasp.org);
• Директива PHP session.cookie_httponly.

Отсутствие дополнительной энтропии может использоваться для предугадывания случайных чисел. Необходимо в настройках php указать:

		 session.entropy_file = /dev/urandom
         session.entropy_length = 128"
	

		 asp_tags = Off
	

		 session.use_only_cookies = On
	

		 display_errors = Off
	

Так как администратор сайта вправе изменять этот список по своему усмотрению, он может устаревать со временем (когда мы решаем добавить какое-либо расширение в список опасных, к примеру, как было с var). Сканер безопасности сообщит, если в кастомизированном списке содержатся не все необходимые расширения.

Выключенный проактивный фильтр не сможет отразить попытки нападения на ресурс.

Редирект на произвольный сторонний ресурс может служить подспорьем для множества атак, защита редиректов исключает эту возможность (при использовании стандартного API).

Пониженный уровень безопасности административной группы может значительно помочь злоумышленнику.

Отладка SQL запросов может раскрыть важную информацию о ресурсе. Рекомендуется установить значение переменной \$DBDebug в false.

• Пароль к базе данных пустой
• Символы пароля к БД в одном регистре
• Пароль к БД не содержит чисел
• Пароль к БД не содержит спецсимволов(знаков препинания)
• Длина пароля к БД меньше 8 символов

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

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

То же самое, что и в предыдущем пункте. Необходимо оповестить администраторов сайта о необходимости использования OTP.

Включенный Directory AutoIndex встречается повсеместно и сулит как минимум неконтролируемым доступом к загруженным пользовательским файлам. Для nginx необходимо убрать директиву autoindex, она выглядит примерно так:

		 location / { autoindex on; ...}
	

		 <Directory /home/bitrix/www> Options +Indexes </Directory>
	

Всегда помните - все сервисы, необходимые только сайту, не должны быть видны "наружу". Случаи неконтролируемого доступа к критически важным сервисам (например, memcached) - совсем не редкость. Это важный момент, т.к. доступ к memcached, где ваш сайт хранит свой кеш - это, по сути, полный контроль над ним. Если вы пользуетесь shared-хостингом - это отличный повод для "беседы" с ним. Если у вас не кластерная архитектура проекта, то правильнее всего использовать unix-сокет, когда у вас memcached используется для кластера - корректные настройки firewall + SASL.

Есть уязвимость в PHP: CVE-2012-1823. Она позволяет как читать файлы вашего сайта (/some_script.php?-s), так и в большинстве случаев исполнять произвольный php-код в контексте вашего сайта.
Рекомендуется незамедлительно обновить версию PHP, либо не использовать php-cgi вовсе.

К сожалению, в интернете все еще достаточно много ужасных "How To" по настройке связки nginx + php-fpm, в которых ни слова не сказано о том, что php-fpm с конфигурацией по умолчанию и location в nginx примерно следующего содержания:

		 location ~* \.php$ { fastcgi_pass backend; ...}
	

К примеру, обратившись к аватару пользователя таким образом: /upload/main/f6f/photo.jpg/some.php, злоумышленник выполнит php-код, содержащийся в аватаре (например в EXIF или конце PNG).

Наиболее распространенными вариантами решения является либо указание в php.ini (если это удовлетворяет требованиям вашего проекта):

		 cgi.fix_pathinfo=0
	

Так называемые статус-страницы позволяют злоумышленникам получить дополнительную информацию о вашем сайте, которая им столь нужна. Не стоит их радовать. Рекомендуем ограничить доступ к ним, а ещё лучше – отключить/закрыть авторизацию, т.к. доверять localhost также не стоит.

Наиболее распространенные:

• Apache mod_status;
• PHP-FPM Status Page - pm.status-path.

При редактировании файлов на сервере по SSH или при использовании DCVS могут создаваться временные копии текущих файлов, в которых может содержаться важная информация (например, все еще актуальные данные о подключении к БД).

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

Так же достаточно часто встречаются сайты, на которых остались какие-то файлы после отладки, установки и т.д.
Например: bitrixsetup.php, bx_1c_import.php, restore.php, log.txt и т.д.

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

Еще одна частая проблема - доступны настройки PhpMyAdmin (директория setup в новых версиях). Они как минимум позволяют прочесть текущую конфигурацию PhpMyAdmin и, вдобавок, в них постоянно находятся новые уязвимости. Внешнее сканирование сообщит, "куда нужно смотреть".

Как ни странно - публичный доступ к служебным каталогам DCVS все еще достаточно актуальное явление. Зачастую это крайне опасно для вашего сайта - необходимо в срочном порядке закрыть доступ к таким каталогам (.git, .hg, .bzr и т.д.) и к файлам игнорирования (.gitignore, .hgignore и т.д.). В идеале необходимо пользоваться экспортом в вашей DCVS. Разумеется, внешнее сканирование сообщит, "куда нужно смотреть".

Эта ошибка по своей сути ничто иное как, проверка включена ли у вас защита от фреймов. Суть защиты заключается в запрете отображения целевого сайта во фрейме со стороннего сайта или запрете работы во фреймах вовсе. Это рекомендованная настройка нужна для предотвращения целого класса client-side атак (например, таких как Clickjacking, Framesniffing и т.п.).

Это, пожалуй, одна из самых распространенных ошибок конфигурации для выделенных серверов. Суть проблемы заключается в том, что сайт отвечает на любой Host в заголовке запроса, вследствие чего, например, если $_SERVER["HTTP_HOST"] попадет в кеш компонента, то получаем классический content spoofing.

Проверить очень легко, запрашиваем наш сайт с правильным хостом:

		 $ http -v head some.info HEAD / HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate, compress Host: some.info User-Agent: HTTPie/0.6.0 HTTP/1.1 200 OK Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: keep-alive Content-Encoding: gzip Content-Type: text/html; charset=windows-1251 Date: Fri, 25 Oct 2013 06:57:31 GMT Expires: Thu, 19 Nov 1981 08:52:00 GMT P3P: policyref="/bitrix/p3p.xml", CP="NON DSP COR CUR ADM DEV PSA PSD OUR UNR BUS UNI COM NAV INT DEM STA" Pragma: no-cache Server: nginx/1.2.6 Set-Cookie: PHPSESSID=vp93uc1j3avoibvfkusn5p6gc5; path=/; HttpOnly X-Frame-Options: SAMEORIGIN X-Powered-CMS: Bitrix Site Manager (a0b80388d20et47833773cf8f6b7c738)
	

		 $ http -v head some.info 'Host: batman.inc' HEAD / HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate, compress Host: batman.inc User-Agent: HTTPie/0.6.0 HTTP/1.1 200 OK Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: keep-alive Content-Encoding: gzip Content-Type: text/html; charset=windows-1251 Date: Fri, 25 Oct 2013 06:57:35 GMT Expires: Thu, 19 Nov 1981 08:52:00 GMT P3P: policyref="/bitrix/p3p.xml", CP="NON DSP COR CUR ADM DEV PSA PSD OUR UNR BUS UNI COM NAV INT DEM STA" Pragma: no-cache Server: nginx/1.2.6 Set-Cookie: PHPSESSID=55up92i9r2sorg24j78lud9li2; path=/; HttpOnly X-Frame-Options: SAMEORIGIN X-Powered-CMS: Bitrix Site Manager (a0b80388d20et47833773cf8f6b7c738)
	

		 server { listen 80 default_server; access_log /var/log/nginx/default.host.access.log main; return 301 $scheme://domain.com$request_uri; }
	

Подробнее можно посмотреть в документации nginx.

С завидным постоянством на сайтах можно увидеть файлы x.php, pi.php, phpinfo.php и т.д. с выводом phpinfo().
Эти файлы не должны быть доступны.

Внешнее сканирование укажет список таких файлов, которые необходимо удалить и впредь использовать встроенную в страницу административного интерфейса ссылку (Настройки > Производительность > PHP, ссылка Настройки PHP) с выводом phpinfo().

По умолчанию в Internet Explorer включен mime-сниффинг (MIME Type Detection in Windows Internet Explorer), что никак не идет на пользу безопасности пользователей вашего сайта. В двух словах, если в заголовке ответа Content-Type сказано text/plain, application/octet-stream, он отсутствует либо пуст - Internet Explorer сам решает какой тип у контента, основываясь на его содержимом (начиная с Internet Explorer 8 этим поведением можно управлять при помощи заголовка X-Content-Type-Options).

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

• Загружаем через него файл test.gif с содержимым:

  			 GIF89 <html> <script> prompt('XSS on ' + document.domain); </script> </html>
  		

• Т.к. это вполне "валидная" картинка с позиции PHP, она благополучно попадет на сервер, но сохранится без расширения (по условиям примера). Допустим, будет доступна по адресу: http://192.168.1.185:8080/upload/test.
• Для начала проверяем, как его обработает Internet Explorer 10 с включенным mime-сниффингом:

  			 $ http head http://192.168.1.185:8080/upload/test HTTP/1.1 200 OK Accept-Ranges: bytes Connection: keep-alive Content-Length: 80 Content-Type: application/octet-stream Date: Sun, 27 Oct 2013 12:14:45 GMT ETag: "526d026b-50" Last-Modified: Sun, 27 Oct 2013 12:09:15 GMT Server: nginx/1.4.3
  		

  Т.к. тип отдаваемого контента application/octet-stream (по умолчанию, регулируется директивой default_type), Internet Explorer включает mime-сниффинг, и мы видим, что наша "картинка" была обработана как html-код:

  

• А теперь с заголовком X-Content-Type-Options: nosniff.

  В nginx это можно сделать через add_header:

  			 add_header X-Content-Type-Options nosniff;
  		

  Проверяем:

  			 $ http head http://192.168.1.185:8080/upload/test HTTP/1.1 200 OK Accept-Ranges: bytes Connection: keep-alive Content-Length: 80 Content-Type: application/octet-stream Date: Sun, 27 Oct 2013 12:18:21 GMT ETag: "526d026b-50" Last-Modified: Sun, 27 Oct 2013 12:09:15 GMT Server: nginx/1.4.3 X-Content-Type-Options: nosniff
  		

  И видим, что Internet Explorer теперь предлагает нам сохранить этот файл: