Publish Latest 2026-06-30

latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.md

@@ -23,9 +23,9 @@ All these files may grant the tester access to inner workings, back doors, admin
 
 An important source of vulnerability is found in files unrelated to the application. These files may be created when editing application files, creating on-the-fly backup copies, or leaving old or unreferenced files in the web tree. Performing in-place editing or other administrative actions on production web servers may inadvertently leave backup copies, either generated automatically by the editor while editing files, or by the administrator who is zipping a set of files to create a backup.
 
-It is easy to forget such files and this may pose a serious security threat to the application. It happens because backup copies may be generated with file extensions differing from those of the original files. A `.tar`, `.zip` or `.gz` archive that we generate (and might forget) has obviously a different extension, and the same happens with automatic copies created by many editors (for example, emacs generates a backup copy named `file~` when editing `file`). Making a copy manually can produce a similar effect, such as when 'file' is copied as 'file.old'. The underlying file system the application is on could be making `snapshots` of your application at different points in time without your knowledge, which may also be accessible via the web, posing a similar but different `backup file` style threat to your application.
+It is easy to forget such files and this may pose a serious security threat to the application. It happens because backup copies may be generated with file extensions differing from those of the original files. A `.tar`, `.zip` or `.gz` archive that we generate (and might forget) has obviously a different extension, and the same happens with automatic copies created by many editors (for example, emacs generates a backup copy named `file~` when editing `file`). Making a copy manually can produce a similar effect, such as when `file` is copied as `file.old` or `file.bak`. The underlying file system the application is on could be making snapshots of your application at different points in time without your knowledge, which may also be accessible via the web, posing a similar but different backup file style threat to your application.
 
-As a result, these activities generate files that are not needed by the application and may be handled differently than the original file by the web server. For example, if we make a copy of login.asp and name it login.asp.old without proper security measures, it could potentially allow users to download the source code of login.asp. This is because `login.asp.old` will be typically served as text or plain, rather than being executed because of its extension. In other words, accessing `login.asp` causes the execution of the server-side code of `login.asp`, while accessing `login.asp.old` causes the content of `login.asp.old` (which is, again, server-side code) to be plainly returned to the user and displayed in the browser. This may pose security risks, since sensitive information may be revealed.
+As a result, these activities generate files that are not needed by the application and may be handled differently than the original file by the web server. For example, if we make a copy of `login.asp` and name it `login.asp.old` without proper security measures, it could potentially allow users to download the source code of login.asp. This is because `login.asp.old` will be typically served as text or plain, rather than being executed because of its extension. In other words, accessing `login.asp` causes the execution of the server-side code of `login.asp`, while accessing `login.asp.old` causes the content of `login.asp.old` (which is, again, server-side code) to be plainly returned to the user and displayed in the browser. This may pose security risks, since sensitive information may be revealed.
 
 Generally, exposing server-side code is a bad idea. Not only are you unnecessarily exposing business logic, but you may be unknowingly revealing application-related information which may help an attacker (path names, data structures, etc.). Not to mention the fact that there are too many scripts with embedded username and password in clear text (which is a careless and extremely dangerous practice).
 
@@ -56,7 +56,7 @@ Testing for unreferenced files uses both automated and manual techniques, and ty
 
 #### Inference from the Naming Scheme Used for Published Content
 
-Enumerate all of the application’s pages and functionality. This can be done manually using a browser, or using an application spidering tool. Most applications use a recognizable naming scheme, and organize resources into pages and directories using words that describe their function. It is often possible to infer the name and location of unreferenced pages from the naming scheme used for published content. For example, if a page titled viewuser.asp is found, one should also look for edituser.asp, adduser.asp, and deleteuser.asp. Similarly, if a directory /app/user is discovered, one should also search for /app/admin and /app/manager.
+Enumerate all of the application’s pages and functionality. This can be done manually using a browser, or using an application spidering tool. Most applications use a recognizable naming scheme, and organize resources into pages and directories using words that describe their function. It is often possible to infer the name and location of unreferenced pages from the naming scheme used for published content. For example, if a page titled `viewuser.asp` is found, one should also look for `edituser.asp`, `adduser.asp`, and `deleteuser.asp`. Similarly, if a directory `/app/user` is discovered, one should also search for `/app/admin` and `/app/manager`.
 
 #### Other Clues in Published Content
 

latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.md

@@ -19,10 +19,10 @@ Administrator interfaces may be present in the application or on the application
 
 An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:
 
-- user account provisioning
-- site design and layout
-- data manipulation
-- configuration changes
+- User account provisioning
+- Site design and layout
+- Data manipulation
+- Configuration changes
 
 In many instances, such interfaces do not have sufficient controls to protect them from unauthorized access. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.
 

latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/11-Test_Cloud_Storage.md

@@ -27,8 +27,8 @@ A known example is where an Amazon S3 bucket is misconfigured, although the othe
 
 First, identify the URL to access the data in the storage service, and then consider the following tests:
 
-- read unauthorized data
-- upload a new arbitrary file
+- Read unauthorized data
+- Upload a new arbitrary file
 
 You may use curl for the tests with the following commands and see if unauthorized actions can be performed successfully.
 

latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/01-Test_Role_Definitions.md

@@ -17,10 +17,10 @@ tags: WSTG
 
 Applications have several types of functionalities and services, and those require access permissions based on the needs of the user. That user could be:
 
-- an administrator, where they manage the application functionalities.
-- an auditor, where they review the application transactions and provide a detailed report.
-- a support engineer, where they help customers debug and fix issues on their accounts.
-- a customer, where they interact with the application and benefit from its services.
+- An administrator, where they manage the application functionalities.
+- An auditor, where they review the application transactions and provide a detailed report.
+- A support engineer, where they help customers debug and fix issues on their accounts.
+- A customer, where they interact with the application and benefit from its services.
 
 In order to handle these uses and any other use case for that application, role definitions are setup (more commonly known as [RBAC](https://en.wikipedia.org/wiki/Role-based_access_control)). Based on these roles, the user is capable of accomplishing the required task.
 
@@ -40,22 +40,24 @@ The tester should start by identifying the application roles being tested throug
 - Guidance by the developers or administrators of the application.
 - Application comments.
 - Fuzz possible roles:
-    - cookie variable (*e.g.* `role=admin`, `isAdmin=True`)
-    - account variable (*e.g.* `Role: manager`)
-    - hidden directories or files (*e.g.* `/admin`, `/mod`, `/backups`)
-    - switching to well known users (*e.g.* `admin`, `backups`, etc.)
+    - Cookie variable (*e.g.* `role=admin`, `isAdmin=True`)
+    - Account variable (*e.g.* `Role: manager`)
+    - Hidden directories or files (*e.g.* `/admin`, `/mod`, `/backups`)
+    - Switching to well known users (*e.g.* `admin`, `backups`, etc.)
 
 ### Switching to Available Roles
 
 After identifying possible attack vectors, the tester needs to test and validate that they can access the available roles.
 
-> Some applications define the roles of the user on creation, through rigorous checks and policies, or by ensuring that the user's role is properly protected through a signature created by the backend. Finding that roles exist doesn't mean that they're a vulnerability.
+> Note: Some applications define the roles of the user on creation, through rigorous checks and policies, or by ensuring that the user's role is properly protected through a signature created by the backend. Finding that roles exist doesn't mean that they're a vulnerability.
 
 ### Review Roles Permissions
 
 After gaining access to the roles on the system, the tester must understand the permissions provided to each role.
 
-A support engineer shouldn't be able to conduct administrative functionalities, manage the backups, or conduct any transactions in the place of a user.
+For example, a support engineer generally shouldn't be able to conduct administrative functionalities, manage the backups, or conduct any transactions in the place of a user.
+
+Users should also not be able to perform actions that increase their own privileges (such as adding themselves to a more privileged role) outside of very specific circumstances.
 
 An administrator shouldn't have full powers on the system. Sensitive admin functionality should leverage a maker-checker principle, or use MFA to ensure that the administrator is conducting the transaction. A clear example on this was the [Twitter incident in 2020](https://blog.twitter.com/en_us/topics/company/2020/an-update-on-our-security-incident.html).
 

latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/02-Test_User_Registration_Process.md

@@ -50,6 +50,10 @@ In contrast, in the Google example below the identification requirements include
 ![Google Registration Page](images/Google_registration_page.jpg)\
 *Figure 4.3.2-2: Google Registration Page*
 
+Some applications may also automatically grant privileged roles to users when they register an account with an email address from a trusted domain. If ownership of the email address is not validated as part of the registration process, this could allow an attacker to gain access to a privileged account by registering a new user on that domain.
+
+Alternatively, if they only perform partial matching of the domain then it may be possible to register a privileged account using other similar domains. For example, if the application checks for email addresses ending in `example.org` then it may be possible to use the `notexample.org` domain; or if it checks for `@example.org` in the email address then it may be possible to use `@example.org.attacker.com`.
+
 ## Remediation
 
 Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect.

latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account.md

@@ -23,6 +23,8 @@ The tester should interact with the authentication mechanism of the application
 
 In some cases, a message is received that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, testers can enumerate the existing users by sending a username and an empty password.
 
+> Note: Some applications do not consider usernames sensitive, and may provide functionality that lets you directly view or list usernames. Ensure that you understand the security requirements of the application before reporting issues around username enumeration.
+
 ## Test Objectives
 
 - Review processes that pertain to user identification (*e.g.* registration, login, etc.).

latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling.md

@@ -19,17 +19,18 @@ All types of applications (web apps, web servers, databases, etc.) will generate
 
 Errors sometimes rise as:
 
-- stack traces,
-- network timeouts,
-- input mismatch,
-- and memory dumps.
+- Stack traces
+- Network timeouts
+- Input mismatch
+- Memory dumps
 
 Improper error handling can allow attackers to:
 
 - Understand the APIs being used internally.
 - Map the various services integrating with each other by gaining insight on internal systems and frameworks used, which opens up doors to attack chaining.
 - Gather the versions and types of applications being used.
-- DoS the system by forcing the system into a deadlock or an unhandled exception that sends a panic signal to the engine running it.
+- Identify filesystem paths.
+- Cause a denial off service by forcing the system into a deadlock or an unhandled exception that sends a panic signal to the engine running it.
 - Controls bypass where a certain exception is not restricted by the logic set around the happy path.
 
 ## Test Objectives
@@ -45,7 +46,7 @@ By trying to send unexpected data, or forcing the system into certain edge cases
 
 ### Web Servers
 
-All web apps run on a web server, whether it was an integrated one or a fully fledged one. Web apps must handle and parse HTTP requests, and for that a web server is always part of the stack. Some of the most famous web servers are Nginx, Apache, and IIS.
+All web apps run on a web server, whether it was an integrated one or a fully fledged one. Web apps must handle and parse HTTP requests, and for that a web server is always part of the stack. Some of the most common web servers are Nginx, Apache, and IIS.
 
 Web servers have known error messages and formats. If one is not familiar with how they look, searching online for them would provide examples. Another way would be to look into their documentation, or simply setup a server locally and discover the errors by going through the pages that the web server uses.
 

latest/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security.md

@@ -45,7 +45,8 @@ There are a large number of protocol versions, ciphers, and extensions supported
 - [TLS compression (CRIME)](https://en.wikipedia.org/wiki/CRIME)
 - [Weak DHE Keys (LOGJAM)](https://weakdh.org/)
 
-The [Mozilla Server-Side TLS Guide](https://wiki.mozilla.org/Security/Server_Side_TLS) details the protocols and ciphers that are currently recommended.
+The [TLSRef project](https://tlsref.org/) (formerly run by Mozilla) provides recommendations for the protocols and ciphers that should be used.
+
 Because of its compatibility with post-quantum ciphers, TLS 1.3 should be preferred over TLS 1.2.
 
 #### Exploitability
@@ -140,5 +141,5 @@ It can also be possible to performed limited testing using a web browser, as mod
 ## References
 
 - [OWASP Transport Layer Protection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html)
-- [Mozilla Server-Side TLS Guide](https://wiki.mozilla.org/Security/Server_Side_TLS)
+- [TLSRef](https://docs.tlsref.org/)
 - [CWE-1428: Reliance on HTTP instead of HTTPS](https://cwe.mitre.org/data/definitions/1428.html)