製品: dgtlmoon/changedetection.io — v0.55.7
ファイル: changedetectionio/blueprint/settings/__init__.py, changedetectionio/forms.py
CWE: CWE-284 — 不適切なアクセス制御
CVSS 3.1: AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:L — 6.3 (中)
CNA: Turan Security · CVE レコード
changedetection.io の /settings 保存ハンドラは、更新辞書を
form.data['application'] から構築し、保存済みアプリケーション設定へ盲目的にマージする（
.update() 経由）。HTML チェックボックスはチェック時のみ、送信されたフォームデータに含まれるため、
セキュリティ上重要なチェックボックスフィールド（API キー要求を強制するフィールドなど）を単に
省略した細工された POST は、ハンドラレベルでは、ユーザーが UI でチェックを外したのと
区別できない。盲目的な .update() はその設定を静かにオフにしてしまう。
api_access_token_enabled（または同等の設定）を明示的に false に設定しないリクエストは —
POST ボディからそのフィールドを除外するだけ — 結果として、アプリケーション設定が
その保護が実質的に無効化された状態でマージされる。明示的な確認手順や、
「ユーザーがチェックを外した」と「フィールドが送信されなかった」を区別する監査シグナルはない。
/settings ページに認証する。/settings への POST を送信する。その際、
api_access_token_enabled フィールド（またはテスト対象の保護対象ブール設定）を
ボディから完全に省略し、無関係なフィールドのみを含める:
POST /settings HTTP/1.1
Content-Type: application/x-www-form-urlencoded
application-some_other_field=value
form.data['application'] → .update() マージは、
欠落したフィールドを明示的な「オフ」と同じように扱い、保護を静かに無効化する。
明示的なオフのシグナルが、ユーザー（またはリクエストをレビューする監査担当者）には見えないまま行われる。生のフォームデータからの盲目的な dict .update() は、「POST から欠落したフィールド」と
「明示的に false に設定されたフィールド」をチェックボックス設定において同一視する。HTML フォームは
未チェックのチェックボックスを送信することはないため、このパターンはセキュリティに
影響するあらゆる設定フィールドに対して安全ではない。
想定されるブール型設定フィールドを明示的に列挙し、欠落しているフィールドは
現在保存されている値（False ではなく）にデフォルト設定する。あるいは、「未送信」と
「未チェックとして送信された」を区別し、セキュリティ関連のトグルを盲目的な dict マージではなく
明示的に検証するフォームライブラリを使用する。