В последнее время все большее количество информации переходит во Всемирную Сеть. Количество Web стартапов с каждым днем все больше, облачные вычисления и SaaS входят в нашу жизнь и жизнь наших компаний семимильными шагами. Именно поэтому тестирование безопасности Web приложений становится важным элементом проекта.
Уязвимости и приёмы тестирования безопасность под катом.
Не будем останавливаться на том, что тестирование безопасности, это вид тестирования, который позволяет нам быть уверенными что персональная и конфиденциальная информация, хранящаяся на наших серверах, таковой и останется. Безопасность включает в себя и тестирование того, что пользователи с разными правами доступа остаются в рамках этих прав. Например, в случае вселенской проницательности и знания пары запросов в SQL пользователь с правами просмотра, вдруг не свергнет администратора с престола или не подменит в программе что-то, пока тот же администратор моргает или варит себе кофе.
Для того чтоб статья была понятна не только опытным хаброюзерам, но и начинающим тестировщикам и программистам, начнем с описания основных терминов которыми любят козырять спецы в области безопасности.
Уязвимости (Vulnerabilities) — это слабые места в приложение, которые «яйцеголовые хакеры» злоумышленники используют для проникновения в программу. Причиной таких уязвимостей может стать недостаточно хорошо написанный код, SQL-, скрипт-, код-инъекции (SQL-, script-, code-injections) или попросту вирусы пролезшие на сервер.
Понятие крос-сайтовое скрипование — это мой вольный перевод понятия XSS (Cross Site Scripting) представляет собой ввод HTML скрипта в пользовательский интерфейс приложения (на стороне клиента), и его выполнение сервером. В результате чего, до некоторых пор секретная информация, будет видна всем пользователям.
Манипуляции со ссылками (URL manipulation) – Web приложения «общаются» с сервером в форме клинт-сервеного обмена данными. Некоторое количество информации передается на сервер и при помощи ссылки (URL), по которой работает клиент. Изменение или добавление информации в URL-е может вести к непредвиденным последствиям… Ниже приведен пример URL, мы можем изменить все что после знака? и передать это все серверу на выполнение.
mysite.com/client/workstation.php?WORKSTATION=client_1&ACTIVITY_ID=CREATE_USER
SQL инъекции (SQL injection) – это проникновение и выполнение вредоносных действий путем выполнения SQL запросов введенных в поля пользовательского интерфейса приложения. В дальнейшем, если не существует никаких ограничений, сервер выполнит запрос и будет взломан. Примером SQL инъекции может быть следующий запрос введенный в поле User ID
SELECT * FROM Users WHERE User_Name = ‘Ivan’ AND Password = ‘Pupkin’
Отдельно стоит спуфинг (Spoofing) о нем уже много говорилось, вкратце это создание клона сайта или e-mail сервера с последующим его использованием для нанесения вреда владельцу и пользователям приложения или компании.
Выяснив основные внешние угрозы для нашего приложения давайте остановимся на приемах тестирования, которые позволят нам предупредить доступ к нашему приложению злоумышленников.
В первую очередь требования к тестировщикам, тестирующим безопасность, выше, чем к обычным тестировщикам. Они должны понимать основные принципы работы HTTP\HTTPS протоколов, необходимо понимать, как именно то или иное клиентское приложение общается с сервером, хорошо бы знать один-два приема SQL и XSS инъекции. Наличие такого специалиста, даже если это будет аутсорсер, значительно усилит вашу уверенность в приложении, которые вы продаете.
Практические рекомендации по тестированию разделим так же – по видам уязвимостей.
Первым в списке для тестирования можно выделить тестирование паролей. Чем более ваш продукт требователен к формату пароля, тем лучше. В сети достаточно много приложений для взлома пароля, списков наиболее распространенных паролей и имен пользователей. Моя рекомендация – воспользуйтесь ими для тестирования. Неочевидным при тестировании, но важным элементом проверки безопасности паролей является тестирование cookies браузера. Общая рекомендация – использовать шифрование паролей в cookies браузера. Злоумышленник может элементарно, «на глазок», без спец. программ, найти пароль. Та же рекомендация касается сохранения пароля в базе и при передаче пароля от клиента к серверу – шифруйте пароли. Даже если при помощи инъекции злоумышленник получит доступ к базе, есть возможность, что пароль он не расшифрует. Тестирование паролей проводится при помощи проверки тестировщиком базы данных, путем составления запросов в соответствующие таблицы, просмотр cookies браузера, и source кода страницы. Это можно делать как простым поиском, так и при помощи специальных программ.
URL манипуляции чаще всего возможны там, где используется HTTP GET метод для передачи информации между клиентом и сервером. Информация передается в URL с элементами запроса в базу данных (это может быть user ID, группа пользователей и др.). Тестировщик, в таком случае, меняет те данные в URL запросе, которые соответствуют запросу в базу. К примеру, в URL ниже можно менять значение для параметра WORKSTATION и ACTIVITY_ID. После изменения, жмем GO в браузере и смотрим, что будет. Сервер не должен пускать нас туда, куда не следует.
mysite.com/client/workstation.php?WORKSTATION=client_1&ACTIVITY_ID=CREATE_USER
В случае с URL манипуляциями, любое нестандартное поведение приложения может открыть дверь злоумышленнику.
SQL инъекции довольно распространенный способ проникновения в приложение. Как и остальные виды тестирования безопасности, этот элемент тесно связан с работой разработчиков. Простейшим способом защиты от SQL инъекций является запрет на специальные символы в полях ввода данных, такие как ‘ =; * тоесть все те символы, без которых невозможно выполнение запроса. Вместе с разработчиками постарайтесь найти места в приложении, где есть запросы в базу с использованием пользовательских данных. Особенно это касается приложений установленных на производствах. Если пользовательские данные содержат SQL запрос для базы, даже при наличии сообщении об ошибке, запрос может быть выполнен, поэтому в этом случае необходимо не только протестировать случаи SQL инъекций, но и на уровне кода правильно на них реагировать.
Чтобы протестировать защиту от XSS атак, необходимо убедиться что любые или
Уязвимости и приёмы тестирования безопасность под катом.
Не будем останавливаться на том, что тестирование безопасности, это вид тестирования, который позволяет нам быть уверенными что персональная и конфиденциальная информация, хранящаяся на наших серверах, таковой и останется. Безопасность включает в себя и тестирование того, что пользователи с разными правами доступа остаются в рамках этих прав. Например, в случае вселенской проницательности и знания пары запросов в SQL пользователь с правами просмотра, вдруг не свергнет администратора с престола или не подменит в программе что-то, пока тот же администратор моргает или варит себе кофе.
Для того чтоб статья была понятна не только опытным хаброюзерам, но и начинающим тестировщикам и программистам, начнем с описания основных терминов которыми любят козырять спецы в области безопасности.
Уязвимости (Vulnerabilities) — это слабые места в приложение, которые «яйцеголовые хакеры» злоумышленники используют для проникновения в программу. Причиной таких уязвимостей может стать недостаточно хорошо написанный код, SQL-, скрипт-, код-инъекции (SQL-, script-, code-injections) или попросту вирусы пролезшие на сервер.
Понятие крос-сайтовое скрипование — это мой вольный перевод понятия XSS (Cross Site Scripting) представляет собой ввод HTML скрипта в пользовательский интерфейс приложения (на стороне клиента), и его выполнение сервером. В результате чего, до некоторых пор секретная информация, будет видна всем пользователям.
Манипуляции со ссылками (URL manipulation) – Web приложения «общаются» с сервером в форме клинт-сервеного обмена данными. Некоторое количество информации передается на сервер и при помощи ссылки (URL), по которой работает клиент. Изменение или добавление информации в URL-е может вести к непредвиденным последствиям… Ниже приведен пример URL, мы можем изменить все что после знака? и передать это все серверу на выполнение.
mysite.com/client/workstation.php?WORKSTATION=client_1&ACTIVITY_ID=CREATE_USER
SQL инъекции (SQL injection) – это проникновение и выполнение вредоносных действий путем выполнения SQL запросов введенных в поля пользовательского интерфейса приложения. В дальнейшем, если не существует никаких ограничений, сервер выполнит запрос и будет взломан. Примером SQL инъекции может быть следующий запрос введенный в поле User ID
SELECT * FROM Users WHERE User_Name = ‘Ivan’ AND Password = ‘Pupkin’
Отдельно стоит спуфинг (Spoofing) о нем уже много говорилось, вкратце это создание клона сайта или e-mail сервера с последующим его использованием для нанесения вреда владельцу и пользователям приложения или компании.
Выяснив основные внешние угрозы для нашего приложения давайте остановимся на приемах тестирования, которые позволят нам предупредить доступ к нашему приложению злоумышленников.
В первую очередь требования к тестировщикам, тестирующим безопасность, выше, чем к обычным тестировщикам. Они должны понимать основные принципы работы HTTP\HTTPS протоколов, необходимо понимать, как именно то или иное клиентское приложение общается с сервером, хорошо бы знать один-два приема SQL и XSS инъекции. Наличие такого специалиста, даже если это будет аутсорсер, значительно усилит вашу уверенность в приложении, которые вы продаете.
Практические рекомендации по тестированию разделим так же – по видам уязвимостей.
Первым в списке для тестирования можно выделить тестирование паролей. Чем более ваш продукт требователен к формату пароля, тем лучше. В сети достаточно много приложений для взлома пароля, списков наиболее распространенных паролей и имен пользователей. Моя рекомендация – воспользуйтесь ими для тестирования. Неочевидным при тестировании, но важным элементом проверки безопасности паролей является тестирование cookies браузера. Общая рекомендация – использовать шифрование паролей в cookies браузера. Злоумышленник может элементарно, «на глазок», без спец. программ, найти пароль. Та же рекомендация касается сохранения пароля в базе и при передаче пароля от клиента к серверу – шифруйте пароли. Даже если при помощи инъекции злоумышленник получит доступ к базе, есть возможность, что пароль он не расшифрует. Тестирование паролей проводится при помощи проверки тестировщиком базы данных, путем составления запросов в соответствующие таблицы, просмотр cookies браузера, и source кода страницы. Это можно делать как простым поиском, так и при помощи специальных программ.
URL манипуляции чаще всего возможны там, где используется HTTP GET метод для передачи информации между клиентом и сервером. Информация передается в URL с элементами запроса в базу данных (это может быть user ID, группа пользователей и др.). Тестировщик, в таком случае, меняет те данные в URL запросе, которые соответствуют запросу в базу. К примеру, в URL ниже можно менять значение для параметра WORKSTATION и ACTIVITY_ID. После изменения, жмем GO в браузере и смотрим, что будет. Сервер не должен пускать нас туда, куда не следует.
mysite.com/client/workstation.php?WORKSTATION=client_1&ACTIVITY_ID=CREATE_USER
В случае с URL манипуляциями, любое нестандартное поведение приложения может открыть дверь злоумышленнику.
SQL инъекции довольно распространенный способ проникновения в приложение. Как и остальные виды тестирования безопасности, этот элемент тесно связан с работой разработчиков. Простейшим способом защиты от SQL инъекций является запрет на специальные символы в полях ввода данных, такие как ‘ =; * тоесть все те символы, без которых невозможно выполнение запроса. Вместе с разработчиками постарайтесь найти места в приложении, где есть запросы в базу с использованием пользовательских данных. Особенно это касается приложений установленных на производствах. Если пользовательские данные содержат SQL запрос для базы, даже при наличии сообщении об ошибке, запрос может быть выполнен, поэтому в этом случае необходимо не только протестировать случаи SQL инъекций, но и на уровне кода правильно на них реагировать.
Чтобы протестировать защиту от XSS атак, необходимо убедиться что любые или