Skip to content
代码片段 群组 项目
未验证 提交 56ea1764 编辑于 作者: Russell Dickenson's avatar Russell Dickenson 提交者： GitLab
浏览文件

DAST add redirects

上级 fa65f99a
No related branches found
No related tags found
无相关合并请求
展开全部 隐藏空白变更内容
行内 左右并排
显示
有 308 个添加 和 1001 个删除
doc/user/application_security/breach_and_attack_simulation/index.md
+ 3
− 3
浏览文件 @ 56ea1764
......@@ -85,7 +85,7 @@ To maintain a separate DAST job while testing the BAS extended DAST image:
To enable Breach and Attack Simulation features inside of an existing DAST job:
1. Follow the steps in [Create a DAST CI/CD job](../dast/browser_based.md#create-a-dast-cicd-job).
1. Follow the steps in [Create a DAST CI/CD job](../dast/browser/configuration/enabling_the_analyzer.md#create-a-dast-cicd-job).
1. Extend DAST to using the [extends](../../../ci/yaml/yaml_optimization.md#use-extends-to-reuse-configuration-sections) keyword to your DAST job's configuration:
......@@ -111,7 +111,7 @@ As with all projects, the items mentioned on this page are subject to change or
The development, release, and timing of any products, features, or functionality remain at the
sole discretion of GitLab Inc.
Perform Out-of-Band Application Security Testing (OAST) for certain [active checks](../dast/checks/index.md#active-checks).
Perform Out-of-Band Application Security Testing (OAST) for certain [active checks](../dast/browser/checks/index.md#active-checks).
1. Extend the `.dast_with_bas_using_services` job configuration using the [extends](../../../ci/yaml/yaml_optimization.md#use-extends-to-reuse-configuration-sections) keyword:
......@@ -141,7 +141,7 @@ Perform Out-of-Band Application Security Testing (OAST) for certain [active chec
You can also manually enable callback attacks by making sure to:
1. Set the `DAST_FF_ENABLE_BAS` [CI/CD variable](../dast/browser_based.md#available-cicd-variables) to `true`.
1. Set the `DAST_FF_ENABLE_BAS` [CI/CD variable](../dast/browser/configuration/variables.md) to `true`.
1. Enable both the application being tested and callback service container using [services](../../../ci/services/index.md).
1. Enable container-to-container networking [making the callback service accessible](../../../ci/services/index.md#connecting-services) in the job.
1. Set `DAST_BROWSER_CALLBACK` to include `Address:$YOUR_CALLBACK_URL` key/value pair where the callback service is accessible to the Runner/DAST container.
doc/user/application_security/dast/browser/checks/1336.1.md 0 → 100644
+ 32
− 0
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Server-Side Template Injection
## Description
The application is vulnerable to Server-Side Template Injection (SSTI), which enables attackers to
manipulate templates on the server side. This vulnerability arises when untrusted user input is
directly used in server-side templates without adequate sanitization. Attackers can exploit this
weakness to inject and execute arbitrary code in templates, potentially compromising the
system's integrity and confidentiality.
## Remediation
User-controlled data should always have special elements neutralized when used as part of
constructing Expression Language statements. Consult the documentation for the template
system in use on how properly neutralize user-controlled data.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 1336.1 | false | 1336 | Active | high |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/1336.html)
- [Testing for Server-side Template Injection](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-side_Template_Injection)
doc/user/application_security/dast/browser/checks/16.11.md 0 → 100644
+ 40
− 0
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# TRACE HTTP method enabled
## Description
The debug TRACE method was found to be enabled on the target web server. This
HTTP method reflects HTTP request data back to the user in a response. In some circumstances
this information may include sensitive data that is applied by intermediary proxies.
## Remediation
The TRACE HTTP method is for debugging only and should not be enabled on production
sites.
For Apache based web servers, ensure the `TraceEnable` directive is either removed or set to
`off`.
For Microsoft Servers, remove the registry parameter named "EnableTraceMethod" found in the below
registry key:
- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters`
For all other server types, consult your product's documentation on how to disable the TRACE method.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.11 | false | 16 | Active | high |
## Links
- [RFC](https://datatracker.ietf.org/doc/html/rfc9110.html#section-9.3.8)
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [Apache TraceEnable](https://httpd.apache.org/docs/2.4/mod/core.html#traceenable)
doc/user/application_security/dast/browser/checks/74.1.md 0 → 100644
+ 31
− 0
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# XSLT Injection
## Description
It is possible to supply an XSL template to a server-side XSLT processor. XSLT processors can
be abused to read or write files, initiate outbound connections, and in some cases execute
arbitrary code.
## Remediation
Applications should never accept user-supplied style sheets. XSLT processors are not built to
handle potentially malicious stylesheet files. However, some processors do implement or offer
security features which may be available. Consult the documentation for the XSLT processor
used by the target application for security guidelines and hardening steps. It is recommended
that all XML parsers and processors at the very least disable external entity resolution.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 74.1 | false | 74 | Active | high |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/74.html)
doc/user/application_security/dast/browser/checks/78.1.md 0 → 100644
+ 44
− 0
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# OS Command Injection
## Description
It is possible to execute arbitrary OS commands on the target application server.
OS Command Injection is a critical vulnerability that can lead to a full system
compromise.
## Remediation
User input should never be used in constructing commands or command arguments
to functions which execute OS commands. This includes filenames supplied by
user uploads or downloads.
Ensure your application does not:
- Use user-supplied information in the process name to execute.
- Use user-supplied information in an OS command execution function which does
not escape shell meta-characters.
- Use user-supplied information in arguments to OS commands.
The application should have a hardcoded set of arguments that are to be passed
to OS commands. If filenames are being passed to these functions, it is
recommended that a hash of the filename be used instead, or some other unique
identifier. It is strongly recommended that a native library that implements
the same functionality be used instead of using OS system commands due to the
risk of unknown attacks against third party commands.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 78.1 | false | 78 | Active | high |
## Links
- [OWASP](https://owasp.org/www-community/attacks/Command_Injection)
- [CWE](https://cwe.mitre.org/data/definitions/78.html)
doc/user/application_security/dast/browser/checks/918.1.md 0 → 100644
+ 33
− 0
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Server-Side Request Forgery
## Description
The application is susceptible to Server-Side Request Forgery (SSRF), a high-risk vulnerability
that allows attackers to make unauthorized requests to internal and external resources. This
vulnerability arises when user-controlled input is not properly validated or sanitized before
being used in requests to resources, enabling attackers to manipulate these requests for
malicious purposes.
## Remediation
Avoid using user-supplied data for constructing requests. If there is a business need for this,
consider an allowlist approach and/or block requests to internal resources using firewall
rules or a robust request library with anti-SSRF support.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 918.1 | false | 918 | Active | high |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/918.html)
- [OWASP](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)
- [Server-Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)
doc/user/application_security/dast/browser/checks/98.1.md 0 → 100644
+ 34
− 0
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# PHP Remote File Inclusion
## Description
The server is vulnerable to PHP Remote File Inclusion (RFI), which enables attackers to load
remote files and have them executed as PHP scripts on the server side. This vulnerability occurs
when untrusted user input is directly used in script inclusion without proper validation. Attackers
can leverage this vulnerability to include and execute arbitrary remote files, potentially
compromising the system's integrity and confidentiality.
## Remediation
Avoid using user-controlled data directly in `include` and `require` statements and instead consider
an allow-list approach for dynamically including scripts.
If possible, also consider setting `allow_url_include=Off` in the server's PHP configuration to
ensure URLs cannot be used in `include` and `require` statements.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 98.1 | false | 98 | Active | high |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/98.html)
- [File inclusion Vulnerability - Wikipedia](https://en.wikipedia.org/wiki/File_inclusion_vulnerability)
doc/user/application_security/dast/browser_based_troubleshooting.md
+ 7
− 300
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: 'browser/troubleshooting.md'
remove_date: '2024-05-16'
---
# Troubleshooting DAST browser-based analyzer
This document was moved to [another location](browser/troubleshooting.md).
DETAILS:
**Tier:** Ultimate
**Offering:** SaaS, Self-managed
The following troubleshooting scenarios have been collected from customer support cases. If you
experience a problem not addressed here, or the information here does not fix your problem, create a
support ticket. For more details, see the [GitLab Support](https://about.gitlab.com/support/) page.
## When something goes wrong
When something goes wrong with a DAST scan, if you have a particular error message then check [known problems](#known-problems).
Otherwise, try to discover the problem by answering the following questions:
- [What is the expected outcome?](#what-is-the-expected-outcome)
- [Is the outcome achievable by a human?](#is-the-outcome-achievable-by-a-human)
- [Any reason why DAST would not work?](#any-reason-why-dast-would-not-work)
- [How does your application work?](#how-does-your-application-work)
- [What is DAST doing?](#what-is-dast-doing)
### What is the expected outcome?
Many users who encounter issues with a DAST scan have a good high-level idea of what they think the scanner should be doing. For example,
it's not scanning particular pages, or it's not selecting a button on the page.
As much as possible, try to isolate the problem to help narrow the search for a solution. For example, take the situation where DAST isn't scanning a particular page.
From where should DAST have found the page? What path did it take to navigate there? Were there elements on the referring page that DAST should have selected, but did not?
### Is the outcome achievable by a human?
DAST cannot scan an application if a human cannot manually traverse the application.
Knowing the outcome you expect, try to replicate it manually using a browser on your machine. For example:
- Open a new incognito/private browser window.
- Open Developer Tools. Keep an eye on the console for error messages.
- In Chrome: `View -> Developer -> Developer Tools`.
- In Firefox: `Tools -> Browser Tools -> Web Developer Tools`.
- If authenticating:
- Navigate to the `DAST_AUTH_URL`.
- Type in the `DAST_USERNAME` in the `DAST_USERNAME_FIELD`.
- Type in the `DAST_PASSWORD` in the `DAST_PASSWORD_FIELD`.
- Select the `DAST_SUBMIT_FIELD`.
- Select links and fill in forms. Navigate to the pages that aren't scanning correctly.
- Observe how your application behaves. Notice if there is anything that might cause problems for an automated scanner.
### Any reason why DAST would not work?
DAST cannot scan correctly when:
- There is a CAPTCHA. Turn these off in the testing environment for the application being scanned.
- It does not have access to the target application. Ensure the GitLab Runner can access the application using the URLs used in the DAST configuration.
### How does your application work?
Understanding how your application works is vital to figuring out why a DAST scan isn't working. For example, the following situations
may require additional configuration settings.
- Is there a popup modal that hides elements?
- Does a loaded page change dramatically after a certain period of time?
- Is the application especially slow or fast to load?
- Is the target application jerky while loading?
- Does the application work differently based on the client's location?
- Is the application a single-page application?
- Does the application submit HTML forms, or does it use JavaScript and AJAX?
- Does the application use websockets?
- Does the application use a specific web framework?
- Does selecting buttons run JavaScript before continuing the form submit? Is it fast, slow?
- Is it possible DAST could be selecting or searching for elements before either the element or page is ready?
### What is DAST doing?
Logging remains the best way to understand what DAST is doing:
- [Browser-based analyzer logging](#browser-based-analyzer-logging), useful for understanding what the analyzer is doing.
- [Chromium DevTools logging](#chromium-devtools-logging), useful to inspect the communication between DAST and Chromium.
- [Chromium Logs](#chromium-logs), useful for logging errors when Chromium crashes unexpectedly.
## Browser-based analyzer logging
The analyzer log is one of the most useful tools to help diagnose problems with a scan. Different parts of the analyzer can be logged at different levels.
### Log message format
Log messages have the format `[time] [log level] [log module] [message] [additional properties]`.
For example, the following log entry has level `INFO`, is part of the `CRAWL` log module, has the message `Crawled path` and the additional properties `nav_id` and `path`.
```txt
2021-04-21T00:34:04.000 INF CRAWL Crawled path nav_id=0cc7fd path="LoadURL [https://my.site.com:8090]"
```
### Log destination
Logs are sent either to file or to console (the CI/CD job log). You can configure each destination to accept different logs using
the environment variables `DAST_BROWSER_LOG` for console logs and `DAST_BROWSER_FILE_LOG` for file logs.
For example:
```yaml
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_BROWSER_SCAN: "true"
DAST_BROWSER_LOG: "auth:debug" # console log defaults to INFO level, logs AUTH module at DEBUG
DAST_BROWSER_FILE_LOG: "loglevel:debug,cache:warn" # file log defaults to DEBUG level, logs CACHE module at WARN
DAST_BROWSER_FILE_LOG_PATH: "$CI_PROJECT_DIR/dast-scan.log" # Save the file log in the project directory so it can be recognized as an artifact
artifacts:
paths:
- dast-scan.log
when: always
```
### Log levels
The log levels that can be configured are as follows:
| Log module | Component overview | More |
|-------------------------|--------------------------------------------------------------------------|----------------------------------|
| `TRACE` | Used for specific, often noisy inner workings of a feature. | |
| `DEBUG` | Describes the inner-workings of a feature. Used for diagnostic purposes. | |
| `INFO` | Describes the high level flow of the scan and the results. | Default level if none specified. |
| `WARN` | Describes an error situation where DAST recovers and continues the scan. | |
| `FATAL`/`ERROR`/`PANIC` | Describes unrecoverable errors prior to exit. | |
### Log modules
`LOGLEVEL` configures the default log level for the log destination. If any of the following modules are configured,
DAST uses the log level for that module in preference to the default log level.
The modules that can be configured for logging are as follows:
| Log module | Component overview |
|------------|---------------------------------------------------------------------------------------------------|
| `ACTIV` | Used for active attacks. |
| `AUTH` | Used for creating an authenticated scan. |
| `BPOOL` | The set of browsers that are leased out for crawling. |
| `BROWS` | Used for querying the state or page of the browser. |
| `CACHE` | Used for reporting on cache hit and miss for cached HTTP resources. |
| `CHROM` | Used to log Chrome DevTools messages. |
| `CONTA` | Used for the container that collects parts of HTTP requests and responses from DevTools messages. |
| `CRAWL` | Used for the core crawler algorithm. |
| `DATAB` | Used for persisting data to the internal database. |
| `LEASE` | Used to create browsers to add them to the browser pool. |
| `MAIN` | Used for the flow of the main event loop of the crawler. |
| `NAVDB` | Used for persistence mechanisms to store navigation entries. |
| `REGEX` | Used for recording performance statistics when running regular expressions. |
| `REPT` | Used for generating reports. |
| `STAT` | Used for general statistics while running the scan. |
| `VLDFN` | Used for loading and parsing vulnerability definitions. |
| `WEBGW` | Used to log messages sent to the target application when running active checks. |
### Example - log crawled paths
Set the log module `CRAWL` to `DEBUG` to log navigation paths found during the crawl phase of the scan. This is useful for understanding
if DAST is crawling your target application correctly.
```yaml
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_BROWSER_LOG: "crawl:debug"
```
For example, the following output shows that four anchor links we discovered during the crawl of the page at `https://example.com`.
```plaintext
2022-11-17T11:18:05.578 DBG CRAWL executing step nav_id=6ec647d8255c729160dd31cb124e6f89 path="LoadURL [https://example.com]" step=1
...
2022-11-17T11:18:11.900 DBG CRAWL found new navigations browser_id=2243909820020928961 nav_count=4 nav_id=6ec647d8255c729160dd31cb124e6f89 of=1 step=1
2022-11-17T11:18:11.901 DBG CRAWL adding navigation action="LeftClick [a href=/page1.html]" nav=bd458cc1fc2d7c6fb984464b6d968866 parent_nav=6ec647d8255c729160dd31cb124e6f89
2022-11-17T11:18:11.901 DBG CRAWL adding navigation action="LeftClick [a href=/page2.html]" nav=6dcb25f9f9ece3ee0071ac2e3166d8e6 parent_nav=6ec647d8255c729160dd31cb124e6f89
2022-11-17T11:18:11.901 DBG CRAWL adding navigation action="LeftClick [a href=/page3.html]" nav=89efbb0c6154d6c6d85a63b61a7cdc6f parent_nav=6ec647d8255c729160dd31cb124e6f89
2022-11-17T11:18:11.901 DBG CRAWL adding navigation action="LeftClick [a href=/page4.html]" nav=f29b4f4e0bdee70f5255de7fc080f04d parent_nav=6ec647d8255c729160dd31cb124e6f89
```
## Chromium DevTools logging
WARNING:
Logging DevTools messages is a security risk. The output contains secrets such as usernames, passwords and authentication tokens.
The output is uploaded to the GitLab server and may be visible in job logs.
The DAST Browser-based scanner orchestrates a Chromium browser using the [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/).
Logging DevTools messages helps provide transparency into what the browser is doing. For example, if selecting a button does not work, a DevTools message might show that the cause is a CORS error in a browser console log.
Logs that contain DevTools messages can be very large in size. For this reason, it should only be enabled on jobs with a short duration.
To log all DevTools messages, turn the `CHROM` log module to `trace` and configure logging levels. The following are examples of DevTools logs:
```plaintext
2022-12-05T06:27:24.280 TRC CHROM event received {"method":"Fetch.requestPaused","params":{"requestId":"interception-job-3.0","request":{"url":"http://auth-auto:8090/font-awesome.min.css","method":"GET","headers":{"Accept":"text/css,*/*;q=0.1","Referer":"http://auth-auto:8090/login.html","User-Agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/105.0.5195.102 Safari/537.36"},"initialPriority":"VeryHigh","referrerPolicy":"strict-origin-when-cross-origin"},"frameId":"A706468B01C2FFAA2EB6ED365FF95889","resourceType":"Stylesheet","networkId":"39.3"}} method=Fetch.requestPaused
2022-12-05T06:27:24.280 TRC CHROM request sent {"id":47,"method":"Fetch.continueRequest","params":{"requestId":"interception-job-3.0","headers":[{"name":"Accept","value":"text/css,*/*;q=0.1"},{"name":"Referer","value":"http://auth-auto:8090/login.html"},{"name":"User-Agent","value":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/105.0.5195.102 Safari/537.36"}]}} id=47 method=Fetch.continueRequest
2022-12-05T06:27:24.281 TRC CHROM response received {"id":47,"result":{}} id=47 method=Fetch.continueRequest
```
### Customizing DevTools log levels
Chrome DevTools requests, responses and events are namespaced by domain. DAST allows each domain and each domain with message to have different logging configuration.
The environment variable `DAST_BROWSER_DEVTOOLS_LOG` accepts a semi-colon separated list of logging configurations.
Logging configurations are declared using the structure `[domain/message]:[what-to-log][,truncate:[max-message-size]]`.
- `domain/message` references what is being logged.
- `Default` can be used as a value to represent all domains and messages.
- Can be a domain, for example, `Browser`, `CSS`, `Page`, `Network`.
- Can be a domain with a message, for example, `Network.responseReceived`.
- If multiple configurations apply, the most specific configuration is used.
- `what-to-log` references whether and what to log.
- `message` logs that a message was received and does not log the message content.
- `messageAndBody` logs the message with the message content. Recommended to be used with `truncate`.
- `suppress` does not log the message. Used to silence noisy domains and messages.
- `truncate` is an optional configuration to limit the size of the message printed.
### Example - log all DevTools messages
Used to log everything when you're not sure where to start.
```yaml
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_BROWSER_FILE_LOG: "chrom:trace"
DAST_BROWSER_FILE_LOG_PATH: "/zap/wrk/dast-scan.log"
DAST_BROWSER_DEVTOOLS_LOG: "Default:messageAndBody,truncate:2000"
artifacts:
paths:
- dast-scan.log
when: always
```
### Example - log HTTP messages
Useful for when a resource isn't loading correctly. HTTP message events are logged, as is the decision to continue or
fail the request. Any errors in the browser console are also logged.
```yaml
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_BROWSER_FILE_LOG: "chrom:trace"
DAST_BROWSER_FILE_LOG_PATH: "/zap/wrk/dast-scan.log"
DAST_BROWSER_DEVTOOLS_LOG: "Default:suppress;Fetch:messageAndBody,truncate:2000;Network:messageAndBody,truncate:2000;Log:messageAndBody,truncate:2000;Console:messageAndBody,truncate:2000"
artifacts:
paths:
- dast-scan.log
when: always
```
## Chromium logs
In the rare event that Chromium crashes, it can be helpful to write the Chromium process `STDOUT` and `STDERR` to log.
Setting the environment variable `DAST_BROWSER_LOG_CHROMIUM_OUTPUT` to `true` achieves this purpose.
DAST starts and stops many Chromium processes. DAST sends each process output to all log destinations with the log module `LEASE` and log level `INFO`.
For example:
```yaml
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_BROWSER_LOG_CHROMIUM_OUTPUT: "true"
```
## Known problems
### Logs contain `response body exceeds allowed size`
By default DAST processes HTTP requests where the HTTP response body is 10 MB or less. Otherwise, DAST blocks the response
which can cause scans to fail. This constraint is intended to reduce memory consumption during a scan.
An example log is as follows, where DAST blocked the JavaScript file found at `https://example.com/large.js` as it's size is greater than the limit:
```plaintext
2022-12-05T06:28:43.093 WRN BROWS response body exceeds allowed size allowed_size_bytes=1000000 browser_id=752944257619431212 nav_id=ae23afe2acbce2c537657a9112926f1a of=1 request_id=interception-job-2.0 response_size_bytes=9333408 step=1 url=https://example.com/large.js
2022-12-05T06:28:58.104 WRN CONTA request failed, attempting to continue scan error=net::ERR_BLOCKED_BY_RESPONSE index=0 requestID=38.2 url=https://example.com/large.js
```
This can be changed using the configuration `DAST_MAX_RESPONSE_SIZE_MB`. For example,
```yaml
include:
- template: DAST.gitlab-ci.yml
dast:
variables:
DAST_MAX_RESPONSE_SIZE_MB: "25"
```
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/1004.1.md
+ 7
− 37
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/1004.1.md'
remove_date: '2024-05-16'
---
# Sensitive cookie without HttpOnly attribute
This document was moved to [another location](../browser/checks/798.9.md).
## Description
The 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 should have the `HttpOnly` attribute
set.
## Remediation
Most web application frameworks allow configuring how cookies are sent to user-agents. Consult your framework's
documentation for more information on how to enable various security directives when assigning cookies to clients.
If the application is assigning cookies via writing to the response headers directly, ensure all responses include
the `HttpOnly` attribute. By enabling this protection, the application is able to mitigate the impact of
certain Cross-Site Scripting (XSS) attacks.
Example:
```http
Set-Cookie: {cookie_name}=<random secure value>; HttpOnly
```
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 1004.1 | false | 1004 | Passive | Low |
## Links
- [OWASP](https://owasp.org/www-community/HttpOnly)
- [CWE](https://cwe.mitre.org/data/definitions/1004.html)
- [Mozilla MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/113.1.md
+ 7
− 23
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/113.1.md'
remove_date: '2024-05-16'
---
# Improper Neutralization of CRLF Sequences in HTTP Headers
This document was moved to [another location](../browser/checks/113.1.md).
## Description
By inserting Carriage Return / Line Feed (CRLF) characters, malicious users could potentially inject arbitrary data into HTTP responses. By modifying HTTP responses, attackers could conduct cross-site scripting or cache poisoning attacks against other users of the system.
## Remediation
User input should never be used in constructing HTTP header responses without some form
of validation against newlines. This includes URLs supplied by the user for HTTP redirects.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 113.1 | false | 113 | Active | high |
## Links
- [OWASP](https://owasp.org/www-community/attacks/HTTP_Response_Splitting)
- [CWE](https://cwe.mitre.org/data/definitions/113.html)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/1336.1.md
+ 7
− 28
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/1336.1.md'
remove_date: '2024-05-16'
---
# Server-Side Template Injection
This document was moved to [another location](../browser/checks/1336.1.md).
## Description
The application is vulnerable to Server-Side Template Injection (SSTI), which enables attackers to
manipulate templates on the server side. This vulnerability arises when untrusted user input is
directly used in server-side templates without adequate sanitization. Attackers can exploit this
weakness to inject and execute arbitrary code in templates, potentially compromising the
system's integrity and confidentiality.
## Remediation
User-controlled data should always have special elements neutralized when used as part of
constructing Expression Language statements. Consult the documentation for the template
system in use on how properly neutralize user-controlled data.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 1336.1 | false | 1336 | Active | high |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/1336.html)
- [Testing for Server-side Template Injection](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server-side_Template_Injection)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.1.md
+ 7
− 29
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.1.md'
remove_date: '2024-05-16'
---
# Missing Content-Type header
This document was moved to [another location](../browser/checks/16.1.md).
## Description
The `Content-Type` header ensures that user agents correctly interpret the data being received. Without this header
being sent, the browser may misinterpret the data, leading to MIME confusion attacks. If an attacker were able
to upload files that are accessible by using a browser, they could upload files that may be interpreted as
HTML and so execute Cross-Site Scripting (XSS) attacks.
## Remediation
Ensure all resources return a proper `Content-Type` header that matches their format. As an example,
when returning JavaScript files, the response header should be: `Content-Type: application/javascript`
For added protection, we recommend that all resources return the `X-Content-Type-Options: nosniff`
header to disable user agents from mis-interpreting resources.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.1 | true | 16 | Passive | Low |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [Mozilla Blog on MIME Confusion attacks](https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.10.md
+ 7
− 26
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.10.md'
remove_date: '2024-05-16'
---
# Content-Security-Policy violations
This document was moved to [another location](../browser/checks/16.10.md).
## Description
A `Content-Security-Policy` (CSP) was identified on the target site that is reporting violations when
attempting to load the page in a browser. This may cause disruption to your users when attempting to visit the page.
## Remediation
Review the violations to determine if any action is necessary.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.10 | true | 16 | Passive | Info |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)
- [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
- [Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
- [CSP Evaluator](https://csp-evaluator.withgoogle.com/)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.11.md
+ 7
− 36
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.11.md'
remove_date: '2024-05-16'
---
# TRACE HTTP method enabled
This document was moved to [another location](../browser/checks/16.11.md).
## Description
The debug TRACE method was found to be enabled on the target web server. This
HTTP method reflects HTTP request data back to the user in a response. In some circumstances
this information may include sensitive data that is applied by intermediary proxies.
## Remediation
The TRACE HTTP method is for debugging only and should not be enabled on production
sites.
For Apache based web servers, ensure the `TraceEnable` directive is either removed or set to
`off`.
For Microsoft Servers, remove the registry parameter named "EnableTraceMethod" found in the below
registry key:
- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters`
For all other server types, consult your product's documentation on how to disable the TRACE method.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.11 | false | 16 | Active | high |
## Links
- [RFC](https://datatracker.ietf.org/doc/html/rfc9110.html#section-9.3.8)
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [Apache TraceEnable](https://httpd.apache.org/docs/2.4/mod/core.html#traceenable)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.2.md
+ 7
− 40
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.2.md'
remove_date: '2024-05-16'
---
# Server header exposes version information
This document was moved to [another location](../browser/checks/16.2.md).
## Description
The target website returns the `Server` header and version information of this website. By
exposing these values, attackers may attempt to identify if the target software is vulnerable to known
vulnerabilities, or catalog known sites running particular versions to exploit in the future when a
vulnerability is identified in the particular version.
## Remediation
We recommend that the version information be removed from the `Server` header.
Apache:
For Apache based web sites, set the `ServerTokens` to `Prod` in the `httpd.conf` configuration file.
NGINX:
For NGINX based websites, set the `server_tokens` configuration value to `off` in the `nginx.conf` file.
IIS:
For IIS based websites version 10 and above you can use the `removeServerHeader` element to the `requestFiltering`
section of the `Web.config` file.
For all other server types, consult your product's documentation on how to redact the version information from
the `Server` header.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.2 | true | 16 | Passive | Low |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [Apache ServerTokens](https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/)
- [NGINX `server_tokens`](https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens)
- [IIS 10 Remove Server Header](https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/#attributes)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.3.md
+ 7
− 31
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.3.md'
remove_date: '2024-05-16'
---
# X-Powered-By header exposes version information
This document was moved to [another location](../browser/checks/16.3.md).
## Description
The target website returns the `X-Powered-By` header and version information of this website. By
exposing these values, attackers may attempt to identify if the target software is vulnerable to known
vulnerabilities, or catalog known sites running particular versions to exploit in the future when a
vulnerability is identified in the particular version.
## Remediation
We recommend that the version information be removed from the `X-Powered-By` header.
PHP:
For PHP based web sites, set the `expose_php` option to `off` in the `php.ini` configuration file.
For all other server types, consult your product's documentation on how to redact the version
information from the `X-Powered-By` header.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.3 | true | 16 | Passive | Low |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [PHP `expose_php`](https://www.php.net/manual/en/ini.core.php#ini.expose-php)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.4.md
+ 7
− 24
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.4.md'
remove_date: '2024-05-16'
---
# X-Backend-Server header exposes server information
This document was moved to [another location](../browser/checks/16.4.md).
## Description
The target website returns the `X-Backend-Server` header which includes potentially internal/hidden IP addresses
or hostnames. By exposing these values, attackers may attempt to circumvent security proxies and access these
hosts directly.
## Remediation
Consult your proxy/load balancer documentation or provider on how to disable revealing the
`X-Backend-Server` header value.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.4 | true | 16 | Passive | Info |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.5.md
+ 7
− 26
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.5.md'
remove_date: '2024-05-16'
---
# AspNet header exposes version information
This document was moved to [another location](../browser/checks/16.5.md).
## Description
The target website returns AspNet headers and version information of this website. By
exposing these values attackers may attempt to identify if the target software is vulnerable to known
vulnerabilities, or catalog known sites running particular versions to exploit in the future when a
vulnerability is identified in the particular version.
## Remediation
To remove the `X-AspNet-Version` header set `<httpRuntime enableVersionHeader="false" />` in the `<system.Web>`
section of the `Web.config` file.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.5 | true | 16 | Passive | Low |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [IIS Remove Unwanted Headers](https://techcommunity.microsoft.com/t5/iis-support-blog/remove-unwanted-http-response-headers/ba-p/369710)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
doc/user/application_security/dast/checks/16.6.md
+ 7
− 33
浏览文件 @ 56ea1764
---
stage: Secure
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: '../browser/checks/16.6.md'
remove_date: '2024-05-16'
---
# AspNetMvc header exposes version information
This document was moved to [another location](../browser/checks/16.6.md).
## Description
The target website returns AspNet headers along with version information of this website. By
exposing these values attackers may attempt to identify if the target software is vulnerable to known
vulnerabilities. Or catalog known sites running particular versions to exploit in the future when a
vulnerability is identified in the particular version.
## Remediation
To remove the `X-AspNetMvc-Version` information set `MvcHandler.DisableMvcResponseHeader = true;` in the
`Global.asax.cs` file in the `Application_Start()` method.
```cs
protected void Application_Start()
{
MvcHandler.DisableMvcResponseHeader = true;
}
```
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:--------|:--------|:--------|:--------|
| 16.6 | true | 16 | Passive | Low |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/16.html)
- [IIS Remove Unwanted Headers](https://techcommunity.microsoft.com/t5/iis-support-blog/remove-unwanted-http-response-headers/ba-p/369710)
<!-- This redirect file can be deleted after 2024-05-16. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或