В журнал вторжения записывается событие "SECURITY_HOST_RESTRICTION".
Что все это значит и как с этим бороться?
Скорее всего в настройках допустимых хостов проактивной защиты (см. Хосты/домены) указан _только_ адрес "mydomain.com". Поэтому "www.mydomain.com" считается не допустимым и запрос блокируется. Если это так то у вас есть два варианта, зависимых от ваших нужд:
Добавить хост "www.mydomain.com" в список разрешенных
Разрешить все поддомены, т.е. добавить "*.mydomain.com" в список разрешенных
Если ничего не выйдет - обратиться в тех поддержку.
По факту, это ошибка PHP допущенная в версиях 5.4.42, 5.5.26 и 5.6.10: https://bugs.php.net/bug.php?id=69874 Но наши разработчики думают стоит ли её workaround'ить, скорее да чем нет.
Если это не поможет и вы все равно будете получать странный ответ, то можно: 1. Посмотреть ответ сервера при помощи tcpdump/ngrep или запуском davfs2 через отладочный прокси 2. Если вы по прежнему получаете 302 редирект, то скорее всего проблема связана с дублированием заголовка User-Agent. Для этого можно попробовать просто пропатчить davfs2. Для этого нужно найти и закоментировать три строки:
Код
// davfs2/src/webdav.c
# Эти строки закоментированны, т.к. мы сами проставляем нужный UA в конфиге
// char *useragent = ne_concat(PACKAGE_TARNAME, "/", PACKAGE_VERSION, NULL);
// ne_set_useragent(session, useragent);
// free(useragent);
я может чего то не понимаю но поставил 5,1 а версия пхп осталась как и была
По идее, у вас должен был появится пункт в меню управления хостами - "Upgrade php and mysql versions". Насколько я помню, было принято решение, что при обновлении пакета автоматически не будет обновляться php и (особенно!) mysql до новых версий, т.к. это не столь тривиальная задача (e.g. с кластером). Поэтому вы можете пойти и самостоятельно обновить php и mysql, через менюшку, в удобное для вас время.
debug => Ключ отвечает за то, будет ли выведена ошибка на страницу в браузере. Выводить ошибки рекомендуется только на время разработки или отладки. Иначе потенциально может быть разглашение информации.
Или сделать запись в лог (ключ "log"), что более корректно.
Проще всего вам использовать ftp. Для каждого разработчика создаете учетку, для которой домашней папкой будет являться папка с проектом. Все, разработчик никогда не получит доступ к операционной системе и не сможет влезть в папку с чужим проектом.
Вы не правы. Это иллюзия безопасности. По сабжу же - Виртуальная машина действительно не расчитана на использование в качестве шаред хостинга. Одна машинка - один владелец, тчк. Поэтому вы можете на свой страх и риск попробовать изменить её конфигурацию для поддержки этого кейса, но: 1. Как правильно заметил Олег - успех обновления настолько кастомизированной машинки не гарантируется и шансы на успешноебезпроблемное обновление стремятся к нулю 2. Скорее всего у вас не выйдет это сделать своими силами:-) В конфигурировании шариков достаточно много тонкостей связанных с безопасность и даже профессиональные хостеры очень часто косячат с этим.
Иными словами - в общем случае, эта задача не решаема и попытки её решить в рамках виртуальной машинки 1С-Битрикс больше похожи на попытки впихнуть невпихуемое.
Валерий Морозов, а изначально кука устанавливается на стороне сервера или клиента? Если на стороне сервера - проверьте флажок httpOnly, запрещающий работать с кукой на JS. Если все ок, и для этой куки флажок не установлен - покажите пример JS кода и запрос браузера к серверу, т.к., например, если вы забыли указать Expires или Path для этой куки, то в зависимости от браузера получите разное поведение (это отдано на откуп реализации, посему каждый браузер посчитал своим долгом реализовать эту логику по своему)
До обновления было: OpenSSL 1.0.0-fips 29 Mar 2010
после обновления стало: OpenSSL 1.0.1e-fips 11 Feb 2013
Тут важно понимать, что в оригинальном источнике сказано про _оригинальную_ версию OpenSSL без каких либо патчей. Но в некоторых дистрах (CentOS) занимается порочной практикой подкладывания бэкпортов фиксов в старые версии софта, вводя тем самым весь честный люд в заблуждение. Для CentOS фикс вышел в версии 1.0.1e-16.7, можете в этом убедиться сами:
Проверить текущую очень легко, для начала смотрим текущую версию:
Код
root@server1# openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Tue Apr 8 02:33:43 UTC 2014
platform: linux-elf
Обратите внимание на поле built on. Как раз тогда и был пересобран пакетик с патчем отключающим расширение Heartbeat. На всякий случай можно посмотреть информацию о пакетике:
Код
root@server1# yum info openssl
Loaded plugins: etckeeper, fastestmirror, merge-conf
Loading mirror speeds from cached hostfile
* base: mirror.yandex.ru
* epel: mirror.yandex.ru
* extras: mirror.yandex.ru
* updates: mirror.yandex.ru
Installed Packages
Name : openssl
Arch : i686
Version : 1.0.1e
Release : 16.el6_5.7
Size : 3.9 M
Repo : installed
Перезапустите все сервисы использующие OpenSSL и запустите сканер безопасности еще раз, он должен перестать ругаться на OpenSSL. У него тест достаточно стабилен и в отличии от некоторых остальных работает с любой версией TLS.
Смотря какова логика работы, если у Вас предполагается ввод пользовательского HTML-кода - лучше воспользоваться html-санитайзером (CBXSanitizer), если же ввод/вывод только текстовых данных - то htmlspecialcharsbx как говорил Дмитрий.
Цитата
Если на входе вместе с данными записать, например:... то проактивный фильтр зафиксирует XSS внедрение, но данные не превратит в безопасные.
Посмотрите в настройки проактивного фильтра, скорее всего у вас включена активная реакция на вторжение - Оставить опасные данные как есть. В противном случае Вам лучше обратится в нашу тех поддержку.
Такой же головняк! var dates = []; dates[0]="19.06.2013";dates[1]="18.06.2013";dates[2]="17.06.2013";dates[3]="16.06.2013";dates[4]="15.06.2013";dates[5]="14.06.2013";dates[6]="13.06.2013";dates[7]="12.06.2013";dates[8]="11.06.2013";dates[9]="10.06.2013";dates[10]="09.06.2013";dates[11]="08.06.2013";dates[12]="07.06.2013";dates[13]="06.06.2013";dates[14]="05.06.2013";dates[15]="04.06.2013";dates[16]="03.06.2013";dates[17]="02.06.2013";dates[18]="01.06.2013";dates[19]="31.05.2013";dates[20]="30.05.2013";dates[21]="29.05.2013";dates[22]="28.05.2013";dates[23]="27.05.2013";dates[24]="26.05.2013";dates[25]="25.05.2013";dates[26]="24.05.2013";dates[27]="23.05.2013";dates[28]="22.05.2013";dates[29]="21.05.2013";dates[30]="20.05.2013";dates[31]="19.05.2013";dates[32]="18.05.2013";dates[33]="17.05.2013";dates[34]="16.05.2013";dates[35]="15.05.2013";dates[36]="14.05.2013";dates[37]="13.05.2013";dates[38]="12.05.2013";dates[39]="11.05.2013";dates[40]="10.05.2013";dates[41]="09.05.2013";dates[42]="08.05.2013";dates[43]="07.05.2013";dates[44]="06.05.2013";dates[45]="05.05.2013";dates[46]="04.05.2013";dates[47]="03.05.2013";dates[48]="02.05.2013";dates[49]="01.05.2013";dates[50]="30.04.2013";dates[51]="29.04.2013";dates[52]="28.04.2013";dates[53]="27.04.2013";dates[54]="26.04.2013";dates[55]="25.04.2013";dates[56]="24.04.2013";dates[57]="23.04.2013";dates[58]="22.04.2013";dates[59]="21.04.2013";dates[60]="20.04.2013";dates[61]="19.04.2013";dates[62]="18.04.2013";dates[63]="17.04.2013";dates[64]="16.04.2013";dates[65]="15.04.2013";dates[66]="14.04.2013";dates[67]="13.04.2013";dates[68]="12.04.2013";dates[69]="11.04.2013";dates[70]="10.04.2013";dates[71]="09.04.2013";dates[72]="08.04.2013";dates[73]="07.04.2013";dates[74]="06.04.2013";dates[75]="05.04.2013";dates[76]="04.04.2013";dates[77]="03.04.2013";dates[78]="02.04.2013";dates[79]="01.04.2013";dates[80]="31.03.2013";dates[81]="30.03.2013";dates[82]="29.03.2013";dates[83]="28.03.2013";dates[84]="27.03.2013";dates[85]="26.03.2013";dates[86]="25.03.2013";dates[87]="24.03.2013";dates[88]="23.03.2013";dates[89]="22.03.2013";dates[90]="21.03.2013"; Как вы победили это ? Пытаюсь запихнуть этот код в исключения но все равно ругается? Скорее всего из-за того что тело скрипта (даты всегда разные и он думает что это уже другой код) Как загнать этот код под общую маску ?
Скажите, пожалуйста, вашу версию модуля security. Если она ниже 12.5.0 - необходимо обновится, это ложно-положительное срабатывание уже учтено. Если она 12.5.0 или выше - создайте, пожалуйста, обращение в ТП и отправьте мне номер тикета.
Если это обязанность вызывающего кода, то кажется это не очевидно и может нести потенциальные проблемы. Вам Евгений Малков правильно говорит: CFile::MakeFileArray + CFile::SaveFile. не забыв перед вызовом CFile::MakeFileArray проверить URI на корректность.
Насколько я помню вам стоит заглянуть в /etc/php.d (или /etc/php.d/modules не помню точно) и там переименовать curl.ini.disabled в curl.ini После этого рестартануть апач и все у вас заведется