19 смертных грехов, угрожающих безопасности программ
Шрифт:
<% Response.Write(Request.QueryString(«Name»)) %>
Или
<img src=\'<%= Request.QueryString(«Name») %>\'>
Греховность форм ASP. NET
В этом примере ASP.NET трактует Web–страницу как форму, из элементов которой можно считывать данные (и записывать тоже), как если бы это была обычная форма Windows. В таком случае найти XSS–ошибку может оказаться не так просто, поскольку запрос и ответ неявно разбираются и формируются ASP.NET во время выполнения.
private void btnSubmit_Click(object sender, System.EventArgs e) {
if (IsValid) {
Application.Lock;
Application[txtName.Text] = txtValue.Text;
Application.UnLock;
lblName.Text = "Hello, " + txtName.Text;
}
}
Греховность JSP
Эти
<% out.println(request.getParameter(«Name»)) %>
Или
<%= request.getParameter («Name») %>
Греховность PHP
Приведенный ниже код читает из строки запроса значение в переменную name, а затем копирует его в ответ:
<?php
$name=$_GET[\'name\'];
if (isset($name)) {
echo "Hello $name";
}
?>
Греховность Perl–модуля CGI.pm
Этот код почти не отличается от примера РНР выше.
#!/usr/bin/perl
use CGI;
use strict;
my $cgi = new CGI;
print CGI::header;
my $name = $cgi->param(\'name\');
print "Hello, $name";
Греховность mod–perl
При использовании mod–perl для вывода HTML–разметки нужно написать чуть больше текста. Но если не считать кода, формирующего заголовки, то это практически то же самое, что приведенные выше примеры на РНР и Perl–CGI.
#!/usr/bin/perl
use Apache::Util;
use Apache::Request;
use strict;
my $apr = Apache::Request->new(Apache->request);
my $name = $apr->param(\'name\');
$apr->content_type(\'text/html\');
$apr->send_http_header;
$apr->print("Hello ");
$apr->print($name);
Где искать ошибку
Любое приложение, обладающее перечисленными ниже признаками, уязвимо для атаки с кросс–сайтовым сценарием:
□ Web–приложение принимает данные из строки запроса, заголовка или формы;
□ приложение не проверяет корректность данных;
□ приложение отправляет принятые данные назад браузеру.
Выявление ошибки на этапе анализа кода
При анализе кода на предмет наличия XSS–ошибок обращайте внимание на места, где используется тот или иной объект запроса, а прочитанные из него данные копируются в объект ответа. Автор этой главы обычно ищет такие конструкции:
Выяснив, где производятся ввод и вывод, проверьте, контролируется ли корректность входных данных. Если нет, возможна XSS–ошибка.
Примечание. Данные могут не копироваться непосредственно из объекта запроса в объект ответа, возможно промежуточное сохранение в базе данных; обращайте внимание и на это тоже.
Хотелось бы отметить еще один важный момент. Многие полагают, что обращение к методу Response.Write и его аналогам – это единственный источник XSS–ошибок.
На самом деле обнаружилось, что конструкции Response.Redirect и Response.SetCookie могут приводить к таким же последствиям; это получило название атаки с расщеплением HTTP–ответа. Вывод таков: любое копирование входных данных в выходные без проверки корректности – это ошибка, угрожающая безопасности. В разделе «Другие ресурсы» приведены ссылки на дополнительные материалы, относящиеся к уязвимостям из–за расщепления HTTP–ответа.Тестирование
Простейший способ протестировать наличие XSS–ошибок – отправить запрос своему Web–приложению, задав всем входным параметрам заведомо небезопасные значения. Затем взгляните на полученный от сервера ответ, не ограничивайтесь только визуальным представлением. Изучите весь поток байтов, чтобы понять, вошли ли в ответ посланные вами данные. Если это так, ваш код может быть уязвим для XSS–атаки. Вот простой Perl–сценарий, который можно положить в основу теста:
#!/usr/bin/perl
use HTTP::Request::Common qw(POST GET);
use LWP::UserAgent;
# Сформировать заголовок, описывающий агента
my $ua = LWP::UserAgent->new;
$ua->agent("XSSInject/v1.40");
# Строки, содержащие внедряемый сценарий
my @xss = (\'><script>alert(window.location);</script>\'\',
\'\"; alert(document.cookie);\',
\'\\' onmouseover=\\'alert(document.cookie);\\' \\'\',
\'\"><script>alert(document.cookie);</script>\',
\'\"></a><script>alert(document.cookie);</script>\',
\'xyzzy\');
# Построить запрос
my $url = "http://127.0.01/form.asp";
my $inject;
foreach $inject (@xss) {
my $req = POST $url, [Name => $inject,
Address => $inject,
Zip => $inject];
my $res = $ua->request($req);
# Получить ответ
# Если мы увидим внедренный сценарий, возможна проблема
$_ = $res->as_string;
print "Возможна XSS-ошибка [$url]\n" if index(lc $_,lc $inject != -1);
}
Примеры из реальной жизни
Следующие примеры XSS–уязвимостей взяты из базы данных CVE (cve.mitre.org).
Уязвимость IBM Lotus Domino для атаки с кросс–сайтовым сценарием и внедрением HTML
По какой–то причине этому бюллетеню не присвоен номер в базе данных CVE. Противник может обойти HTML–кодирование в вычисляемом Lotus Notes значении, добавив квадратные скобки («[" и "]») в начало и конец поля для некоторых типов данных. Подробности на странице www.securityfocus.eom/bid/l 1458.
Ошибка при контроле входных данных в сценарии isqlplus, входящем в состав Oracle HTTP Server, позволяет удаленному пользователю провести атаку с кросс–сайтовым сценарием
И на этот раз у бюллетеня отсутствует номер. Oracle HTTP Server основан на сервере Apache 1.3.x. В сценарии isqlplus есть XSS–ошибка, связанная с недостаточным контролем значений параметров «action», «username» и «password». Атака может выглядеть примерно так:
http://[target]isqlplus?action=logon&username=xyzzy%22%3e%3cscript%3e
alert(\'XSS\')%3c/script%3e\&password=xyzzy%3cscript%3ealert(\'XSS\')%3c
/script%3e
Подробности на странице www.securitytracker.com/alerts/2004/Jan/1008838.html.
CVE–2002–0840
XSS–уязвимость на стандартной странице с сообщением об ошибке в Apache 2.0 до версии 2.0.43 и в Apache 1.3.x до версии 1.3.26. Подробности на странице http://cert.uni–stuttgart.de/archive/bugtraq/2002/10/msg00017.html.
Искупление греха
Путь к искуплению состоит из двух шагов:
1) не допускайте некорректных входных данных. Для проверки обычно применяются регулярные выражения;