| 语言 | 消息 |
|---|---|
| de | Eine Anfrage wurde erkannt, die aus der Benutzereingabe `$REQUEST` gebildet wird. Das kann zu Server-Side-Request-Forgery-Schwachstellen (SSRF) führen und sensible Daten preisgeben. Lassen Sie nach Möglichkeit die Basisanfrage nicht aus Benutzereingaben entstehen, sondern behandeln Sie sie als Teil des Pfads oder eines Query-Parameters. Ist eine Benutzereingabe dafür unvermeidlich, folgen Sie den OWASP-Best Practices gegen Missbrauch, etwa mit einer Allowlist. |
| en | A request was found to be crafted from user-input `$REQUEST`. This can lead to Server-Side Request Forgery (SSRF) vulnerabilities, potentially exposing sensitive data. It is recommend where possible to not allow user-input to craft the base request, but to be treated as part of the path or query parameter. When user-input is necessary to craft the request, it is recommended to follow OWASP best practices to prevent abuse, including using an allowlist. |
| fr | Une requête construite à partir de l'entrée utilisateur `$REQUEST` a été détectée. Cela peut créer une vulnérabilité de falsification de requête côté serveur (SSRF) exposant des données sensibles. Dans la mesure du possible, n'autorisez pas l'entrée utilisateur à construire la requête de base et réservez-la au chemin ou aux paramètres de requête ; si c'est nécessaire, suivez les bonnes pratiques OWASP pour prévenir les abus, notamment via une liste blanche. |
| ja | ユーザー入力 `$REQUEST` から構築されたリクエストが検出されました。サーバーサイドリクエストフォージェリ（SSRF）の脆弱性につながったり、機密データが露出したりする恐れがあります。リクエストのベース URL をユーザー入力から構築することはできる限り避け、ユーザー入力はパスやクエリパラメーターへの利用にとどめてください。ユーザー入力がリクエストの構築に必須である場合は、OWASP のベストプラクティス（ホワイトリストを含む）に従い、悪用を防止してください。 |
| ko | 사용자 입력 `$REQUEST`로 구성된 요청이 발견되었습니다. 이는 서버 측 요청 위조(SSRF) 취약점을 일으켜 민감한 데이터가 노출될 수 있습니다. 가급적 요청 기본 주소를 사용자 입력으로 구성하지 말고, 사용자 입력은 경로나 쿼리 파라미터에만 포함시키는 것이 좋습니다. 사용자 입력이 반드시 요청 구성에 포함되어야 하는 경우에는 OWASP 모범 사례(허용 목록 포함)를 따라 악용을 방지하십시오. |
| ru | Обнаружен запрос, построенный из пользовательского ввода `$REQUEST`. Это может привести к SSRF (подделке серверных запросов) и раскрытию чувствительных данных. По возможности не позволяйте пользовательскому вводу формировать базу запроса — пусть он участвует только в пути или параметрах запроса; если ввод необходим, следуйте лучшим практикам OWASP, включая белые списки, чтобы предотвратить злоупотребление. |
| zh | 发现由用户输入 `$REQUEST` 构造的请求，可能导致服务端请求伪造（SSRF）漏洞、暴露敏感数据。建议尽量不允许用户输入构造请求基址，只让其参与路径或查询参数；当用户输入必须参与构造请求时，请遵循 OWASP 最佳实践（包括白名单）防止滥用。 |
| zh-Hant | 發現由使用者輸入 `$REQUEST` 建構的請求，可能導致伺服器端請求偽造（SSRF）漏洞、暴露敏感資料。建議儘量不允許使用者輸入建構請求基址，只讓其參與路徑或查詢參數；當使用者輸入必須參與建構請求時，請遵循 OWASP 最佳實務（包括白名單）防止濫用。 |
| 语言 | 名称 | 修复建议 |
|---|---|---|
| de | SSRF (Server-Side Request Forgery) | Prüfen Sie Ziel-URLs per Allowlist, blockieren Sie interne/Loopback-/Metadaten-Adressen und leiten Sie ausgehende Anfragen einheitlich über einen kontrollierten Proxy. |
| en | — | — |
| fr | Falsification de requête côté serveur (SSRF) | Validez les URL cibles par liste blanche, interdisez les adresses internes/loopback/métadonnées et faites sortir tout le trafic par un proxy contrôlé. |
| ja | SSRF（サーバーサイドリクエストフォージェリ） | 対象 URL はホワイトリストで検証し、内部ネットワーク/ループバック/メタデータアドレスを禁止して、外部への通信は制御されたプロキシ経由に統一してください。 |
| ko | SSRF(서버 측 요청 위조) | 대상 URL은 허용 목록으로 검증하고, 내부망/루프백/메타데이터 주소는 비활성화하며, 아웃바운드 통신은 통제된 프록시를 통해 일원화하십시오. |
| ru | SSRF (подделка серверных запросов) | Проверяйте целевой URL по белому списку, запрещайте внутренние, loopback- и адреса метаданных, выпускайте трафик через управляемый прокси. |
| zh | SSRF（服务端请求伪造） | 目标 URL 白名单校验，禁用内网/回环/元数据地址，统一经受控代理出网。 |
| zh-Hant | SSRF（伺服器端請求偽造） | 目標 URL 白名單驗證，停用內部網路/迴環/後設資料位址，統一經受控代理出網。 |