Список изменений: проект OWASP Top 10

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

В 2001 году на сцену вышла новая организация. Его цель состояла в том, чтобы бороться с проблемами безопасности, затрагивающими веб-сайты и приложения. Он получил соответствующее название Open Web Application Security Project (OWASP). В настоящее время он публикует ресурсы, организует конференции и предлагает стандарты веб-безопасности и безопасности приложений. Стандартом де-факто для безопасности веб-приложений является проект OWASP Top Ten. В нем перечислены десять наиболее распространенных угроз безопасности. Факторами, влияющими на принятие решения о том, что будет добавлено, были обширный объем данных и отзывы сообщества. В конце 2017 года произошло обновление проекта. Несколько новых проблем, критичных для многих современных веб-приложений, получили свое место, а некоторые выпали из списка.

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

Проблемы, удаленные из списка OWASP Top 10

До обновления 2017 года список за 2013 год был самым последним. Учитывая изменения в способах создания и использования веб-приложений, имело смысл провести тщательную ревизию. Микросервисы берут свой кусок пирога, а новые классные и блестящие фреймворки заменяют боевое снаряжение ванильного кода. Эти факты означают, что некоторые из перечисленных угроз были устранены, а их место заняли новые.

В этой статье мы обязательно освежим в памяти давно забытые проблемы, а также представим новых злых волков. Изучение истории — единственный верный способ не повторять тех же ошибок.

Подделка межсайтовых запросов

Подделка межсайтовых запросов (CSRF) — один из «проигравших» в последней итерации проекта. Он ушел, потому что многие современные веб-фреймворки включают механизмы защиты CSRF. Таким образом, вероятность подвергания ваших приложений угрозе быстро снижается.

Независимо от выхода CSRF из списка, все равно полезно освежить память. Давайте удостоверимся, что он не вернется сильнее, чем когда-либо.

По сути, CSRF — это эксплойт, который чувствует дымовую шашку. Злоумышленник обманом заставляет ничего не подозревающего пользователя выполнить нежелательный запрос или действие в веб-приложении. Проще говоря, злоумышленник заставляет свою жертву отправить запрос стороннему приложению, а жертва не знает о том, что запрос когда-либо был отправлен. Запрос может быть запросом HTTP GET для извлечения ресурса или, что еще хуже, запросом HTTP POST, который изменяет ресурс, находящийся под контролем жертвы. Во время приступа жертва думает, что все в порядке, чаще всего даже не замечая, что что-то происходит на заднем плане. После того, как воздух проясняется, ущерб нанесен или чего-то не хватает, и никто не знает, что произошло.

Успешная предыдущая аутентификация пользователя в целевом приложении — это то, что делает ловушку эффективной. Пользователь в какой-то момент перед атакой вошел в приложение. Приложение отправляло жертве файл cookie, чтобы запомнить их. Как только веб-браузер отправляет вредоносный запрос, файл cookie автоматически отправляется вместе с любой потенциальной полезной нагрузкой, и приложение не возражает против обслуживания запроса пользователю, которого оно уже знает.

Один из самых известных примеров — это обман пользователя, чтобы он перевел деньги со своего счета на тот, который контролируется злоумышленником. Пользователь входит в систему электронного банкинга, чтобы проверить баланс своего счета. После этого они посещают онлайн-форум, чтобы проверить отзывы о новом мобильном телефоне. Злоумышленник, ловящий рыбу динамитом, публикует обзор, включающий изображение с, казалось бы, неработающей гиперссылкой. Вместо реальной гиперссылки злоумышленник использует гиперссылку, которую система электронного банкинга внутренне использует для перевода денег со счета A на счет B: https://payments.dummybank.com?receiver=attacker&amount=100 . Банковская система делает аутентифицированного пользователя отправителем, а значение параметра «получатель» — получателем средств. Разумеется, в качестве получателя злоумышленник указывает свою оффшорную учетную запись.

Поскольку браузер автоматически загружает изображения при отображении страницы, запрос выполняется в фоновом режиме. Если платежная система банка реализует денежные переводы с использованием HTTP GET-запроса, ничто не мешает случиться катастрофе. Обратите внимание, что пример простой и, скорее всего, передача не обрабатывается через HTTP GET. Тем не менее, злоумышленник может с небольшими трудностями изменить атрибут «действие» в HTML-форме сообщения на форуме. Затем браузер отправляет запрос в платежную систему банка, а не в серверную часть форума.

Кража денег — лишь один из многих примеров. Изменение адресов электронной почты пользователей или совершение непреднамеренных покупок также попадают в эту категорию. Как это часто бывает, социальная инженерия и некоторые технические знания являются эффективным средством защиты от ошибок в программной инженерии.

При проектировании систем необходимо учитывать следующее:

• Не используйте запросы HTTP GET для инкапсуляции действий, изменяющих ресурс. Вы должны использовать эти запросы только для получения информации. Помните, эмпирическое правило заключается в том, чтобы сделать запросы GET идемпотентными.
• Do , при внутренней передаче данных с использованием запросов HTTP POST, как правило, отправляйте данные в формате JSON, XML или в каком-либо другом формате, отличном от кодирования параметров в виде строки запроса. Использование нетривиального формата данных снижает опасность того, что кто-то создаст поддельную HTML-форму, которая отправит данные в вашу службу.
• Обязательно создайте и включите в свои HTML-формы уникальный и непредсказуемый токен. Эти токены также должны быть уникальными для каждого запроса. Проверка наличия и правильности таких токенов снизит риски возникновения угроз. Чтобы узнать токен и использовать его в своих поддельных запросах, злоумышленникам потребуется получить доступ к вашей системе и взять токен прямо оттуда. Поскольку токены являются одноразовыми, повторно использовать их во вредоносном коде нельзя.

Эта уязвимость имеет еще больший эффект в сочетании с межсайтовым скриптингом (XSS). Если злоумышленник может внедрить вредоносный код в любимый веб-сайт или приложение, масштаб атаки становится гораздо более значительным и опасным. Что еще более важно, злоумышленники могут обойти некоторые механизмы защиты от CSRF, если возможны атаки XSS.

Имейте в виду, что CSRF не исчез, просто он не так распространен, как раньше.

Непроверенные перенаправления и перенаправления

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

Две основные причины, по которым непроверенные перенаправления и перенаправления могут считаться опасными, — это фишинг и захват учетных данных. Злоумышленник может изменить целевое местоположение перенаправления/переадресации и отправить пользователя во вредоносное приложение, почти неотличимое от исходного. Ничего не подозревающий пользователь раскрывает свои учетные данные и конфиденциальную информацию злоумышленнику. Прежде чем они поймут, что произошло, будет уже слишком поздно.

Например, веб-приложения очень часто реализуют вход с поддержкой перенаправления на последнюю посещенную страницу. Чтобы это было легко сделать, атрибут действия HTML-формы может выглядеть примерно так: http://myapp.example.com/signin?url=http://myapp.example.com/puppies . Вы большой поклонник щенков, поэтому имело смысл установить расширение для браузера, которое заменяет значки веб-сайтов миниатюрами ваших любимых щенков. К сожалению, это мир собачьих поеданий. Автор расширения для браузера решил нажиться на вашей безоговорочной любви и внедрить дополнительную «фичу». Каждый раз, когда вы посещаете свой любимый фан-сайт для щенков, он заменяет параметр «url» в атрибуте действия формы ссылкой на их собственный сайт. Поскольку сайт выглядит точно так же, когда вы предоставляете данные своей кредитной карты для покупки игральных карт для щенков, вы на самом деле финансируете злоумышленника, а не свое хобби.

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

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

• Проверьте исходящий URL-адрес, убедившись, что он указывает на домен, которым вы управляете.
• Вместо использования явных адресов кодируйте их на внешнем интерфейсе, а затем декодируйте и проверяйте на внутреннем.
• Подготовьте белый список доверенных URL-адресов. Разрешает переадресацию и перенаправление только в места из белого списка. Предпочтите этот подход ведению черного списка. Черные списки обычно заполняются новыми элементами только тогда, когда происходит что-то плохое. Белые списки более строгие.
• Используйте подход, используемый LinkedIn и некоторыми другими приложениями: предоставьте своим пользователям страницу с просьбой подтвердить перенаправление/переадресацию, давая понять, что они покидают ваше приложение.

Объединенные задачи

Большинство проблем в списке можно отнести к дефектам реализации либо из-за недостатка знаний, либо из-за недостаточно глубокого изучения потенциальных угроз. Обе эти причины можно отнести к отсутствию опыта, и решение для их рассмотрения в будущем простое — просто обязательно узнайте больше и будьте более тщательными. Особенно сложный вариант основан на сочетании опасной (но очень человеческой) черты делать слишком много предположений в сочетании со сложностью разработки и обслуживания сложных компьютерных систем. Уязвимость, подходящая под эту категорию, — «нарушение контроля доступа».

Сломанный контроль доступа

Уязвимость вызвана неадекватной или полным отсутствием авторизации и контроля доступа к определенным частям приложения. В предыдущих итерациях проекта OWASP Top Ten было две проблемы: небезопасные прямые ссылки на объекты и отсутствующий контроль доступа на функциональном уровне. Теперь они объединены в один из-за их сходства.

Прямые ссылки на объекты

Прямые ссылки на объекты часто используются в URL-адресах для идентификации ресурсов, с которыми выполняются операции. Например, когда пользователь входит в систему, он может посетить свой профиль, щелкнув ссылку, содержащую идентификатор его профиля. Если тот же идентификатор хранится в базе данных и используется для получения информации профиля, а приложение предполагает, что люди могут попасть на страницу профиля только через страницу входа, изменение идентификатора профиля в URL-адресе раскрывает информацию профиля другого пользователя.

Приложение, которое устанавливает URL-адрес формы профиля удаления http://myapp.example.com/users/15/delete , дает понять, что в приложении есть как минимум 14 других пользователей. Выяснение того, как добраться до формы удаления других пользователей, в этом случае не является сложной задачей.

Решение этой проблемы состоит в том, чтобы выполнять проверки авторизации для каждого ресурса, не предполагая, что для доступа к некоторым частям приложения можно использовать только определенные пути. Кроме того, удаление прямых ссылок и использование косвенных — это еще один шаг вперед, потому что злоумышленникам будет сложно понять, как создается ссылка.

Во время разработки в качестве меры предосторожности запишите простую диаграмму конечного автомата. Пусть состояния представляют разные страницы в вашем приложении и переходы, которые могут выполнять пользователи. Это упрощает перечисление всех переходов и страниц, требующих особого внимания.

Отсутствует контроль доступа на функциональном уровне

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

Заимствуя пример с прямыми ссылками на объекты, если приложение предполагает, что пользователь, посещающий форму удаления, является суперпользователем только потому, что суперпользователи могут видеть ссылку на форму удаления без дальнейшей авторизации, открывается огромная брешь в безопасности. Расчет на доступность какого-либо элемента пользовательского интерфейса не является надлежащим контролем доступа.

Проблема решается путем обязательного выполнения проверок во всех слоях вашего приложения. Внешний интерфейс может быть не единственным способом доступа злоумышленников к вашему уровню домена. Кроме того, не полагайтесь на информацию, полученную от пользователей об их уровнях доступа. Выполняйте надлежащий контроль сеанса и всегда перепроверяйте полученные данные. То, что в теле запроса указано, что пользователь является администратором, на самом деле не означает, что это так.

Сломанный контроль доступа теперь объединяет все проблемы, связанные с недостаточным контролем доступа, будь то на уровне приложений или на уровне системы, например неправильная конфигурация файловой системы.

Новые проблемы в списке 10 самых популярных OWASP

Появление новых интерфейсных фреймворков и внедрение новых методов разработки программного обеспечения сместили проблемы безопасности на совершенно новые темы. Новым технологиям также удалось решить некоторые распространенные проблемы, с которыми мы раньше сталкивались вручную. Поэтому стало выгодно пересмотреть список и скорректировать его в соответствии с современными тенденциями.

Внешние объекты XML

Стандарт XML предлагает малоизвестную идею, называемую внешней сущностью, которая является частью определения типа данных документа (DTD). Это позволяет авторам документов указывать ссылки на внешние объекты, на которые затем можно ссылаться и которые можно включить в основной документ. Очень простой пример:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Во время парсинга ссылка &bar; заменяется содержимым из определенного объекта, что дает <foo>baz</foo> .

Если бы приложение принимало внешние входные данные и включало их без каких-либо проверок непосредственно в определение XML-документа, стал бы возможен широкий спектр утечек данных и атак.

Волшебство заключается в том, что объект не обязательно должен быть простой строкой — это может быть ссылка на файл в файловой системе. Синтаксический анализатор XML с удовольствием возьмет содержимое указанного файла и включит его в сгенерированный ответ, потенциально раскрывая конфиденциальную системную информацию. Как показано OWASP, было бы очень легко получить информацию о пользователях системы, определив сущность как

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Особенно неприятной «особенностью» этой уязвимости является возможность легкого выполнения атаки типа «отказ в обслуживании». Один из простых способов сделать это — перечислить содержимое бесконечного файла, такого как /dev/random . Другой — создать последовательность сущностей, каждая из которых многократно ссылается на предыдущую. Это превращает конечную ссылку в корень потенциально очень широкого и глубокого дерева, анализ которого может исчерпать системную память. Эта атака даже известна как Billion Laughs. Как показано в Википедии, определен ряд фиктивных сущностей, что дает злоумышленнику возможность включить в окончательный документ один миллиард лолов.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

Предотвратить эксплойты внешних сущностей XML можно с помощью менее сложного формата данных. JSON является хорошей заменой, если также принять некоторые меры предосторожности из-за возможных атак на него. Обновление XML-библиотек является обязательным в сочетании с отключением внешней обработки сущностей и DTD. Как всегда, проверяйте и очищайте данные, поступающие из ненадежных источников, перед их использованием или включением в свои документы.

Небезопасная десериализация

При написании кода разработчики имеют возможность контролировать разрабатываемые ими системы с помощью написанного ими кода. Насколько здорово было бы контролировать поведение сторонних систем, написав лишь немного кода или даже не написав его вовсе? Благодаря тому, что люди не идеальны и что у библиотек есть недостатки, это определенно возможно.

Состояние и конфигурация приложения часто сериализуются и сохраняются. Иногда браузеры служат механизмами хранения, если сериализованные данные тесно связаны с текущим пользователем. Приложение, пытающееся быть умным и экономить время обработки, может использовать файл cookie, чтобы отметить, что пользователь вошел в систему. Поскольку файл cookie может быть создан только после успешного входа в систему, имеет смысл хранить имя пользователя в файле cookie. Затем пользователь аутентифицируется и авторизуется на основе существования и содержимого файла cookie. Если бы у людей не было злых намерений, ничего не могло бы пойти не так. Честно говоря, им тоже не должно быть любопытно.

Если любопытный пользователь обнаружил на своем компьютере файл cookie, он мог увидеть что-то вроде этого:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

Совершенно правильный словарь Python, сериализованный в JSON, в этом нет ничего особенного. Вечно любопытный пользователь может изменить дату истечения срока действия, чтобы приложение не принудительно вышло из системы. Еще более любопытный пользователь может попытаться изменить имя пользователя на "jane.doe" . Если бы это имя пользователя существовало, оно открыло бы совершенно новый мир для ничего не подозревающего пользователя, который теперь имеет доступ к личным данным.

Простой пример сериализации данных в JSON и сохранения прозрачности — далеко не самое худшее, что может с вами случиться. Если злоумышленнику удастся изменить некоторые сериализованные данные, он может изменить их таким образом, что заставит вашу систему выполнять произвольный код.

Допустим, вы создаете REST API, который позволяет людям писать свои собственные модели машинного обучения на Python и загружать их в ваш сервис. Сервис оценит загруженные модели и обучит их с использованием ваших наборов данных. Это позволяет людям использовать ваши вычислительные ресурсы и огромное количество доступных наборов данных для быстрого и простого построения моделей.

Служба не хранит код в текстовом формате. Пользователи выбирают свой код, шифруют его с помощью закрытого ключа и отправляют в API для обучения. Когда сервису нужно запустить модель, он расшифровывает код, расшифровывает его и запускает. Сложность заключается в том, что протокол pickle небезопасен. Код может быть построен таким образом, чтобы во время десериализации можно было выполнить произвольный вредоносный код.

Протокол pickle Python позволяет классам определять метод __reduce__ , который возвращает информацию о том, как десериализовать пользовательский объект. Одно из поддерживаемых возвращаемых значений — это кортеж из двух аргументов: вызываемого объекта и кортежа аргументов, которые должны быть переданы вызываемому объекту. Принимая во внимание, что ваша система обучения модели машинного обучения нацелена на обеспечение максимальной гибкости структуры кода, можно написать следующий код:

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Как только объект необходимо десериализовать (распаковать), вызывается list функций только с одним аргументом. list функций — это конструктор списка в Python, а функция itertools.count создает бесконечный итератор значений, начиная с переданного параметра. Превращение бесконечного итератора в конечный список может иметь катастрофические последствия для производительности и стабильности вашей системы.

Единственное реальное лекарство от этого типа уязвимости — отказаться от десериализации данных, поступающих из внешних источников. В случае, если это невозможно, предлагается использовать контрольную сумму или цифровую подпись, чтобы предотвратить десериализацию данных, которые потенциально были изменены злоумышленником. Кроме того, попробуйте настроить среду песочницы, отделенную от вашей основной системы, чтобы ограничить влияние проблем, которые могут возникнуть.

При использовании внешних библиотек для десериализации данных, например из XML или JSON, старайтесь выбирать те, которые позволяют выполнять проверки типа объекта до того, как будет выполнена фактическая процедура десериализации. Это может привести к обнаружению неожиданных типов объектов, единственной целью которых является нанесение вреда вашей системе.

Как и в случае со всеми другими действиями, выполняемыми вашим приложением, обеспечьте тщательное ведение журналов и мониторинг. Десериализация, происходящая часто или сбой чаще, чем обычно, является сигналом о том, что происходит что-то плохое. Выявляйте проблемы заранее.

Недостаточное ведение журнала и мониторинг

Сколько времени вы тратите на то, чтобы убедиться, что вы регистрируете все предупреждения и ошибки, возникающие в вашем приложении? Сохраняете ли вы только ошибки, происходящие в коде, или также регистрируете ошибки проверки? Что происходит, когда бизнес-правила вашего домена не соблюдаются? Неспособность сохранить все ошибочные и подозрительные действия в вашем приложении представляет собой угрозу безопасности и данных.

Представьте себе следующий сценарий. Ваше приложение содержит страницу входа, как и большинство других приложений. Форма имеет два поля, одно для ввода электронной почты, а другое для пароля. Если пользователь пытается войти и вводит неправильный пароль, он может повторить попытку. К сожалению, количество неправильных попыток не ограничено, поэтому страница авторизации не будет заблокирована после N неудачных попыток. Злоумышленник может воспользоваться этой возможностью и, получив одно правильное электронное письмо, продолжать вводить пароли из радужной таблицы до тех пор, пока одна комбинация, наконец, не сработает. Если ваше приложение достаточно безопасно и вы хэшируете пароли перед вводом их в базу данных, эта конкретная атака не сработает. Однако есть ли у вас механизм выявления вторжений?

То, что эта попытка взломать вашу страницу входа не удалась, не означает, что не удастся сделать и другую. Страница входа, вероятно, не единственный потенциальный бэкдор, который у вас есть. Если бы не что-то еще, кто-то мог бы попытаться использовать нарушенный контроль доступа против вас. Даже идеально созданные приложения должны знать, что кто-то пытается атаковать их, даже если это невозможно. Впрочем, это всегда так.

Чтобы сделать все возможное, чтобы защитить себя от таких атак, выполните следующие действия:

• Регистрируйте все сбои и предупреждения, возникающие в приложении, будь то исключения в коде или ошибки управления доступом, проверки и обработки данных. Вся хранимая информация должна воспроизводиться и сохраняться достаточно долго, чтобы можно было проводить ретроспективную проверку и анализ.
• Важно определить формат и слой сохраняемости. Иметь огромный файл с произвольным текстовым форматом легко; обработка его позже не является. Выберите вариант хранения, который упрощает хранение и чтение данных, а также формат, обеспечивающий простую и быструю (де)сериализацию. Хранение JSON в базе данных с возможностью быстрого доступа упрощает использование. Поддерживайте небольшой размер базы данных, регулярно создавая ее резервные копии.
• Если вы имеете дело с важными и ценными данными, отслеживайте действия, которые можно выполнить для проверки конечного состояния. Реализовать механизм предотвращения подделки данных.
• Пусть фоновые системы анализируют журналы и предупреждают вас, если что-то происходит. Проверки — такие же простые, как тестирование, если пользователь неоднократно пытается получить доступ к защищенной части приложения — помогают. Однако не перегружайте систему фиктивными проверками. Системы мониторинга должны работать как отдельные службы и не должны влиять на производительность основной системы.

При решении проблемы соблюдайте особую осторожность, чтобы не допустить утечки журналов ошибок внешним пользователям. Невыполнение этого требования делает вас уязвимым для раскрытия конфиденциальной информации. Ведение журнала и мониторинг должны помочь вам в решении проблем, а не злоумышленникам в более эффективном выполнении своей работы.

Следующие шаги

Важно знать о потенциальных угрозах и уязвимостях в веб-приложениях. Еще важнее начать идентифицировать их в своих приложениях и применять исправления для их удаления.

Внимание к безопасности приложений является важной частью всех этапов проекта разработки программного обеспечения. Архитекторы программного обеспечения, разработчики и тестировщики должны включать процедуры тестирования программного обеспечения в свои рабочие процессы. Полезно использовать контрольные списки безопасности и автоматические тесты на соответствующих этапах процесса разработки программного обеспечения, чтобы снизить риск безопасности.

Независимо от того, анализируете ли вы существующее приложение или разрабатываете новое, вам следует ознакомиться со Стандартным проектом проверки безопасности приложений (ASVS) OWASP. Цель проекта — разработать стандарт проверки безопасности приложений. Стандарт перечисляет тесты и требования для разработки безопасных веб-приложений. Тестам присвоены уровни от одного до трех, где один означает наименьшую степень опасности, а три означает наибольшую потенциальную угрозу. Классификация позволяет менеджерам приложений решать, какие из угроз более вероятны и важны. Нет необходимости включать каждый тест в каждое приложение.

Как новые, так и существующие проекты веб-приложений, особенно те, которые следуют принципам Agile, выигрывают от структурированного планирования усилий по обеспечению безопасности своих приложений. Планирование тестов OWASP ASVS станет проще, если вы решите использовать OWASP Security Knowledge Framework. Это приложение для управления спринтами, ориентированными на тестирование безопасности, поставляется с набором примеров того, как решать распространенные проблемы безопасности, и простыми в использовании контрольными списками на основе OWASP ASVS.

Если вы только начали изучать безопасность веб-приложений и вам нужна безопасная площадка для песочницы, используйте реализацию веб-приложения от OWASP — WebGoat. Это намеренно небезопасная реализация веб-приложения. Приложение проводит вас через уроки, причем каждый урок посвящен одной угрозе безопасности.

Во время разработки приложения убедитесь, что вы:

• Выявление и определение приоритетов угроз. Определите, какие угрозы реально могут возникнуть и представляют риск для вашего приложения. Приоритизируйте угрозы и решите, какие из них заслуживают наибольшего внимания при разработке и тестировании. Нет особого смысла прилагать много усилий для решения проблемы недостаточного ведения журнала и мониторинга, если вы обслуживаете статический блог.
• Оцените архитектуру и дизайн вашего приложения. Некоторые уязвимости очень сложно устранить на более поздних этапах разработки приложения. Например, если вы собираетесь выполнять сторонний код и не планируете использовать среду песочницы, будет очень сложно защититься от небезопасных атак десериализации и внедрения.
• Обновите процесс разработки программного обеспечения. Тестирование угроз веб-приложений должно быть, насколько это возможно, автоматизированным процессом. Полезно дополнить рабочие процессы CI/CD автоматическими тестами, пытающимися найти дыры в безопасности. Вы даже можете использовать существующую систему модульного тестирования для разработки тестов безопасности и их периодического запуска.
• Учитесь и совершенствуйтесь. Список проблем и уязвимостей не является статичным и определенно не ограничивается десятью-пятнадцатью угрозами. Новые функциональные возможности и идеи открывают двери для новых типов атак. Важно читать о текущих тенденциях в мире безопасности веб-приложений, чтобы оставаться в курсе. Применяйте то, чему вы научились; в противном случае вы зря теряете время.

Заключение

Несмотря на то, что, как следует из названия, проект OWASP Top Ten перечисляет только десять уязвимостей безопасности, существуют тысячи возможных ловушек и бэкдоров, угрожающих вашим приложениям и, что наиболее важно, вашим пользователям и их данным. Будьте начеку и постоянно обновляйте свои знания, потому что изменения и улучшения в технологиях имеют как положительные, так и отрицательные стороны.

О, и, не забывайте, мир не черно-белый. Уязвимости безопасности не приходят сами по себе; они часто переплетаются. Подверженность одному из них часто означает, что за углами прячется куча других, ожидающих, чтобы поднять свои уродливые головы, и иногда, даже если это не ваша вина, как разработчика системной безопасности, вы все равно должны залатать лазейки, чтобы обуздать киберпреступность. Например, см. статью Взломанные номера кредитных карт по-прежнему доступны для Google .