The Web Security Testing Guide (WSTG) Project produces the premier cybersecurity testing resource for web application developers and security professionals.
The WSTG is a comprehensive guide to testing the security of web applications and web services. Created by the collaborative efforts of cybersecurity professionals and dedicated volunteers, the WSTG provides a framework of best practices used by penetration testers and organizations all over the world.
Contributions
Any contributions to the guide itself should be made via the guide’s project repo.
Stable
View the always-current stable version at stable.
Latest
We are currently developing release version 5.0.
You can read the latest development documents in our official GitHub repository or view the bleeding-edge content at latest.
Versioned Releases
v4.2 is currently available as a web-hosted release and PDF. Previous releases are available as PDFs and in some cases web content via the Release Versions tab.
How To Reference WSTG Scenarios
Each scenario has an identifier in the format WSTG-<category>-<number>
, where: ‘category’ is a 4 character upper case string that identifies the type of test or weakness, and ‘number’ is a zero-padded numeric value from 01 to 99. For example:WSTG-INFO-02
is the second Information Gathering test.
The identifiers may change between versions therefore it is preferable that other documents, reports, or tools use the format: WSTG-<version>-<category>-<number>
, where: ‘version’ is the version tag with punctuation removed. For example: WSTG-v41-INFO-02
would be understood to mean specifically the second Information Gathering test from version 4.1.
If identifiers are used without including the <version>
element then they should be assumed to refer to the latest Web Security Testing Guide content. Obviously as the guide grows and changes this becomes problematic, which is why writers or developers should include the version element.
Linking
Linking to Web Security Testing Guide scenarios should be done using versioned links not stable
or latest
which will definitely change with time. However, it is the project team’s intention that versioned links not change. For example: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server
. Note: the v42
element refers to version 4.2.
Stable
View the always-current stable version at stable.
[Unreleased 4.3]
[Version 4.2] — 2020-12-03
Version 4.2 introduces new testing scenarios, updates existing chapters, and offers an improved writing style and chapter layout.
Download the v4.2 PDF here.
[Version 4.1] — 2020-04-21
Version 4.1 serves as a post-migration stable version under the new GitHub repository workflow.
Download the v4.1 PDF here.
[Version 4.0] — 2014-09-17
Download the v4 PDF here.
A printed book is also made available for purchase.
[Version 3.0] — 2008-12-16
Download the v3 PDF here.
[Pre-release 3.0] — 2008-11-06
View a presentation (PPT) previewing the release at the OWASP EU Summit 2008 in Portugal.
[Version 2.0] — 2007-02-10
Download the v2 PDF here.
The guide is also available in Word Document format in English (ZIP) as well as Word Document format translation in Spanish (ZIP).
[Version 1.1] — 2004-08-14
Version 1.1 is released as the OWASP Web Application Penetration Checklist.
Download the v1.1 PDF here.
[Version 1.0] — 2004-12-10
Download the v1 PDF here.
Archives
Historical archives of the Mailman owasp-testing mailing list are available to view or download.
How can I help?
We are actively inviting new contributors to help keep the WSTG up to date! You can get started at our official GitHub repository.
To report issues or make suggestions for the WSTG, please use GitHub Issues.
For everything else, we’re easy to find on Slack:
- Join the OWASP Group Slack with this invitation link.
- Join this project’s channel, #testing-guide.
You can @ us on Twitter @owasp_wstg.
Table of Contents
0. Foreword by Eoin Keary
1. Frontispiece
2. Introduction
2.1 The OWASP Testing Project
2.2 Principles of Testing
2.3 Testing Techniques Explained
2.4 Manual Inspections and Reviews
2.5 Threat Modeling
2.6 Source Code Review
2.7 Penetration Testing
2.8 The Need for a Balanced Approach
2.9 Deriving Security Test Requirements
2.10 Security Tests Integrated in Development and Testing Workflows
2.11 Security Test Data Analysis and Reporting
3. The OWASP Testing Framework
3.1 The Web Security Testing Framework
3.2 Phase 1 Before Development Begins
3.3 Phase 2 During Definition and Design
3.4 Phase 3 During Development
3.5 Phase 4 During Deployment
3.6 Phase 5 During Maintenance and Operations
3.7 A Typical SDLC Testing Workflow
3.8 Penetration Testing Methodologies
4. Web Application Security Testing
4.0 Introduction and Objectives
4.1 Information Gathering
4.1.1 Conduct Search Engine Discovery Reconnaissance for Information Leakage
4.1.2 Fingerprint Web Server
4.1.3 Review Webserver Metafiles for Information Leakage
4.1.4 Enumerate Applications on Webserver
4.1.5 Review Webpage Content for Information Leakage
4.1.6 Identify Application Entry Points
4.1.7 Map Execution Paths Through Application
4.1.8 Fingerprint Web Application Framework
4.1.9 Fingerprint Web Application
4.1.10 Map Application Architecture
4.2 Configuration and Deployment Management Testing
4.2.1 Test Network Infrastructure Configuration
4.2.2 Test Application Platform Configuration
4.2.3 Test File Extensions Handling for Sensitive Information
4.2.4 Review Old Backup and Unreferenced Files for Sensitive Information
4.2.5 Enumerate Infrastructure and Application Admin Interfaces
4.2.6 Test HTTP Methods
4.2.7 Test HTTP Strict Transport Security
4.2.8 Test RIA Cross Domain Policy
4.2.9 Test File Permission
4.2.10 Test for Subdomain Takeover
4.2.11 Test Cloud Storage
4.3 Identity Management Testing
4.3.1 Test Role Definitions
4.3.2 Test User Registration Process
4.3.3 Test Account Provisioning Process
4.3.4 Testing for Account Enumeration and Guessable User Account
4.3.5 Testing for Weak or Unenforced Username Policy
4.4 Authentication Testing
4.4.1 Testing for Credentials Transported over an Encrypted Channel
4.4.2 Testing for Default Credentials
4.4.3 Testing for Weak Lock Out Mechanism
4.4.4 Testing for Bypassing Authentication Schema
4.4.5 Testing for Vulnerable Remember Password
4.4.6 Testing for Browser Cache Weaknesses
4.4.7 Testing for Weak Password Policy
4.4.8 Testing for Weak Security Question Answer
4.4.9 Testing for Weak Password Change or Reset Functionalities
4.4.10 Testing for Weaker Authentication in Alternative Channel
4.5 Authorization Testing
4.5.1 Testing Directory Traversal File Include
4.5.2 Testing for Bypassing Authorization Schema
4.5.3 Testing for Privilege Escalation
4.5.4 Testing for Insecure Direct Object References
4.6 Session Management Testing
4.6.1 Testing for Session Management Schema
4.6.2 Testing for Cookies Attributes
4.6.3 Testing for Session Fixation
4.6.4 Testing for Exposed Session Variables
4.6.5 Testing for Cross Site Request Forgery
4.6.6 Testing for Logout Functionality
4.6.7 Testing Session Timeout
4.6.8 Testing for Session Puzzling
4.6.9 Testing for Session Hijacking
4.7 Input Validation Testing
4.7.1 Testing for Reflected Cross Site Scripting
4.7.2 Testing for Stored Cross Site Scripting
4.7.3 Testing for HTTP Verb Tampering
4.7.4 Testing for HTTP Parameter Pollution
4.7.5 Testing for SQL Injection
4.7.5.1 Testing for Oracle
4.7.5.2 Testing for MySQL
4.7.5.3 Testing for SQL Server
4.7.5.4 Testing PostgreSQL
4.7.5.5 Testing for MS Access
4.7.5.6 Testing for NoSQL Injection
4.7.5.7 Testing for ORM Injection
4.7.5.8 Testing for Client-side
4.7.6 Testing for LDAP Injection
4.7.7 Testing for XML Injection
4.7.8 Testing for SSI Injection
4.7.9 Testing for XPath Injection
4.7.10 Testing for IMAP SMTP Injection
4.7.11 Testing for Code Injection
4.7.11.1 Testing for Local File Inclusion
4.7.11.2 Testing for Remote File Inclusion
4.7.12 Testing for Command Injection
4.7.13 Testing for Format String Injection
4.7.14 Testing for Incubated Vulnerability
4.7.15 Testing for HTTP Splitting Smuggling
4.7.16 Testing for HTTP Incoming Requests
4.7.17 Testing for Host Header Injection
4.7.18 Testing for Server-side Template Injection
4.7.19 Testing for Server-Side Request Forgery
4.8 Testing for Error Handling
4.8.1 Testing for Improper Error Handling
4.8.2 Testing for Stack Traces
4.9 Testing for Weak Cryptography
4.9.1 Testing for Weak Transport Layer Security
4.9.2 Testing for Padding Oracle
4.9.3 Testing for Sensitive Information Sent via Unencrypted Channels
4.9.4 Testing for Weak Encryption
4.10 Business Logic Testing
4.10.0 Introduction to Business Logic
4.10.1 Test Business Logic Data Validation
4.10.2 Test Ability to Forge Requests
4.10.3 Test Integrity Checks
4.10.4 Test for Process Timing
4.10.5 Test Number of Times a Function Can Be Used Limits
4.10.6 Testing for the Circumvention of Work Flows
4.10.7 Test Defenses Against Application Misuse
4.10.8 Test Upload of Unexpected File Types
4.10.9 Test Upload of Malicious Files
4.11 Client-side Testing
4.11.1 Testing for DOM-Based Cross Site Scripting
4.11.2 Testing for JavaScript Execution
4.11.3 Testing for HTML Injection
4.11.4 Testing for Client-side URL Redirect
4.11.5 Testing for CSS Injection
4.11.6 Testing for Client-side Resource Manipulation
4.11.7 Testing Cross Origin Resource Sharing
4.11.8 Testing for Cross Site Flashing
4.11.9 Testing for Clickjacking
4.11.10 Testing WebSockets
4.11.11 Testing Web Messaging
4.11.12 Testing Browser Storage
4.11.13 Testing for Cross Site Script Inclusion
4.12 API Testing
4.12.1 Testing GraphQL
5. Reporting
Appendix B. Suggested Reading
Appendix C. Fuzz Vectors
Appendix D. Encoded Injection
Appendix E. History
OWASP Web Security Testing Guide
Welcome to the official repository for the Open Web Application Security Project® (OWASP®) Web Security Testing Guide (WSTG). The WSTG is a comprehensive guide to testing the security of web applications and web services. Created by the collaborative efforts of security professionals and dedicated volunteers, the WSTG provides a framework of best practices used by penetration testers and organizations all over the world.
We are currently working on release version 5.0. You can read the current document here on GitHub.
For the last stable release, check release 4.2. Also available online.
- How To Reference WSTG Scenarios
- Linking
- Contributions, Feature Requests, and Feedback
- Chat With Us
- Project Leaders
- Core Team
- Translations
How To Reference WSTG Scenarios
Each scenario has an identifier in the format WSTG-<category>-<number>
, where: ‘category’ is a 4 character upper case string that identifies the type of test or weakness, and ‘number’ is a zero-padded numeric value from 01 to 99. For example:WSTG-INFO-02
is the second Information Gathering test.
The identifiers may change between versions. Therefore, it is preferable that other documents, reports, or tools use the format: WSTG-<version>-<category>-<number>
, where: ‘version’ is the version tag with punctuation removed. For example: WSTG-v42-INFO-02
would be understood to mean specifically the second Information Gathering test from version 4.2.
If identifiers are used without including the <version>
element, they should be assumed to refer to the latest Web Security Testing Guide content. Obviously as the guide grows and changes this becomes problematic, which is why writers or developers should include the version element.
Linking
Linking to Web Security Testing Guide scenarios should be done using versioned links not stable
or latest
, which will definitely change with time. However, it is the project team’s intention that versioned links not change. For example: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.html
. Note: the v42
element refers to version 4.2.
Contributions, Feature Requests, and Feedback
We are actively inviting new contributors! To start, read the contribution guide.
First time here? Here are GitHub’s suggestions for first-time contributors to this repository.
This project is only possible thanks to the work of many dedicated volunteers. Everyone is encouraged to help in ways large and small. Here are a few ways you can help:
- Read the current content and help us fix any spelling mistakes or grammatical errors.
- Help with translation efforts.
- Choose an existing issue and submit a pull request to fix it.
- Open a new issue to report an opportunity for improvement.
To learn how to contribute successfully, read the contribution guide.
Successful contributors appear on the project’s list of authors, reviewers, or editors.
Chat With Us
We’re easy to find on Slack:
- Join the OWASP Group Slack with this invitation link.
- Join this project’s channel, #testing-guide.
Feel free to ask questions, suggest ideas, or share your best recipes.
You can @ us on Twitter @owasp_wstg.
You can also join our Google Group.
Project Leaders
- Rick Mitchell
- Elie Saad
Core Team
- Rejah Rehim
- Victoria Drake
Translations
- Portuguese-BR
- Russian
- French
- Persian (Farsi)
Open Web Application Security Project and OWASP are registered trademarks of the OWASP Foundation, Inc.
Уровень сложности
Средний
Время на прочтение
5 мин
Количество просмотров 6.9K
Open Web Application Security Project (OWASP) — организация, целью которой является улучшение защищённости приложений. Большинство специалистов в области информационной безопасности знакомы с OWASP Top Ten. У OWASP есть множество других проектов для различных этапов жизненного цикла разработки программного обеспечения (SDLC).
В предыдущей статье на Хабр я рассказывал о стандарте OWASP ASVS, в котором перечислены требования к безопасности web-приложений. А как убедиться в том, что эти требования выполняются? Например, посредством Web Security Testing Guide (WSTG) — Руководства по тестированию безопасности web-приложений, перевод которого я и хотел бы представить вашему вниманию.
Что из себя представляет WSTG?
За более чем 20 лет своей работы под эгидой OWASP появилось множество проектов в области безопасности приложений. Один из флагманских — Web Security Testing Guide (WSTG) — Руководство по тестированию безопасности web-приложений, с которым вы можете свободно ознакомиться. В нём описываются приёмы, методики, инструменты и ресурсы для тестирования наиболее распространённых уязвимостей web-приложений.
Текущая версия WSTG — 4.2. Также доступны материалы для будущей версии 5.0, которая в настоящее время разрабатывается и обновляется. Это не первая попытка перевода WSTG, но полной версии я в свободном доступе не нашёл, поэтому решил взяться за текущую, актуальную на 2022 г. (latest).
Какое место занимает WSTG в методике тестирования OWASP?
WSTG фокусируется на этапе развёртывания и, в частности, тестировании на проникновение. В различных сценариях для поиска уязвимостей предлагаются разные методы тестирования (т.н. «белого», «серого» и «чёрного ящика»), однако «красной нитью» по тексту прослеживается мысль о необходимости сбалансированного подхода, сочетающего всё перечисленное, т. к. каждый метод имеет свою область применения, преимущества и недостатки (однако, на тесты надейся, а Дейкстру не забывай).
Области тестирования WSTG
WSTG охватывает следующие области тестирования:
-
Сбор информации: получение информации о web-сервере, приложении и его архитектуре.
-
Тестирование управления конфигурациями и развёртыванием: определение конфигурации сети и приложений, используемые HTTP-методы, а также относительно новые сценарии, такие как захват поддомена и облачные хранилища.
-
Тестирование управления идентификацией: определение ролей (RBAC), регистрацию пользователей и инвентаризацию учётных записей.
-
Тестирование аутентификации: выявление учётных данных по умолчанию, блокировка пользователя, парольная политика, МФА и т.д.
-
Тестирование авторизации: обход каталогов, повышение привилегий, IDOR и OAuth.
-
Тестирование управления сессиями: фиксация и перехват сессий, атрибуты cookie, CSRF и JWT.
-
Тестирование контроля входных данных: XSS-атаки, различные типы инъекций, включая SQL (с учётом специфики СУБД), XML, SSTI, LFI/RFI, SSRF и др.
-
Тестирование обработки ошибок.
-
Тестирование криптографии: TLS и шифрование.
-
Тестирование бизнес-логики: поиск нарушений в бизнес-логике. Например, в бизнес-процессе необходимо, чтобы пользователь выполнил шаг 1, а затем шаг 2. Если мы сможем выполнить шаг 2, не выполняя шага 1 — это нарушение логики. Конкретного способа, как найти такие уязвимости нет, но WSTG предлагает как протестировать их наличие.
-
Тестирование на стороне клиента: сценарии DOM-XSS, HTML-, JS- и CSS-инъекции, CORS, WebSockets, кликджекинг и др.
-
Тестирование API: GraphQL.
Не менее интересны и приложения к Руководству:
-
Описание инструментов тестирования.
-
Как написать отчёт о тестировании и схемы наименования для ПО и компонентов.
-
Полезная нагрузка: векторы фаззинга для всех видов инъекций.
-
Описание и рекомендации по закодированным инъекциям.
Информации и ресурсов в WSTG много — несколько сотен страниц в pdf-версии. Ошибок в переводе соответственно тоже — пишите, пожалуйста, о них в ЛС.
С чего начать работу с WSTG?
Руководство поначалу может казаться пугающим из-за объёма — порядка ста сценариев тестирования. Давайте обсудим способы внедрения WSTG в SDLC конкретной организации.
Обучение безопасной разработке: команды разработки и тестирования должны регулярно практиковаться в сценариях тестирования, а также изучать инструменты. Хотя WSTG и ориентирован на тестирование, Руководство включает в себя рекомендации и для разработчиков.
Расставьте приоритеты для тестов: невозможно применить всё и сразу. Во-первых, надо выбрать сценарии, которые уместны в контексте вашей ситуации и могут предотвратить наиболее серьёзные из известных вам рисков. Дайте команде время на освоение, а затем постепенно добавляйте тесты в свой SDLC в соответствии с имеющимися ресурсами.
Как определить, какие сценарии тестирования подходят для начала внедрения WSTG? Первые кандидаты:
-
Тесты, связанные с архитектурой ваших приложений и информацией, которую вы защищаете. Например, если в приложении используется протокол OAuth, то важно включить сценарий Тестирование уязвимостей в Oauth, а если есть процесс оплаты, то нужен сценарий Тестирование платёжных функций.
-
Тесты, относящиеся к OWASP Top 10. Они охватывают наиболее распространённые угрозы для web-приложений.
-
Тесты, в которых у команды больше опыта. По мере изучения, можно добавлять новые.
-
Внедряйте WSTG вместе с «родственными» проектами OWASP. Например, ASVS. С ним связаны Proactive Top 10 и серия памяток, содержащих практические рекомендации. Идея состоит в том, чтобы улучшить не отдельно взятый этап SDLC, а столько, сколько вы сможете себе позволить при имеющихся ресурсах.
-
Назначьте «WSTG-чемпиона» — участника команды, который имеет больше опыта в WSTG. Эта роль поможет распространить и внедрить WSTG в вашей компании.
-
Регулярно контролируйте результаты и сообщайте о них руководству. Динамика таких показателей, как «количество обнаруженных уязвимостей по уровням критичности», может показать, насколько хорошо команда находит реальные уязвимости и как практика тестирования безопасности улучшает защищённость ваших web-приложений.
WSTG для самостоятельных тестировщиков
Ресурсы WSTG могут пригодиться экспертам кибербезопасности, исследователям уязвимостей и студентам. Для проведения тестов в лабораторных условиях можно быстро развернуть виртуалку с дистрибутивом Samurai WTF (Web Testing Framework, а вы что подумали?), в которой инструменты тестирования уживаются с зоопарком из уязвимых web-приложений.
Пентестерам и Bug Bounty-хантерам рекомендуется дополнять тесты другими ресурсами и актуальными публикациями об уязвимостях и новых методах тестирования.
Автоматизация тестирования web-приложений
WSTG представляет собой структурированный источник информации в формате wiki, предназначенный для того, чтобы снизить вероятность уязвимостей в коде и обеспечить киберустойчивость приложения после развёртывания. Устранение дефектов на ранних стадиях является проблемой, с которой сталкиваются все разработчики. На пути к созданию защищённых приложений появился целый ряд технологий автоматизации тестирования. Использование инструментов статического анализа кода (SAST) позволяет выявлять уязвимости в исходном коде приложений (white box). Динамическое тестирование приложений (DAST) обеспечивает взгляд на запущенное приложение «снаружи» (black box) до его вывода в эксплуатацию. Интерактивное тестирование (IAST) как симбиоз SAST и DAST, применяется для анализа дефектов в работающих приложениях в режиме реального времени с помощью встроенных в приложение сенсоров (агентов), и проводит автотесты в среде разработки или тестирования (например, Selenium). Список инструментов автоматизации с открытым исходным кодом также есть на сайте OWASP.
Все эти возможности позволяют улучшить защищённость приложений. Один из проектов OWASP — Benchmark, позволяет оценить точность, охват и производительность инструментов на почти трёх тысячах примерах уязвимостей, из которых половина — настоящие, а остальные — ложные. Можно воспринимать это как призыв к действию для разработчиков инструментов: у вас уже есть функциональность тестирования на соответствие требованиям ASVS и по сценариям WSTG?
Search code, repositories, users, issues, pull requests…
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up