□ «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: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: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–кодированию любую выводимую информацию, формируемую на основе поступивших входных данных.

Не рекомендуется

□ Не копируйте ввод в вывод без предварительной проверки.

□ Не храните секретные данные в куках.

Стоит подумать

□ Об использовании как можно большего числа дополнительных защитных мер.

Представьте, что вы присутствуете на конференции, где бесплатно предоставляется доступ к WiFi. При посещении любой Web–страницы или просмотре электронной почты все изображения заменяются фотографией Барбары Стрейзанд или еще какой–нибудь нежелательной картинкой. А тем временем хакер перехватил ваши пароли электронной почты и Интернет–пейджера. Такое уже случалось (к примеру, это стандартный трюк на конференциях типа Defcon), и существуют инструменты, позволяющие безо всякого труда организовать подобную атаку.

Один профессионал в области систем безопасности, бывало, проводил семинары по безопасности электронной почты, а в конце объявлял «счастливого победителя». Тот получал майку с напечатанной на ней информацией о доступе к собственному почтовому ящику. Кто–то за кулисами с помощью анализатора протоколов (снифера) перехватывал имя пользователя и пароль, а потом наносил их на майку. Обидно, честное слово: человек радуется выигрышу, не осознавая, что принял участие в конкурсе помимо собственного желания. А когда понимает, что произошло, радость оборачивается смущением! Это, конечно, все забавы и игры, но печальная истина состоит в том, что при определенных условиях электронная почта благодаря плохо спроектированным протоколам оказывается незащищенной во время передачи.

Такие виды атак возможны потому, что многие сетевые протоколы не предусматривают адекватной защиты данных. Такие важные протоколы, как Simple Mail Transfer Protocol (SMTP) для передачи электронной почты, Internet Message Access Protocol (IMAP) и Post Office Protocol (POP) для доставки почты и HyperText Transfer Protocol (HTTP) для просмотра Web–страниц, не содержат никаких защитных механизмов или, в крайнем случае, предоставляют средства простой аутентификации, которые легко можно атаковать. Конечно, для всех базовых протоколов существуют безопасные альтернативы, но люди редко ими пользуются, потому что устаревшие, менее безопасные протоколы широко распространены. К тому же есть еще немало протоколов, для которых вовсе не существует безопасной альтернативы!

Эта проблема не зависит от языка программирования.

Многие программисты полагают, что после того как данные попали в сеть, противник может разве что прочитать их, но не модифицировать. Часто разработчик вообще не задумывается о конфиденциальности на уровне сети, поскольку заказчик не выдвигал таких требований. Однако существуют инструменты, позволяющие перенаправить трафик и даже манипулировать потоком данных.