Серия, охватывающая 10 основных уязвимостей OWASP с точки зрения Java-программиста.
Что такое OWASP?
Open Web Application Security Project — это некоммерческая организация, основанная в США для анализа, документирования и обмена информацией, касающейся наиболее распространенных и серьезных уязвимостей в современных веб-приложениях. Их цель — обучить нас — если мы сами этого не сделаем — слабым сторонам безопасности, которые мы неосознанно используем в наших приложениях, как их идентифицировать и как их предотвратить. Проще говоря, они проводят кучу ночей в сияющих доспехах, помогая нам создавать более безопасные веб-приложения.
Их миссия, как они заявляют это:
Проект Open Web Application Security Project (OWASP) — это некоммерческая всемирная благотворительная организация 501c3, ориентированная на повышение безопасности прикладного программного обеспечения. Наша миссия — сделать безопасность приложений
видимой, чтобы
люди и организации могли принимать обоснованные решения об истинных рисках безопасности приложений. Каждый может свободно участвовать в OWASP, и
все наши материалы доступны по бесплатной и открытой лицензии на программное обеспечение.
Каждый год OWASP публикует список 10 самых уязвимых мест в Интернете, которые можно найти по всему миру, чтобы обучать и укреплять приложения, доступные для всех нас.
Наша задача как программистов — прислушиваться к советам и понимать, что мы делаем неправильно, и улучшать их.
Топ 10 — инъекция
OWASP определяет недостатки впрыска как:
Недостатки внедрения, такие как внедрение SQL, OS и LDAP, возникают, когда ненадежные данные отправляются интерпретатору как часть команды или запроса. Враждебные данные злоумышленника могут заставить интерпретатора выполнить непреднамеренные команды или получить доступ к несанкционированным данным.
Я лично чувствую (и у меня нет абсолютно никаких данных, подтверждающих эту догадку), что инъекция SQL является наиболее распространенной уязвимостью сегодня; и я бы рискнул предположить, что приложения PHP — главный виновник, потому что, хотя его легко понять, PHP требует тонкого мастерства, которое немногие приобретают, прежде чем выпустить свой код в Интернет.
В Java уязвимости не менее маловероятны, и вы рискуете многим, если предположите, что выбранный вами язык может определять вашу безопасность. Языковые функции и общие соглашения могут лишь частично защитить ваш текст; В конце концов, разработчик должен не только знать, что требуется для создания защищенного приложения, но и иметь возможность доказать, что он создал, не уязвимо.
Так как же выглядит уязвимость для инъекций? Давайте создадим нам сценарий: сайт, который принимает параметр GET идентификатора страницы и просматривает содержимое страницы в базе данных. Это веб-приложение имеет сервлет страницы, который обрабатывает контент, загружаемый из базы данных. Код просто читает параметр запроса и передает его в пользовательский DAO, который создает оператор SQL на лету, используя конкатенацию строк или что-то подобное . Этот процесс построения на лету и не использования подготовленных операторов — это то, что позволяет злоумышленнику передать тщательно сконструированный SQL-оператор, который избегает того, что вы делаете, и затем запускает «отбрасывание базы данных»; или похожие.
Вот типичный пример:
String pageId = request.getParameter(“pageID”);
String SQL = “SELECT * FROM pages WHERE page_id = “ + pageId;
Вторая строка выше безопасна и надежна, если вы когда-либо передаете целые числа на страницу в качестве ее параметра GET. Если бы любопытный разработчик увидел ваш параметр pageID и подумал: «Интересно, смогу ли я передать SQL-код туда», вы бы без проблем пошли в гору; размещение »; удалить базу данных; так как pageID будет работать непосредственно в вашей базе данных, и вы не узнаете, пока не станет слишком поздно.
Недостатки инъекций не ограничиваются базами данных. Страница может быть небезопасной так же легко, если вы будете слепо записывать ввод прямо на страницу без проверки или дезинфекции. Внедрение страницы так же просто, как:
<%=request.getParameter(“firstName”)%>
Теперь все, что нужно сделать злоумышленнику, — это распространить URL-адрес вашего сайта с тщательно созданным HTML или Javascript для этого параметра, и он сможет собрать любые необходимые сведения и все это под знаменем вашей организации.
Еще более глубокий пример — сохранение входных данных в вашей модели и последующее отображение их — например, на странице подтверждения или сводки — без прохождения простых процедур проверки: удаление недопустимых символов, экранирование XML и т. Д. (Тег c: out имеет escapeXml по умолчанию установлено значение true, поэтому используйте JSTL или EL!).
Точно так же, если вашему приложению нужно записать другой файл на клиент, а ваш серверный ресурс принимает параметр без проверки и обеспечения безопасности ввода, вы оставляете себя открытым для атаки. Вот несколько рекомендаций по предотвращению внедрения уязвимостей в ваш код:
-
Никогда, ни при каких обстоятельствах не создавайте операторы SQL на лету
-
Никогда, никогда не доверяй своему вкладу. Всегда «дезинфицировать», удаляя нестандартные символы; например, поле имени не должно содержать точку с запятой
-
Если вы говорите с базой данных, используйте подготовленные операторы, которые принимают параметризованный ввод (объявив значения, которые должны быть переданы как «?», А затем установив их с помощью метода мутатора).
-
Использование пользователей только для чтения для доступа к ОС или базе данных; в последнем случае убедитесь, что вы разрешаете только обновление и вставку, и, конечно, НЕ отбрасываете или предоставляете!
-
Просмотрите код вашей команды и проверьте ваш
Как вы можете видеть, уязвимости инъекций довольно легко обнаружить, но их так же легко предотвратить . Есть ли у вас какие-либо страшные истории, которые подчеркивают важность этого сценария? При чтении кода возникла проблема в вашей организации?
В следующий раз мы рассмотрим # 2 в первой десятке OWASP: межсайтовый скриптинг.