Второе место в серии из 10 основных уязвимостей OWASP с точки зрения Java-программиста. На этой неделе — XSS.
Что такое OWASP?
Open Web Application Security Project — это некоммерческая организация, основанная в США для анализа, документирования и обмена информацией, касающейся наиболее распространенных и серьезных уязвимостей в современных веб-приложениях. Их цель — обучить нас — если мы сами этого не сделаем — слабым сторонам безопасности, которые мы неосознанно используем в наших приложениях, как их идентифицировать и как их предотвратить. Проще говоря, они проводят кучу ночей в сияющих доспехах, помогая нам создавать более безопасные веб-приложения.
Их миссия, как они заявляют это:
Проект Open Web Application Security Project (OWASP) — это некоммерческая всемирная благотворительная организация 501c3, ориентированная на повышение безопасности прикладного программного обеспечения. Наша миссия — сделать безопасность приложений
видимой, чтобы
люди и организации могли принимать обоснованные решения об истинных рисках безопасности приложений. Каждый может свободно участвовать в OWASP, и все наши материалы доступны по бесплатной и открытой лицензии на программное обеспечение.
Каждый год OWASP публикует список 10 самых уязвимых мест в Интернете, которые можно найти по всему миру, чтобы обучать и укреплять приложения, доступные для всех нас.
Наша задача как программистов — прислушиваться к советам и понимать, что мы делаем неправильно, и улучшать их.
Топ 10 — XSS
Межсайтовый скриптинг — или XSS — является уязвимостью, которая широко распространена. Согласно OWASP, сегодня это самая распространенная система безопасности на веб-сайтах, и это заняло второе место в их списке.
Как определено OWASP, XSS является:
Недостатки XSS возникают, когда приложение включает предоставленные пользователем данные на странице, отправленной в браузер, без надлежащей проверки или экранирования этого содержимого. Существует три известных типа недостатков XSS: 1) сохраненные , 2) отраженные и 3) основанные на DOM XSS
Lowdown
Атаки XSS происходят обычно потому, что некоторым входным данным — невинным или иным — доверяют вслепую и передают приложение без беспокойства. Золотое правило или недоверчивый ввод нарушается, и злоумышленник может нанести ущерб.
Как определяет OWASP, существует три типа уязвимостей XSS: хранимые, отраженные и DOM.
Хранимые атаки
Я бы сказал, что это худшие из трех, потому что атака постоянна. Допустим, у вас есть форма с содержимым страницы, которая берет из других элементов заголовок страницы . Они хранятся в базе данных напрямую, без проверки, и при успешном хранении информация возвращается пользователю через страницу «предварительного просмотра» . В вашем JSP вы делаете следующее (предположим, что pageBean — это модель вашей формы и представляет значения, которые были сохранены в вашей БД):
<%=postBean.getPageTitle()%>
Этот простой, невинный сценарий закладывает основу для простого хранимого XSS. Пользователь отправляет форму, информация сохраняется, и вы представляете ее обратно пользователю. Что если пользователь введет «<script language = ‘Javascript’> alert (« о дорогой »); </ script>» в одно из этих полей? Когда вы представляете его обратно пользователю, на странице будет отображаться предупреждение Javascript; Безусловно, в этом примере это безвредно, но оно имеет более зловещую перспективу, и вы будете получать сценарии со всех видов вредоносных сайтов — пользователь беспомощен, так как атака имеет все виды контроля под флагом вашей организации. Если бы это было частью CMS, которая была доступна за пределами вашей организации, пользователь мог бы разослать ссылки на этот пост любому количеству людей и нанести ущерб, собирая личные данные (пользователь думает: «о, это такой-то сайт, я можно им доверять! ») и так далее.
Чтобы устранить вышеуказанную проблему, вам нужно всего лишь использовать тег JSTL c: out для вывода заголовка компонента страницы. По умолчанию тег core out экранирует XML, так что вам не о чем беспокоиться.
отраженный
Подобно хранимым атакам, отраженные атаки могут происходить из-за плохой обработки ввода или по специально созданным URL-адресам (что снова является формой плохой обработки ввода). Например, предоставляя окно поиска, вы по праву используете запрос GET для этого. При отображении результатов вы можете суммировать вводные данные — «вы искали X» — и затем представлять результаты. Если злоумышленник передал сюда какой-нибудь Javascript, и вы не смогли безопасно избежать ввода при подведении итогов, у вас будет уязвимость в ваших руках. В таком случае атака должна распространять электронную почту или другое сообщение с тщательно созданным URL-адресом (содержащим некоторый Javascript, который извлекает что-то в другом месте), а ваши пользователи и их данные находятся под угрозой.
DOM на основе XSS
Объектная модель документа — атаки на основе DOM немного сложнее, чем сохраняются или отражаются. Это происходит, например, когда клиентский код создается с использованием доверенных значений. Если код написан неверно, код действует или структурируется с учетом определенных ожиданий ввода, и этот ввод можно использовать для внедрения стороннего кода в DOM. См. Страницу OWASP на DOM XSS для более полного ознакомления.
Многое из того, что вы видите в OWASP, можно избежать простым пониманием вашего вклада и никогда не доверять ему! Не пишите слепо данные обратно своим пользователям и, конечно же, не храните их без их кодирования или дезинфекции перед использованием в динамическом коде (и даже в этом случае санитарный код может быть плохо реализован и давать ложное чувство безопасности.
Я надеюсь, что это просветило вас или, по крайней мере, освежило вашу память о еще одном критическом аспекте развития. На следующей неделе я расскажу об аутентификации!