19 смертных грехов, угрожающих безопасности программ
Шрифт:
□ «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
Резюме
Рекомендуется
□
□ Подвергайте HTML–кодированию любую выводимую информацию, формируемую на основе поступивших входных данных.
Не рекомендуется
□ Не копируйте ввод в вывод без предварительной проверки.
□ Не храните секретные данные в куках.
Стоит подумать
□ Об использовании как можно большего числа дополнительных защитных мер.
Грех 8. Пренебрежение защитой сетевого трафика
В чем состоит грех
Представьте, что вы присутствуете на конференции, где бесплатно предоставляется доступ к WiFi. При посещении любой Web–страницы или просмотре электронной почты все изображения заменяются фотографией Барбары Стрейзанд или еще какой–нибудь нежелательной картинкой. А тем временем хакер перехватил ваши пароли электронной почты и Интернет–пейджера. Такое уже случалось (к примеру, это стандартный трюк на конференциях типа Defcon), и существуют инструменты, позволяющие безо всякого труда организовать подобную атаку.
Один профессионал в области систем безопасности, бывало, проводил семинары по безопасности электронной почты, а в конце объявлял «счастливого победителя». Тот получал майку с напечатанной на ней информацией о доступе к собственному почтовому ящику. Кто–то за кулисами с помощью анализатора протоколов (снифера) перехватывал имя пользователя и пароль, а потом наносил их на майку. Обидно, честное слово: человек радуется выигрышу, не осознавая, что принял участие в конкурсе помимо собственного желания. А когда понимает, что произошло, радость оборачивается смущением! Это, конечно, все забавы и игры, но печальная истина состоит в том, что при определенных условиях электронная почта благодаря плохо спроектированным протоколам оказывается незащищенной во время передачи.
Такие виды атак возможны потому, что многие сетевые протоколы не предусматривают адекватной защиты данных. Такие важные протоколы, как Simple Mail Transfer Protocol (SMTP) для передачи электронной почты, Internet Message Access Protocol (IMAP) и Post Office Protocol (POP) для доставки почты и HyperText Transfer Protocol (HTTP) для просмотра Web–страниц, не содержат никаких защитных механизмов или, в крайнем случае, предоставляют средства простой аутентификации, которые легко можно атаковать. Конечно, для всех базовых протоколов существуют безопасные альтернативы, но люди редко ими пользуются, потому что устаревшие, менее безопасные протоколы широко распространены. К тому же есть еще немало протоколов, для которых вовсе не существует безопасной альтернативы!
Подверженные греху языки
Эта проблема не зависит от языка программирования.
Как происходит
Многие программисты полагают, что после того как данные попали в сеть, противник может разве что прочитать их, но не модифицировать. Часто разработчик вообще не задумывается о конфиденциальности на уровне сети, поскольку заказчик не выдвигал таких требований. Однако существуют инструменты, позволяющие перенаправить трафик и даже манипулировать потоком данных.
Большинство людей считают, что данные поступают в сеть слишком быстро для того, чтобы противник сумел вклиниться в поток, а потом они передаются от одного маршрутизатора другому, где находятся в безопасности. Программисты, работающие в сетях, оборудованных коммутаторами, часто уверены, что никаких проблем возникнуть не может.
Но в реальном мире противник, оборудовавший себе плацдарм в локальной сети по любую сторону от маршрутизатора, занимает прекрасную позицию для организации атаки на сеть в силу отсутствия защитных мер в инфраструктуре сети–жертвы. Если противник находится в том же сегменте сети, что и одна из оконечных точек (например, подключен к концентратору), то он может просматривать весь трафик в этом сегменте и обычно способен перехватить его. Но даже если противник подключен к коммутатору (концентратор, в котором отдельные порты не «видят» трафика на других портах), то и тогда техника подлога по протоколу ARP (Address Resolution Protocol – протокол разрешения адресов) позволяет ему притвориться шлюзом и перенаправить на себя весь трафик. Обработав трафик, противник может отправить его первоначальному адресату. Есть и другие методы. Например, некоторые коммутаторы можно затопить потоком ARP–запросов, в результате чего они переходят в пропускающий (promiscuous) режим и начинают работать как обычный концентратор.
Как все это реализуется? ARP – это протокол, отображающий адреса уровня 2 (Ethernet MAC) на адреса уровня 3 (IP). Противник может объявить, что его собственный МАС–адрес соответствует IP–адресу шлюза. Когда остальные машины видят такое объявление, они начинают маршрутизировать весь трафик через компьютер противника. У этой проблемы нет практичного и универсального решения, которое можно было бы реализовать быстро, поскольку речь идет о базовых службах на уровне Ethernet, которые только–только начинают обсуждать в органах стандартизации. Кстати, в беспроводных сетях эта проблема стоит еще более остро.
Даже на уровне маршрутизатора не всегда можно предполагать отсутствие вектора атаки. Популярные маршрутизаторы работают под управлением больших и сложных программ на языке С, которые могут быть подвержены ошибкам переполнения буфера и иным, что позволит противнику исполнить произвольный код. Пока производители маршрутизаторов не перейдут на технологии, которые сведут к минимуму или вообще исключат риск такой катастрофы, опасность будет существовать. И ведь находили же в прошлом ошибки переполнения буфера в маршрутизаторах. См., например, бюллетени CVE–2002–0813, CVE–2003–0100 и CAN–2003–0647 в базе данных CVE .
Сетевые атаки весьма разнообразны.
□ Подслушивание. Противник прослушивает сеанс связи и извлекает всю ценную информацию, например имена и пароли пользователей. Даже если пароль передается не в читаемом виде (а часто так и есть), почти всегда возможно путем перебора по словарю раскрыть его. А иногда и это не нужно, поскольку пароль не шифруется, а лишь маскируется.
□ Воспроизведение. Противник извлекает уже имеющиеся в потоке данные и воспроизводит их. Это может быть весь поток или какая–то его часть. Например, можно воспроизвести данные аутентификации, чтобы зарегистрироваться под чужим именем, а затем начать сеанс от чужого имени.