diff options
Diffstat (limited to 'doc/user/application_security/dast')
16 files changed, 244 insertions, 28 deletions
diff --git a/doc/user/application_security/dast/browser_based.md b/doc/user/application_security/dast/browser_based.md index 4cde1847419..ffcd496e2c3 100644 --- a/doc/user/application_security/dast/browser_based.md +++ b/doc/user/application_security/dast/browser_based.md @@ -111,7 +111,7 @@ a page fully loaded. Browser-based scans consider a page loaded when: 1. The [DOMContentLoaded](https://developer.mozilla.org/en-US/docs/Web/API/Window/DOMContentLoaded_event) event has fired. 1. There are no open or outstanding requests that are deemed important, such as JavaScript and CSS. Media files are usually deemed unimportant. 1. Depending on whether the browser executed a navigation, was forcibly transitioned, or action: - + - There are no new Document Object Model (DOM) modification events after the `DAST_BROWSER_NAVIGATION_STABILITY_TIMEOUT`, `DAST_BROWSER_STABILITY_TIMEOUT`, or `DAST_BROWSER_ACTION_STABILITY_TIMEOUT` durations. After these events have occurred, browser-based scans consider the page loaded and ready, and attempt the next action. diff --git a/doc/user/application_security/dast/checks/1004.1.md b/doc/user/application_security/dast/checks/1004.1.md index 9626973eb36..72af1156b95 100644 --- a/doc/user/application_security/dast/checks/1004.1.md +++ b/doc/user/application_security/dast/checks/1004.1.md @@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w The {cookie_name} cookie was transmitted in a `Set-Cookie` header without the `HttpOnly` attribute set. To prevent JavaScript being able to access the cookie value - usually via `document.cookies` - all -cookies that are used for authorization or contain sensitive information should have the `HttpOnly` attribute +cookies that are used for authorization should have the `HttpOnly` attribute set. ## Remediation diff --git a/doc/user/application_security/dast/checks/16.7.md b/doc/user/application_security/dast/checks/16.7.md new file mode 100644 index 00000000000..a02fb3a451f --- /dev/null +++ b/doc/user/application_security/dast/checks/16.7.md @@ -0,0 +1,42 @@ +--- +stage: Secure +group: Dynamic Analysis +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Strict-Transport-Security header missing or invalid + +## Description + +The `Strict-Transport-Security` header was found to be missing or invalid. The `Strict-Transport-Security` +header allows web site operators to force communications to occur over a TLS connection. By enabling this +header, websites can protect their users from various forms of network eavesdropping or interception attacks. +While most browsers prevent mixed-content (loading resources from HTTP when navigating from an HTTPS site), +this header also ensures that all resource requests are only ever initiated over a secure transport. + +## Remediation + +Only three directives are applicable for the `Strict-Transport-Security` header. + +1. `max-age`: This required directive specifies how long (in seconds) after receiving the response it should communicate only over a secure transport. +1. `includeSubDomains`: This optional, valueless directive signals that the policy applies to this host as well as any subdomains found under this host's domain. +1. `preload`: While not part of the specification, setting this optional value allows major browser organizations to add this site into the browser's preloaded set of HTTPS sites. This requires further action on behalf of the website operator to submit their domain to the browser's HSTS preload list. See [hstspreload.org](https://hstspreload.org/) for more information. + +Note that invalid directives, or the `Strict-Transport-Security` header appearing more than once (if the values are +different) is considered invalid. + +Prior to adding to this security configuration to your website, it is recommended you review the hstspreload.org [Deployment +Recommendations](https://hstspreload.org/#deployment-recommendations). + +## Details + +| ID | Aggregated | CWE | Type | Risk | +|:---|:--------|:--------|:--------|:--------| +| 16.7 | true | 16 | Passive | Low | + +## Links + +- [CWE](https://cwe.mitre.org/data/definitions/16.html) +- [Deployment Recommendations](https://hstspreload.org/#deployment-recommendations) +- [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) +- [RFC](https://datatracker.ietf.org/doc/html/rfc6797) diff --git a/doc/user/application_security/dast/checks/200.1.md b/doc/user/application_security/dast/checks/200.1.md index 9795ad11b0b..fcd329c3f2b 100644 --- a/doc/user/application_security/dast/checks/200.1.md +++ b/doc/user/application_security/dast/checks/200.1.md @@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w ## Description -A private RFC 1918 was identified in the target application. Public facing websites should not be issuing +A private RFC 1918/RFC 4193 address was identified in the target application. Public facing websites should not be issuing requests to private IP Addresses. Attackers attempting to execute subsequent attacks, such as Server-Side Request Forgery (SSRF), may be able to use this information to identify additional internal targets. @@ -27,3 +27,4 @@ facing version, or remove the reference from the target application. - [CWE](https://cwe.mitre.org/data/definitions/200.html) - [RFC](https://datatracker.ietf.org/doc/html/rfc1918) +- [RFC](https://datatracker.ietf.org/doc/html/rfc4193) diff --git a/doc/user/application_security/dast/checks/209.1.md b/doc/user/application_security/dast/checks/209.1.md new file mode 100644 index 00000000000..2e4163bdec0 --- /dev/null +++ b/doc/user/application_security/dast/checks/209.1.md @@ -0,0 +1,43 @@ +--- +stage: Secure +group: Dynamic Analysis +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Generation of error message containing sensitive information + +## Description + +The application was found to return error data such as stack traces. Depending on the data contained within the error message, +this information could be used by an attacker to conduct further attacks. While stack traces are helpful during development +and debugging, they should not be presented to users when an error occurs. + +## Remediation + +Applications should handle exception conditions internally and map known failure types to error codes that can be displayed +to a user. These error codes should be customized to the application and returned along with the relevant HTTP error code. + +When an error occurs, the application identifies the error type or class, and displays a numerical value to the +user. Requests should also be tracked so when a user is presented with an error code, it has a corresponding request ID. +Support teams can then correlate the HTTP error, the customized error code, and the request ID in the log files to +determine the root cause of the error without leaking details to the end user. + +Example of returning customized errors: + +```plaintext +HTTP/1.1 500 Internal Server Error +... +Error [0004] Occurred, please contact support or re-try your request again shortly. +Request ID [a4bc91def12] +... +``` + +## Details + +| ID | Aggregated | CWE | Type | Risk | +|:---|:--------|:--------|:--------|:--------| +| 209.1 | false | 209 | Passive | Low | + +## Links + +- [CWE](https://cwe.mitre.org/data/definitions/209.html) diff --git a/doc/user/application_security/dast/checks/319.1.md b/doc/user/application_security/dast/checks/319.1.md new file mode 100644 index 00000000000..d598fb70ce3 --- /dev/null +++ b/doc/user/application_security/dast/checks/319.1.md @@ -0,0 +1,37 @@ +--- +stage: Secure +group: Dynamic Analysis +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Mixed Content + +## Description + +The target application was found to request resources over insecure transport protocols (HTTP). This is usually due to HTML +elements which load resources using the `http://` scheme instead of `https://`. It should be noted that most modern browsers +block these requests automatically so there is limited risk. + +Some parts of the application may not behave correctly since these files are not being properly loaded. + +## Remediation + +Ensure all HTML elements which load resources from a URL (JavaScript, stylesheets, images, video and other media) are set to +use the `https://` scheme instead of `http://`. Alternatively, developers may use the `//` scheme, which will only load resources +over the same protocol that the originating page was loaded. + +A browser visiting the website `https://example.com` with the HTML loading a file using +`<script src="//example.com/cdn/bundle.js"></script>`, would ensure the `example.com/cdn/bundle.js` file was loaded over +HTTPS. + +## Details + +| ID | Aggregated | CWE | Type | Risk | +|:---|:--------|:--------|:--------|:--------| +| 319.1 | true | 319 | Passive | Info | + +## Links + +- [OWASP](https://owasp.org/www-community/vulnerabilities/Insecure_Transport) +- [CWE](https://cwe.mitre.org/data/definitions/319.html) +- [MDN](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content) diff --git a/doc/user/application_security/dast/checks/352.1.md b/doc/user/application_security/dast/checks/352.1.md new file mode 100644 index 00000000000..4daba908331 --- /dev/null +++ b/doc/user/application_security/dast/checks/352.1.md @@ -0,0 +1,41 @@ +--- +stage: Secure +group: Dynamic Analysis +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Absence of anti-CSRF tokens + +## Description + +The application failed to protect against Cross-Site Request Forgery (CSRF) by using +secure application tokens or `SameSite` cookie directives. + +The vulnerability can be exploited by an attacker creating a link or form on a third +party site and tricking an authenticated victim to access them. + +## Remediation + +Consider setting all session cookies to have the `SameSite=Strict` attribute. However, +it should be noted that this may impact usability when sharing links across other mediums. +It is recommended that a two cookie based approach is taken, as outlined in the +[Top level navigations](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-08#section-8.8.2) section +of the RFC. + +If the application is using a common framework, there is a chance that Anti-CSRF protection +is built in but needs to be enabled. Consult your application framework documentation for +details. + +If neither of the above are applicable, it is **strongly** recommended that a third party library is used. +Implementing a secure Anti-CSRF system is a significant investment and difficult to do correctly. + +## Details + +| ID | Aggregated | CWE | Type | Risk | +|:---|:--------|:--------|:--------|:--------| +| 352.1 | true | 352 | Passive | Medium | + +## Links + +- [OWASP](https://owasp.org/www-community/attacks/csrf) +- [CWE](https://cwe.mitre.org/data/definitions/352.html) diff --git a/doc/user/application_security/dast/checks/359.1.md b/doc/user/application_security/dast/checks/359.1.md index af1fdf8a596..076ab2da0d5 100644 --- a/doc/user/application_security/dast/checks/359.1.md +++ b/doc/user/application_security/dast/checks/359.1.md @@ -8,8 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w ## Description -The target application was found to return credit card information in the response. Organizations -found returning such information may be in violation of industry regulations and could face fines. +The target application was found to return credit card information in the response. Organizations +found returning such information may be in violation of industry regulations and could face fines. ## Remediation @@ -17,7 +17,7 @@ PII such as credit cards should never be directly returned to the user. The majo the last few digits or characters of the identifier. For example, credit card numbers should only return the last four digits: `****-****-****-1234`. Ensure this masking is done on the server and only then send the masked data back to the client. Do not rely on client side JavaScript or other methods -to mask these values as the data could still be intercepted or unmasked. +to mask these values as the data could still be intercepted or unmasked. Additionally, credit card information should never be stored un-encrypted in files or databases. diff --git a/doc/user/application_security/dast/checks/359.2.md b/doc/user/application_security/dast/checks/359.2.md index beb99e26097..2c59b5e321f 100644 --- a/doc/user/application_security/dast/checks/359.2.md +++ b/doc/user/application_security/dast/checks/359.2.md @@ -8,16 +8,16 @@ info: To determine the technical writer assigned to the Stage/Group associated w ## Description -The target application was found to return social security number (SSN) information in the response. Organizations -found returning such information may be in violation of (United States) state or federal laws and may face stiff penalties. +The target application was found to return social security number (SSN) information in the response. Organizations +found returning such information may be in violation of (United States) state or federal laws and may face stiff penalties. ## Remediation -PII such as social security numbers should never be directly returned to the user. The majority of the information +PII such as social security numbers should never be directly returned to the user. The majority of the information should masked except the last few digits or characters of the identifier. For example, social security numbers only be displayed with the last four digits: `***-**-1234`. Ensure this masking is done on the server and only then send the masked data back to the client. Do not rely on client side JavaScript or other methods -to mask these values as the data could still be intercepted or unmasked. +to mask these values as the data could still be intercepted or unmasked. Additionally, social security numbers should never be stored un-encrypted in files or databases. diff --git a/doc/user/application_security/dast/checks/548.1.md b/doc/user/application_security/dast/checks/548.1.md index d6371c5491d..1da2ce58247 100644 --- a/doc/user/application_security/dast/checks/548.1.md +++ b/doc/user/application_security/dast/checks/548.1.md @@ -39,7 +39,7 @@ indexing. ## Links -- [CWE](https://cwe.mitre.org/data/definitions/598.html) +- [CWE](https://cwe.mitre.org/data/definitions/548.html) - [Apache Options](https://httpd.apache.org/docs/2.4/mod/core.html#options) - [NGINX autoindex](https://nginx.org/en/docs/http/ngx_http_autoindex_module.html) - [IIS directoryBrowse element](https://docs.microsoft.com/en-us/iis/configuration/system.webserver/directorybrowse) diff --git a/doc/user/application_security/dast/checks/598.2.md b/doc/user/application_security/dast/checks/598.2.md index f6c6787128d..05d04b71cf0 100644 --- a/doc/user/application_security/dast/checks/598.2.md +++ b/doc/user/application_security/dast/checks/598.2.md @@ -16,7 +16,7 @@ be able to gain access to the target account. ## Remediation Passwords should never be sent in GET requests. When authenticating users or requesting users -reset their passwords, always use POST requests to transmit sensitive data. +reset their passwords, always use `POST` requests to transmit sensitive data. ## Details diff --git a/doc/user/application_security/dast/checks/598.3.md b/doc/user/application_security/dast/checks/598.3.md index fa6fdf43e1c..be17fdcaef6 100644 --- a/doc/user/application_security/dast/checks/598.3.md +++ b/doc/user/application_security/dast/checks/598.3.md @@ -17,7 +17,7 @@ target account. ## Remediation Authorization header details should never be sent in GET requests. When transmitting sensitive information -such as JWT tokens, always use POST requests or headers to transmit the sensitive data. +such as JWT tokens, always use `POST` requests or headers to transmit the sensitive data. ## Details diff --git a/doc/user/application_security/dast/checks/601.1.md b/doc/user/application_security/dast/checks/601.1.md new file mode 100644 index 00000000000..26ccd877104 --- /dev/null +++ b/doc/user/application_security/dast/checks/601.1.md @@ -0,0 +1,34 @@ +--- +stage: Secure +group: Dynamic Analysis +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# URL redirection to untrusted site ('open redirect') + +## Description + +This site was found to allow open redirects from user supplied input. Open redirects are commonly +abused in phishing attacks where the original domain or URL looks like a legitimate link, but then +redirects a user to a malicious site. An example would be +`https://example.com/redirect?url=https://%62%61%64%2e%63%6f%6d%2f%66%61%6b%65%6c%6f%67%69%6e` which, +when decoded turns into `bad.com/fakelogin`. + +## Remediation + +Never redirect a client based on user input found in a `GET` request. It is recommended that the list +of target links to redirect a user to are contained server side, and retrieved using a numerical value +as an index to return the link to be redirected to. For example, `/redirect?id=1` would cause the +application to look up the `1` index and return a URL such as `https://example.com`. This URL would +then be used to redirect the user, using the 301 response code and `Location` header. + +## Details + +| ID | Aggregated | CWE | Type | Risk | +|:---|:--------|:--------|:--------|:--------| +| 601.1 | true | 601 | Passive | Low | + +## Links + +- [OWASP](https://owasp.org/www-project-cheat-sheets/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) +- [CWE](https://cwe.mitre.org/data/definitions/601.html) diff --git a/doc/user/application_security/dast/checks/index.md b/doc/user/application_security/dast/checks/index.md index 629ff1c3a8d..e2947d5b120 100644 --- a/doc/user/application_security/dast/checks/index.md +++ b/doc/user/application_security/dast/checks/index.md @@ -17,13 +17,18 @@ The [DAST browser-based crawler](../browser_based.md) provides a number of vulne | [16.4](16.4.md) | X-Backend-Server header exposes server information | Info | Passive | | [16.5](16.5.md) | AspNet header exposes version information | Low | Passive | | [16.6](16.6.md) | AspNetMvc header exposes version information | Low | Passive | +| [16.7](16.7.md) | Strict-Transport-Security header missing or invalid | Low | Passive | | [200.1](200.1.md) | Exposure of sensitive information to an unauthorized actor (private IP address) | Low | Passive | +| [209.1](209.1.md) | Generation of error message containing sensitive information | Low | Passive | +| [319.1](319.1.md) | Mixed Content | Info | Passive | +| [352.1](352.1.md) | Absence of anti-CSRF tokens | Medium | Passive | | [359.1](359.1.md) | Exposure of Private Personal Information (PII) to an unauthorized actor (credit card) | Medium | Passive | | [359.2](359.2.md) | Exposure of Private Personal Information (PII) to an unauthorized actor (United States social security number) | Medium | Passive | | [548.1](548.1.md) | Exposure of information through directory listing | Low | Passive | | [598.1](598.1.md) | Use of GET request method with sensitive query strings (session ID) | Medium | Passive | | [598.2](598.2.md) | Use of GET request method with sensitive query strings (password) | Medium | Passive | | [598.3](598.3.md) | Use of GET request method with sensitive query strings (Authorization header details) | Medium | Passive | +| [601.1](601.1.md) | URL redirection to untrusted site ('open redirect') | Low | Passive | | [614.1](614.1.md) | Sensitive cookie without Secure attribute | Low | Passive | | [693.1](693.1.md) | Missing X-Content-Type-Options: nosniff | Low | Passive | | [829.1](829.1.md) | Inclusion of Functionality from Untrusted Control Sphere | Low | Passive | diff --git a/doc/user/application_security/dast/dast_troubleshooting.md b/doc/user/application_security/dast/dast_troubleshooting.md index 9969526c906..50570b89920 100644 --- a/doc/user/application_security/dast/dast_troubleshooting.md +++ b/doc/user/application_security/dast/dast_troubleshooting.md @@ -89,6 +89,16 @@ include: - template: DAST.latest.gitlab-ci.yml ``` +## Getting error `shell not found` when using DAST CI/CD template + +When including the DAST CI/CD template as described in the documentation, the job may fail, with an error like the following recorded in the job logs: + +```shell +shell not found +``` + +To avoid this error, make sure you are using the latest stable version of Docker. More information is available in [issue 358847](https://gitlab.com/gitlab-org/gitlab/-/issues/358847). + ## Lack of IPv6 support Due to the underlying [ZAProxy engine not supporting IPv6](https://github.com/zaproxy/zaproxy/issues/3705), DAST is unable to scan or crawl IPv6-based applications. diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index 1389db65713..25b4b705025 100644 --- a/doc/user/application_security/dast/index.md +++ b/doc/user/application_security/dast/index.md @@ -178,7 +178,8 @@ To enable DAST to run automatically, either: #### Include the DAST template -> This template was [updated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62597) to DAST_VERSION: 2 in GitLab 14.0. +> - This template was [updated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62597) to DAST_VERSION: 2 in GitLab 14.0. +> - This template was [updated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87183) to DAST_VERSION: 3 in GitLab 15.0. If you want to manually add DAST to your application, the DAST job is defined in a CI/CD template file. Updates to the template are provided with GitLab @@ -333,7 +334,7 @@ Vulnerability rules in an API scan are different than those in a normal website A new DAST API scanning engine is available in GitLab 13.12 and later. For more details, see [DAST API scanning engine](../dast_api). The new scanning engine supports REST, SOAP, GraphQL, and generic APIs using forms, XML, and JSON. Testing can be performed using OpenAPI, Postman Collections, and HTTP Archive (HAR) documents. -The target API instance’s base URL is provided by using the `DAST_API_TARGET_URL` variable or an `environment_url.txt` file. +The target API instance's base URL is provided by using the `DAST_API_TARGET_URL` variable or an `environment_url.txt` file. #### Specification format @@ -493,7 +494,7 @@ To perform a [full scan](#full-scan) on the listed paths, use the `DAST_FULL_SCA ### List URLs scanned When DAST completes scanning, the merge request page states the number of URLs scanned. -Click **View details** to view the web console output which includes the list of scanned URLs. +Select **View details** to view the web console output which includes the list of scanned URLs.  @@ -574,7 +575,7 @@ DAST scan with both configured exits with an error. By default, several rules are disabled because they either take a long time to run or frequently generate false positives. The complete list of disabled rules -can be found in [exclude_rules.yml](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/src/config/exclude_rules.yml). +can be found in [`exclude_rules.yml`](https://gitlab.com/gitlab-org/security-products/dast/-/blob/main/src/config/exclude_rules.yml). The lists for `DAST_EXCLUDE_RULES` and `DAST_ONLY_INCLUDE_RULES` **must** be enclosed in double quotes (`"`), otherwise they are interpreted as numeric values. @@ -737,7 +738,7 @@ by the application as correctly authenticated. Authentication supports single form logins, multi-step login forms, and authenticating to URLs outside of the configured target URL. WARNING: -**NEVER** run an authenticated scan against a production server. When an authenticated +**Never** run an authenticated scan against a production server. When an authenticated scan is run, it may perform *any* function that the authenticated user can. This includes actions like modifying and deleting data, submitting forms, and following links. Only run an authenticated scan against a test server. @@ -846,7 +847,7 @@ Many web applications show the user the login form in a pop-up (modal) window. For these applications, navigating to the form requires both: - A starting URL. -- A list of elements to click to display the modal window. +- A list of elements to select to display the modal window. When `DAST_BROWSER_PATH_TO_LOGIN_FORM` is present, like in this example: @@ -1327,7 +1328,7 @@ class DastWebsiteTargetView(View): ##### Node (with Express) example for on-demand scan Here's how you can add a -[custom header in Node (with Express)](http://expressjs.com/en/5x/api.html#res.append): +[custom header in Node (with Express)](https://expressjs.com/en/5x/api.html#res.append): ```javascript app.get('/dast-website-target', function(req, res) { @@ -1399,17 +1400,19 @@ and DAST site profiles are included in the [audit log](../../../administration/a ## Reports -The DAST tool outputs a report file in JSON format by default. However, this tool can also generate reports in -Markdown, HTML, and XML. For more information, see the [schema for DAST reports](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/dast-report-format.json). +The DAST tool outputs a `gl-dast-report.json` report file containing details of the scan and its results. +This file is included in the job's artifacts. JSON is the default format, but +you can output the report in Markdown, HTML, and XML formats. To specify an alternative +format, use a [CI/CD variable](#available-cicd-variables). You can also use a CI/CD variable +to configure the job to output the `gl-dast-debug-auth-report.html` file which helps when debugging +authentication issues. -### JSON +For details of the report's schema, see the [schema for DAST reports](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/dast-report-format.json). Example reports can be found in the +[DAST repository](https://gitlab.com/gitlab-org/security-products/dast/-/tree/main/test/end-to-end/expect). WARNING: -The JSON report artifacts are not a public API of DAST and their format is expected to change in the future. - -The DAST tool always emits a JSON report file called `gl-dast-report.json` and -sample reports can be found in the -[DAST repository](https://gitlab.com/gitlab-org/security-products/dast/-/tree/main/test/end-to-end/expect). +The JSON report artifacts are not a public API of DAST and their format is expected to change in the +future. ## Optimizing DAST |