Статья написана Джоном Мюллером
Вы хотите проверить API, чтобы убедиться в его безопасности, но как, по вашему мнению, злоумышленник собирается взломать ваш API и, возможно, попасть на ваш сайт? Выполнение правильных видов тестирования безопасности API имеет важное значение.
Каждый день кажется, что в торговой прессе появляется другая проблема безопасности. В некоторых случаях новости появляются в национальной прессе на весь мир, что разрушает репутацию организации таким образом, что это может привести к провалу и банкротству. Взлом, который раскрывает информацию пользователя, особенно конфиденциальную информацию, такую как номера кредитных карт, — это то, чего каждая организация хочет избежать. Единственный способ избежать появления в новостях самым негативным способом — это убедиться, что плохие парни не могут получить доступ к вашему сайту через одну из самых пористых границ: API, используемый для разработки приложений. Здесь я опишу некоторые распространенные формы тестирования безопасности API, чтобы вы могли создать собственный набор тестов для своего собственного API, который поможет держать плохих парней в страхе.
Понимание основных проблем тестирования безопасности
Тестирование вашего API на потенциальные проблемы безопасности абсолютно необходимо. Однако простого выполнения тестов недостаточно — вы должны выполнять тесты, которые на самом деле имитируют виды атак, которые может попробовать посторонний. Это означает, что вы должны думать как плохой парень, чтобы выяснить, какие атаки могут предпринять посторонние.
Вам не нужно идти в одиночку, однако. Есть способы думать, как плохой парень, который не требует гораздо большего, чем чтение отраслевой прессы, чтобы определить, как другие организации проиграли свою битву, чтобы остаться свободными от хищников, и избегая распространенных ошибок, на которые плохие парни обращаются чаще всего.
Конечно, важно знать, на какие проблемы безопасности нужно ориентироваться и тестировать в рамках своего API. Одним из наиболее важных источников информации является База данных инцидентов Web Hacking (WHID) , в которой перечислены следующие главные претенденты на взлом.
- SQL-инъекция (18,87%)
- Межсайтовый скриптинг (12,58%)
- Отказ в обслуживании (8,06%)
- Предсказуемое расположение ресурсов (4,35%)
- Непреднамеренное раскрытие информации (4,35%)
- Грубая сила (4,03%)
Использование WHID позволяет проверить особенности большинства инцидентов, щелкнув одну из записей в разделе «Быстрые загрузки» на странице. Использование полных данных WHID в Google Fusion Tables — это, пожалуй, самый быстрый способ. Статистика также говорит о том, что держать в страхе плохого парня является обязанностью каждого в организации, но, как разработчик, вы можете выбить двух главных соперников, просто создав безопасные приложения и полностью протестировав их.
Важно помнить, что создание защищенного программного обеспечения, его полное тестирование и даже проведение имитационных атак на него только отодвинет в сторону среднего плохого парня. Если кто-то действительно настроен нарушить вашу безопасность, он это сделает. Таким образом, часть того, что вам нужно убрать из этого поста, заключается в том, что потребность в тестировании постоянна, так же как и необходимость бдительности. Поиск взлома позволит вам исправить проблемы до того, как они станут главной страницей.
Противодействие атакам SQL-инъекций
Атака SQL-инъекций существует уже давно. Причина, по которой хакеры продолжают использовать его, заключается в том, что техника продолжает работать. Кроме того, методика чрезвычайно проста, поэтому любой может использовать ее с легкостью. Допустим, у вас есть следующие утверждения как часть вашего приложения:
txtUserID = getRequestString(“UserId”); SQLCmd = “SELECT * FROM Users WHERE UserId” + txtUserID;
Команда SQLCmd выглядит достаточно безобидной. Однако что, если пользователь вводит значение, которое всегда будет истинным, например, 100 или 1 = 1? Команда теперь будет возвращать каждую запись в базе данных пользователей. Если база данных содержит пароли пользователей, хакер теперь получил доступ ко всем учетным записям в вашей системе. На самом деле, есть много способов, которыми хакер может использовать, чтобы внедрить все виды ужасных вещей. Например, хакер может просто решить попросить менеджера базы данных удалить базу данных пользователей, освобождая вас от бремени ее обслуживания.
К счастью, есть относительно простые способы преодолеть такую атаку. Все, что вам действительно нужно сделать, это проверить входящие данные. Если вы ожидаете простого числа, убедитесь, что пользователь ввел простое число, например 100. Не допускайте ничего, кроме числового ввода. Вы также можете ограничить длину ввода, типы символов, используемые для ввода, и так далее. Например, если поле должно содержать имя, оно не должно содержать точку с запятой. В предыдущем примере можно было бы удалить базу данных, если бы пользователь набрал 100; DROP TABLE Пользователи. Обратите внимание, что пользователю пришлось бы использовать точку с запятой, чтобы этот подход работал.
Другим распространенным способом избежать проблем является использование параметров SQL. В этом случае вы заставляете менеджер базы данных проверить, что каждая запись имеет правильный тип для определенного поля. Кроме того, этот метод гарантирует, что текст не будет выполнен как код. Вот пример того же кода с использованием параметров SQL:
txtUserID = getRequestString(“UserId”); SQLCmd = “SELECT * FROM Users WHERE UserId @0″; db.Execute(SQLCmd, txtUserId);
Параметр SQL — это число, которому предшествует знак @ (at). В этом случае вы видите, что есть один параметр, @ 0. Когда ваше приложение вызывает db.Execute (), параметр txtUserID передается вместе с командой менеджеру базы данных.
При создании теста вы должны включить все виды ошибочных входных данных, чтобы гарантировать, что любой метод (или комбинация методов), который вы используете, действительно работает. Например, тестер может не подумать об использовании знаков препинания в качестве входных данных, но пользователь может. Попробуйте ввести управляющие символы, нажав ALT + <Трехзначный номер>. Например, ALT + 000 введет нулевой символ, что может вызвать серьезные проблемы. Не думайте, что менеджер базы данных или другая сущность действительно остановит атаку — будьте активны в своем тестировании.
Работа с межсайтовым скриптингом
Атака межсайтового скриптинга — это атака, при которой ваша страница заражена клиентским скриптом, который затем загружается жертве. Сценарий выполняется в системе жертвы и делает что-то плохое, например, заставляет жертву отказаться от ценной информации или заставить систему жертвы действовать как зомби. Последовательность событий выглядит так:
- Плохой парень добавляет клиентский скрипт на вашу страницу.
- Невинная жертва заходит на вашу страницу и скачивает сценарий вместе с остальной частью страницы.
- Сценарий выполняется на компьютере жертвы.
- Жертва заканчивает тем, что теряла данные или наносила ущерб чьей-либо системе на имя плохого парня.
Конечно, лучший способ избежать всей этой проблемы — не допустить наступления первого шага атаки. Проблема в том, что контент сегодня представляет собой объединение данных со всего Интернета. Вы, вероятно, используете код из разных мест. Таким образом, не всегда легко увидеть взаимодействия, которые могут происходить на вашей странице, потому что ваша страница динамична.
Например, многие страницы содержат раздел комментариев. Хакер может включить ссылку на скрипт как часть комментария на вашей странице. Каждый пользователь, который загружает и читает этот комментарий, также загружает и выполняет сценарий. В этом случае вы можете решить проблему с помощью правильной модерации комментариев.
Однако что происходит, когда ваша страница принимает входные аргументы, которые могут включать сценарий на стороне клиента? В этом случае вам нужно следовать тем же методам тестирования, что и при атаках с использованием SQL-инъекций, но в вашем коде JavaScript, а не в менеджере баз данных. Как и при тестировании SQL-инъекций, вам необходимо убедиться, что входные данные имеют правильный тип, правильную длину и находятся в правильном диапазоне. Кроме того, вам необходимо проверить наличие явных признаков взлома, таких как ошибочные символы, такие как точки с запятой.
Нижняя линия
В этой статье даже не рассматривалось множество уязвимостей, с которыми вы могли столкнуться, таких как граничные значения, размытие данных и бомбы XML. Картина, нарисованная в этой статье, на первый взгляд может показаться унылой, но вы можете преодолеть множество потенциальных дыр в вашем API, думая как плохой парень, а затем предпринимая надлежащие шаги для преодоления уязвимостей с помощью комбинации тестирования, управления сайтом, и обучение пользователей. Кроме того, вы можете положиться на функции, предоставляемые сторонними продуктами, такими как SoapUI Pro , для автоматического тестирования на наличие некоторых уязвимостей (снижение рабочей нагрузки при сохранении безопасности вашего сайта).