АФАИК надо предупреждать сперва создателей движка, и только через 30 дней общественность, дабы не провоцировать хакеров и дать время разработчикам на патч.
Хотя я года 2 тому назад отослал нижеследующее письмо и никакой реакции... Так что думаю всем на всё плевать хотя и жаль.
***Предисловие***
Мысли о безопасности RSDN не покидают меня (В этом месте я плакал). Всем давно известно, что вставка голого HTML в текст сообщений есть плохо. Это плохо по следующим причинам:
1) В этом HTML могу содержаться разные теги, в том числе те на вставку которых ты не рассчитывал.
2) В результате такого художества, когда каждый может указать <font color=red>ВАЖНОЕ СЛОВО</font>, форум постепенно превращается в зеркало сайта www.Brazilsky-Karnaval.ru.
3) Отсутствуют стандартные методы отображения эмоций и пользователи употребляют так называемые смайлики с разных сайтов, которые в свою очередь могут изменить место расположения.
Очевидным решением данной проблемы является употребления своих методов форматирования текста транслируемых далее в HTML теги форматирования. Несмотря на очевидные преимущества и здесь есть подводные камни. Это встраиваемые изображения и ссылки. Коды форматирования RSDN и HTML теги [img][/img] <img src = ></img> <a href = ></a> соответственно. Опасны эти теги, очевидно, тем, что ссылаются на произвольный URL и могут выполнять произвольный код как на стороне сервера в случае с img, так и на стороне клиента и сервера в случае с url/a. Несмотря на большие возможности тега url/a более опасен тег img так как для выполнения его кода достаточно просмотра страницы, а для выполнения тега url/a необходимо щёлкнуть по ссылке, действие которое пользователь может и не выполнить. При открытии ссылок по протоколу HTTP серверу всегда передаётся некоторая информация о клиенте. Скриптам/CGI-приложениям сервера эта информация доступна в виде переменных. Например для нас наиболее интересны переменные HTTP_USER_AGENT и REMOTE_ADDR. В первой переменной содержится информация о браузере из которого просматривают URL, во второй IP адрес хоста с которого просматривают URL.
// Открыть файл requests/hack.txt на запись и установить указатель в конец файла.
$log = fopen("requests/hack.txt","a");
// Записать переменные HTTP_USER_AGENT и REMOTE_ADDR и аннотацию к ним в файл.
fwrite($log,"HTTP_USER_AGENT : ".$_SERVER["HTTP_USER_AGENT"]."\r\n");
fwrite($log,"REMOTE_ADDR : ".$_SERVER["REMOTE_ADDR"]."\r\n");
fwrite($log,"DATE/TIME : ".date("Y-m-d H:i:s")."\r\n");
fwrite($log,"\r\n");
// Закрыть файл
fclose($log);
Конец PHP скрипта.
?>
Данный скрипт взят из книги А. Павлова CGI-Программирование(издательство Питер 2001г, ISBN 5-272-00242-3, страница 134) и портирован с PERL на PHP, что ввиду похожести языков не составило большого труда. При портировании использовалась стандартная документация к интерпретатору PHP. Таким образом, указанная методика не является чем-то сложным или секретным.
Можно было бы так же анализировать переменные HTTP_ACCEPT_LANGUAGE и HTTP_ACCEPT_CHARSET, весьма точно при этом определив географическое месторасположение пользователя.
***Опасность***
Получив в файле hack.txt строки вида (В этом месте я тоже плакал)
HTTP_USER_AGENT : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705)
REMOTE_ADDR : 12.236.94.62
DATE/TIME : 2003-01-11 01:30:22
Я знаю не только IP адрес пользователя, но и версию его ОС и количество дополнительных обновлений безопасности установленных у него. Путём простой статистики за неделю по IP адресам я могу с лёгкостью вычислить всех пользователей со статическим IP адресом. Дальнейшее дело моёй совести.
Не вставлять в сообщение изображения, чей URL заканчивается не на .BMP .GIF .JPG .JPEG. Данный список расширений вполне достаточен для повседневного употребления и хотя этот метод не защищает от атаки указанной выше, он сильно снижает её вероятность, поскольку очень мало людей имеют свой сервер, на котором можно расширению .GIF сопоставить интерпретатор ну скажем perl-а.
P.S.
По правилам о всяком упущении в системе безопасности сперва сообщается разработчикам и, если не было принято никаких мер, через 30 дней общественности.
Здравствуйте, adontz, Вы писали:
A>Хотя я года 2 тому назад отослал нижеследующее письмо и никакой реакции... Так что думаю всем на всё плевать хотя и жаль.
Не помню, как это делается в ASP.NET , но в php для каждого параметра в URL достаточно сделать проверку на htmlspecialchars.
Про шпионаж за переменными окружения.
1) Если у человека есть права на добавление скриптов, то наверняка, есть доступ и к .htaccess своего сайта. Сделать там RewriteUrl или что-нибудь подобное — как нефиг делать.
2) Также можно просто создать каталог /cgi-bin/image.gif/ в корень которого закинуть index.pl
3) Даже этого не нужно. Много интересного есть прямо в логах сервера.
Перекуём баги на фичи!
Re[2]: Дырки. Некорректная обработка входных данных.
Здравствуйте, der Igel, Вы писали:
DI>Тут я не совсем догоняю... В чём опасность?
В alert() никакой, а если использовать Scripting.FileSystemObject или просто внедрять ActiveX какой-нибудь или элементарно взять кукисы...
Да мало ли что можно придумать?
Hello, adontz!
DI>> Тут я не совсем догоняю... В чём опасность?
a> В alert() никакой, а если использовать Scripting.FileSystemObject или a> просто внедрять ActiveX какой-нибудь или элементарно взять кукисы... Да a> мало ли что можно придумать?
Ну будет Scripting.FileSystemObject в урл светиться и что?
Я конкретно про вторую ссылку, которую привёл Олег.
Posted via RSDN NNTP Server 1.9 delta
Re[3]: Дырки. Некорректная обработка входных данных.
и ссылки. Коды форматирования RSDN и HTML теги [img][/img] <img src = ></img> <a href = ></a> соответственно. Опасны эти теги, очевидно, тем, что ссылаются на произвольный URL и могут выполнять произвольный код как на стороне сервера в случае с img, так и на стороне клиента и сервера в случае с url/a. Несмотря на большие A>
Вывод — сделать тег [img] дейтсвующим только в пределах сайта, т.е. на закаченные рисунки и на те что уже есть на сервере, остальные же делать в виде ссылки на новую страницу.. Те пользователи, которые хотят открыть ссылку — сделают это, и это уже будет на их совести.
Нет ничего невозможного..
Re[6]: Дырки. Некорректная обработка входных данных.
Hello, Олег!
DI>> Тут я не совсем догоняю... В чём опасность?
ОГ> Ну скажем так, некорректное поведение. Такого mid не существует. Хотя ОГ> скрипт его всё-же пытается обработать.
Да никакого mid'а и нет...
Этот же скрипт и в статьях, например, используется, где может быть любой урл.
Posted via RSDN NNTP Server 1.9 delta
Re[7]: Дырки. Некорректная обработка входных данных.
Здравствуйте, der Igel, Вы писали:
DI>Hello, adontz!
a>> Главное, что подорвётся авторитет РСДН как безопасной системы. Тебе a>> охота заходить на сайт, где тебя могут поломать?
DI>Ну хоть убейте, не догоняюю... DI>Если я такую ссылку напишу http://rsdn.ru/?hack=Scripting.FileSystemObject — я поломал РСДН?
20 декабря 2004 года, 13:09 [прямая ссылка]
В системе UseModWiki, предназначенной для создания так называемых Wiki-сайтов, использующихся для коллективного сбора, редактирования и хранения информации, обнаружена уязвимость. Дыра, связанная с некорректной обработкой входных данных, теоретически обеспечивает возможность проведения XSS-атак (Cross-Site Scripting) на удаленные компьютеры. Нападение может быть осуществлено через сформированную особым образом ссылку. В качестве примера вредоносного запроса эксперты приводят строку "http://[target]/cgi-bin/wiki.pl?<script>alert('XSSvulnerabilityexists')</script>". Брешь присутствует в программе UseModWiki версии 1.0, способов устранения уязвимости на сегодняшний день не существует.
Hello, adontz!
DI>> Я исправил только первый пункт, который и не отрицал. DI>> Второй как был — так и остался. Вот и продемонстрируй.
a> Не, эффектно было именно с использованием первой ссылки
Так, как я понял, мой конкретный вопрос о том, чем грозит второй пункт остался без ответа и его можно считать закрытым — никакой
опасности нет?
хотя и жаль.
, но в php для каждого параметра в URL достаточно сделать проверку на htmlspecialchars.
Перекуём баги на фичи!
