Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
public static String encode(String str) {
if (str == null)
return null;
StringBuffer s = new StringBuffer();
for (short i = 0; i < str.length(); i++) {
char c = str.CharAt(i);
switch (c) {
case '<':
s.append("<");
break;
case '>':
s.append(">");
break;
case '(':
s.append("(");
break;
case ')':
s.append(")");
break;
case '#':
s.append("#");
break;
case '&':
s.append("&");
break;
case '"':
s.append(""");
break;
default:
s.append(c);
}
}
return s.toString();
}
}
Ну и наконец пример JSP)страницы, из которой вызывается определенный выше тег:
...<%@ taglib uri="/tags/htmlencoder" prefix="htmlencoder" %>
<head>
<title>Покайся, грешник...</title>
</head>
<html>
<body bgcolor="white">
<htmlencoder:htmlencode><script
type="javascript">BadStuff()</script></htmlencoder:htmlencode>
<htmlencoder:htmlencode>testing</htmlencoder:htmlencode>
<script type="badStuffNotWrapped()"></script>
</body>
</html>
Искупление греха в PHP
Как и в остальных примерах, мы применяем оба лекарства: проверяем входные данные, а затем HTML)кодируем выводимую информацию с помощью функции htmlentities():
...<?php
$name = $_GET['name'];
if (isset($name)) {
if (preg_match('^w{5,25}$/',$name)) {
echo "Hello, " . htmlentities($name);
} else {
echo "Вон отсюда!";
}
}
?>
Искупление греха в Perl/CGI
Идея та же, что в предыдущих примерах: проверить входные данные, сопоставив их с регулярным выражением, а затем HTML–кодировать выводимую информацию.
...#!/usr/bin/perl
use CGI;
use HTML::Entities;
use strict;
my $cgi = new CGI;
print CGI::header();
my $name = $cgi->param('name');
if ($name =~ /^w{5,25}$/) {
print "Hello, " . HTML::Entities::encode($name);
} else {
print "Вон отсюда!";
}
Если вы не хотите или не можете загрузить модуль HTML::Entities, то вот эк)
вивалентный код для решения той же задачи:
sub html_encode
{
my $in = shift;
$in =~ s/&/&/g;
$in =~ s/</</g;
$in =~ s/>/>/g;
$in =~ s/»/"/g;
$in =~ s/#/#/g;
$in =~ s/(/(/g;
$in =~ s/)/)/g;
return $in;
}
Искупление греха в mod–perl
Как и выше, мы проверяем корректность входных данных и HTML–кодируем выходные.
...#!/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;
if ($name =~/^w{5,25}$/) {
$apr->print("Hello, " . Apache::Util::html_encode($name);
} else {
$apr->print "Вон отсюда!";
}
Замечание по поводу HTML–кодирования
Прямолинейное HTML–кодирование всей выводимой информации для некоторых Web–сайтов представляется драконовской мерой, поскольку такие теги, как <1> или <В> безвредны. Чтобы несколько ослабить путы, подумайте, не стоит ли «декодировать» заведомо безопасные конструкции. Следующий фрагмент кода на С# иллюстрирует, что автор называет «HTML–декодированием» тегов, описывающих курсив, полужирный шрифт, начало абзаца, выделение и заголовки:
...Regex.Replace(s,
@"<(/?)(i|b|p|em|hd{1})>",
"<$1$2>",
RegexOptions.IgnoreCase);
Дополнительные защитные меры
В Web–приложение можно включить много дополнительных механизмов защиты на случай, если вы пропустили XSS–ошибку, а именно:
□ добавить в кук атрибут httponly. Это спасет пользователей Internet Explorer версии (6.0) (и последующих), поскольку помеченный таким образом кук невозможно прочитать с помощью свойства document.cookie. Подробнее см. ссылки в разделе «Другие ресурсы». В ASP.NET 2.0 добавлено свойство HttpCookie.HttpOnly, упрощающее решение этой задачи;
□ заключать в двойные кавычки значения атрибутов тега, порождаемые из входных данных. Пишите не <img src=someinput>, a <img src=«someinput»>. Это сводит на нет атаки, которые могли бы обойти HTML–кодирование. Подробно этот прием объясняется в книге Майкла Ховарда и Дэвида Леб–ланка «Защищенный код», 2–ое издание (Русская редакция, 2004);
□ если вы пользуетесь ASP.NET, проверьте, задан ли конфигурационный параметр ValidateRequest. По умолчанию он задан, но лишний раз проверить не мешает. В этом случае запросы и ответы, содержащие недопустимые символы, будут отвергаться. Стопроцентной гарантии этот метод не дает, но все же является неплохой защитой. Подробнее см. раздел «Другие ресурсы»;
□ для Apache mod_perl есть модуль Apache::TaintRequest, помогающий обнаружить входные данные, которые копируются в выходные без проверки. Подробнее см. раздел «Другие ресурсы»;
□ предлагаемая Microsoft программа UrlScan для Internet Information Server 5.0 обнаруживает и обезвреживает многие варианты XSS–уязвимостей в коде вашего приложения.
Примечание. Для Internet Information Server 6.0 (IIS6) расширение UrlScan не нужно, так как его функциональность уже встроена в сам сервер. Подробнее см. раздел «Другие ресурсы».
Другие ресурсы
□ «Writing Secure Code, Second Edition» by Michael Howard and David C. LeBlanc (Microsoft Press, 2002), Chapter 13 «Web–specific Input Issues»
□ Mitigating Cross–site Scripting With HTTP–only Cookies: http://msdn. microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_ cookies.asp
□ Request Validation – Preventing Script Attacks: www.asp.net/faq/ requestvalidation.aspx
□ mod_perl Apache::TaintRequest: www.modperlcookbook.org/code.html
□ «UrlScan Security Tool»: www.microsoft.com/technet/security/tools/ urlscan.mspx
□ «Divide and Conquer – HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics»: www.securityfocus.com/archive/1/356293
□ «Prevent a cross–site scripting attack» ny Anand K. Sharma: www–106. ibm.com/developerworks/library/wa–secxss/?ca=dgr–lnxw93PreventXSS
□ «Prevent Cross–site Scripting Attacks» by Paul binder: www.perl.eom/pub/a/ 2002/02/20/css.html
□ «CERT Advisory CA–2000–02 Malicious HTML Tags Embedded in Client Web Requests»: www.cert.org/advisories/CA–2000–0.html
□ The Open Web Application Security Project (OWASP): www.owasp.org
□ «HTML Code Injection and Cross–site Scripting» by Gunter Oilman: www.technicalinfo.net/papers/CSS.html
□ Building Secure ASP.NET Pages and Controls: http://msdn/microsoft.com/ library/default.asp?url=/library/en–us/dnnetsec/html/THCMChl0.asp
□ Understanding Malicious Content Mitigation for Web Developers: wwweert. org/ tech_tips/malicious_code_mitigation. html
□ How to Prevent Cross–Site Scripting Security Issues in CGI or ISAPI: support. microsoft.com/default.aspx?scid=kb%3BEN–US%3BQ253165
□ Hacme Bank: www.foundstone.com/resources/proddesc/hacmebank.htm
□ WebGoat: www.owasp.org/software/webgoat.html
Резюме
Рекомендуется
□ Проверяйте корректность всех входных данных, передаваемых Web–приложению.
□ Подвергайте HTML–кодированию любую выводимую информацию, формируемую на основе поступивших входных данных.
Не рекомендуется
□ Не копируйте ввод в вывод без предварительной проверки.
□ Не храните секретные данные в куках.
Стоит подумать
□ Об использовании как можно большего числа дополнительных защитных мер.
Грех 8. Пренебрежение защитой сетевого трафика
В чем состоит грех
Представьте, что вы присутствуете на конференции, где бесплатно предоставляется доступ к WiFi. При посещении любой Web–страницы или просмотре электронной почты все изображения заменяются фотографией Барбары Стрейзанд или еще какой–нибудь нежелательной картинкой. А тем временем хакер перехватил ваши пароли электронной почты и Интернет–пейджера. Такое уже случалось (к примеру, это стандартный трюк на конференциях типа Defcon), и существуют инструменты, позволяющие безо всякого труда организовать подобную атаку.
Один профессионал в области систем безопасности, бывало, проводил семинары по безопасности электронной почты, а в конце объявлял «счастливого победителя». Тот получал майку с напечатанной на ней информацией о доступе к собственному почтовому ящику. Кто–то за кулисами с помощью анализатора протоколов (снифера) перехватывал имя пользователя и пароль, а потом наносил их на майку. Обидно, честное слово: человек радуется выигрышу, не осознавая, что принял участие в конкурсе помимо собственного желания. А когда понимает, что произошло, радость оборачивается смущением! Это, конечно, все забавы и игры, но печальная истина состоит в том, что при определенных условиях электронная почта благодаря плохо спроектированным протоколам оказывается незащищенной во время передачи.
Такие виды атак возможны потому, что многие сетевые протоколы не предусматривают адекватной защиты данных. Такие важные протоколы, как Simple Mail Transfer Protocol (SMTP) для передачи электронной почты, Internet Message Access Protocol (IMAP) и Post Office Protocol (POP) для доставки почты и HyperText Transfer Protocol (HTTP) для просмотра Web–страниц, не содержат никаких защитных механизмов или, в крайнем случае, предоставляют средства простой аутентификации, которые легко можно атаковать. Конечно, для всех базовых протоколов существуют безопасные альтернативы, но люди редко ими пользуются, потому что устаревшие, менее безопасные протоколы широко распространены. К тому же есть еще немало протоколов, для которых вовсе не существует безопасной альтернативы!
Подверженные греху языки
Эта проблема не зависит от языка программирования.
Как происходит грехопадение
Многие программисты полагают, что после того как данные попали в сеть, противник может разве что прочитать их, но не модифицировать. Часто разработчик вообще не задумывается о конфиденциальности на уровне сети, поскольку заказчик не выдвигал таких требований. Однако существуют инструменты, позволяющие перенаправить трафик и даже манипулировать потоком данных.
Большинство людей считают, что данные поступают в сеть слишком быстро для того, чтобы противник сумел вклиниться в поток, а потом они передаются от одного маршрутизатора другому, где находятся в безопасности. Программисты, работающие в сетях, оборудованных коммутаторами, часто уверены, что никаких проблем возникнуть не может.
