# IG 資安研究報告（繁體中文，技術詳解版）
> 受眾：資安研究員、滲透測試員、Meta 工程團隊（僅授權、受控 staging 執行）。
> 注意：不含可執行攻擊程式碼或惡意 payload，示意程式僅供測試規格與流程參考。
---
## 1 前言
本文件提供 Instagram 的研究級技術分析，重點在：
* 描述可能攻擊向量及其影響。
* 提供可在受控環境重現的測試規格（repro spec）。
* 設計統計與工程化偵測方案。
* 保存測試證據與可追蹤流程。
這有助於 Meta 內部團隊快速理解、重現並修補安全漏洞。
---
## 2 攻擊向量（技術重點）
1. **Credential attacks**：
* Credential stuffing / password spraying / targeted brute-force。
* 使用測試帳號池，控制速率與 concurrency，收集 request/response 指紋。
2. **Account enumeration**：
* 利用 login、forgot-password、signup 等流程的回應差異或 timing side-channel 辨識帳號存在性。
3. **Session / Token 弱點**：
* token 生命週期、refresh rotation、cookie flags、SameSite、token binding。
4. **OAuth / third-party 濫用**：
* scope 過寬、缺乏 revocation、refresh token 可重複使用。
5. **API abuse**：
* 參數濫用、page/limit 濫走、debug endpoint 暴露。
6. **Phishing / 社交工程測試**：
* 在授權環境下評估使用者與平台防護，驗證訊息偵測與警示。
---
### Brute‑Force（深度分析：線上與離線、測試方法與偵測）
> 本節為針對 Brute‑Force（暴力破解）攻擊的研究級技術說明，含攻擊類型、攻擊者模型、實驗室測試設計、偵測指標、日誌範本與工程化防護建議。**不含可直接執行之惡意程式碼或可利用 payload。**
#### 一、定義與分類
* **線上 Brute‑Force（Online）**：直接對目標認證介面（web form / auth API / SSH 等）反覆送出認證嘗試，以找出有效密碼。通常受網路延遲、rate‑limit、帳號鎖定等限制。
* **離線 Brute‑Force（Offline）**：攻擊者已取得密碼雜湊（hash）或資料庫備份，於本地或雲端進行高速雜湊推測（GPU / FPGA 加速）。此類不受目標系統即時防護約束，但需對密碼雜湊種類與鹽值設計習性分析。
* **Credential Stuffing**：將已洩露的 email:password 清單套用到目標登入介面，屬於一種經濟高效的線上攻擊變體。
* **Password Spraying**：對大量帳號使用少量常見密碼（例如常見的季節性密碼），以避免單帳號鎖定機制。
* **Targeted Brute‑Force**：針對高價值帳號（管理員、付費用戶）進行深度字典或暴力嘗試，通常結合社會工程或先前的帳號情報。
#### 二、攻擊者模型與資源
* **資源**：外洩憑證市場（credential feeds）、proxy pool / cloud instance（IP rotation）、自動化工具（自研或商用）、GPU/ASIC 叢集（離線破解）。
* **能力**：分布式攻擊以逃避 IP 封鎖、使用 timing/fingerprint 分析來判定成功；具備處理大量回應與後處理（session persistence）。
#### 三、實驗室測試設計（給 Meta 執行的安全流程）
* **環境**：完全隔離的 staging，與 production 網路完全不通；mock services（SMS、email）與使用測試帳號池。
* **樣本設計**：建立由弱至強三類密碼的測試帳號（weak/medium/strong），每類 50–200 帳號；預先設定 baseline 行為指標（正常登入 latency、成功率）。
* **參數控制**：建議採用分階段 ramp：RPS = 0.1 → 0.5 → 1 → 5；Concurrency = 1..50；Max attempts per account = 5..100（視測試目的）。
* **節流與保護**：測試殼層應內建節流（token bucket）、指數 backoff、並在發現 service degradation 時自動執行 kill‑switch。
* **資料收集**：收集每次嘗試的 timestamp、request_id、client_ip、username_attempted (hash)、http_status、response_length、response_body_hash、latency_ms、server_instance_id。
#### 四、偵測指標（具體可量化）
* **單 IP 大量失敗**：在 10 分鐘內同一 IP 對 >N 個不同帳號產生失敗登入（N 例如 50）。
* **同密碼多帳號失敗**：大量帳號在近似時間窗使用相同密碼嘗試（password spraying/credential stuffing 特徵）。
* **成功後異常行為**：成功登入後 5 分鐘內出現高風險操作（改 email、提權、匯出資料）。
* **時間側信道**：成功／失敗回應平均 latency 顯著差異（使用統計檢定，p<0.01）。
* **來源分散**：短時間內相同或類似 user‑agent 在多個 ASN 出現大量請求。
#### 五、偵測規則範例（Pseudo‑rules，可直接用於 SIEM）
* 規則 1（credential stuffing suspicion）:
* if count(distinct username) by client_ip in last 10m > 50 and avg(http_status!=200) > 0.9 then alert HIGH
* 規則 2（password spraying fingerprint）:
* if count(distinct client_ip) by username in last 30m > 20 and same_password_pattern_used > threshold then alert MEDIUM
* 規則 3（post‑success anomalous activity）:
* if success_event and subsequent privileged_action within 5m then alert CRITICAL
#### 六、日誌欄位範本（取證級）
* `timestamp, request_id, client_ip, x_forwarded_for, asn, geoip_country, user_agent, username_hash, http_method, path, status_code, response_length, response_body_hash, latency_ms, server_instance_id, snapshot_id`
* **保存建議**：append‑only，至少保留 90 天，evidence 打包時須計算 SHA‑256 並以收件方公鑰加密。
#### 七、統計驗證方法（研究級分析）
* 對每種情境（exist / not_exist / locked / captcha）各收集 ≥50–100 筆樣本。
* 使用非參數檢定（Mann‑Whitney U）比較 latency 或 body_length；若要比較多組採用 Kruskal‑Wallis，並以 Bonferroni 校正多重比較。
* 以 ROC/PR 曲線評估偵測規則的 TPR/FPR，選擇最佳閾值以平衡誤報與漏報。
#### 八、防護與工程化建議（針對 Brute‑Force）
* 強制 MFA（優先 FIDO2 / TOTP；SMS 作為 fallback）。
* 在邊緣（CDN / API gateway）就實施 bot management、IP reputation、WAF 規則與 rate limiting。
* 在應用層實施 adaptive authentication：根據 device_fingerprint、geoip、behavioral risk 調整驗證強度。
* 線上檢查 against breached‑credentials feeds，在登入過程檢驗使用者密碼是否出現在洩露清單，並強制重設。
* 密碼儲存採用 Argon2id / bcrypt 並設定強成本參數；為離線攻擊降低風險。
#### 九、測試殼層 Pseudocode（針對 Brute‑Force 的抽象樣板）
```
# Pseudocode: Brute‑Force Test Harness (abstract, non‑executable)
config:
endpoint = "{STAGING_BASE_URL}/auth/login"
credential_list = [{TEST_USER_1}, {TEST_USER_2}, ...]
password_list = [{PW1}, {PW2}, ...] # controlled dictionary
concurrency = {CONCURRENCY}
rps = {REQUESTS_PER_SECOND}
max_attempts_per_account = {MAX_ATTEMPTS}
for user in credential_list parallel up to concurrency:
attempts = 0
for pw in password_list:
if attempts >= max_attempts_per_account: break
rate_limiter.wait() # respect rps
result = SEND_AUTH_REQUEST(endpoint, user, pw)
record_log(result)
if MATCH_SUCCESS(result):
record_success(user, pw)
break
attempts += 1
end for
end for
# Aggregate and export anonymized logs; trigger kill_switch on service degradation
```
#### 十、SIEM／Splunk 查詢範例（針對 Brute‑Force）
* Splunk (偽語句)：
* `index=auth_logs | stats dc(username) as users_attempted, count as attempts by client_ip | where users_attempted > 50 and attempts > 200`。
* ELK/KQL (偽語句)：
* `auth_logs | where status != 200 | summarize attempts=count(), unique_users=cardinality(username) by client_ip | where unique_users > 50`。
#### 十一、實驗倫理與合約化控制
* 測試前必須：明確 scope、授權名單、白名單/黑名單、最大併發/頻率限制、kill_switch 設定與通報程序。
* 所有測試產物（logs、artifacts）均需加密保存並在 retention 期滿後刪除，並保留刪除證明。
---
## 3 Repro Spec（YAML 範本）
* 欄位：`finding_id`、`summary`、`impact`、`preconditions`、`repro_steps`、`expected_response`、`actual_response_sample`、`metrics_to_capture`、`notes`。
* 建議 metrics：timestamp, request_id, client_ip, username_hash, http_status, response_length, latency_ms, response_body_hash。
* 這提供研究員在 staging 環境重現漏洞的完整規格。（YAML 範本）
* 欄位：`finding_id`、`summary`、`impact`、`preconditions`、`repro_steps`、`expected_response`、`actual_response_sample`、`metrics_to_capture`、`notes`。
* 建議 metrics：timestamp, request_id, client_ip, username_hash, http_status, response_length, latency_ms, response_body_hash。
* 這提供研究員在 staging 環境重現漏洞的完整規格。
---
## 4 Pseudocode Test Harness
* 目標：描述測試邏輯與控制流程。
* 核心流程：
1. 初始化 config（受控速率、並發、最大嘗試）。
2. 對每個帳號進行受控重試。
3. 記錄指紋（username hash、body hash、延遲）。
4. 匯總指標，若達到閾值則觸發 kill_switch 停止測試。
* 輸出成果：anonymized logs、metrics JSON、evidence archive（含 SHA256 校驗）。
---
## 5 執行說明（staging checklist）
* 必備：staging URL、snapshot ID、test account manifest、mock SMS/email、SIEM hooks、egress 控制、operator 聯絡。
* 流程：驗證 snapshot → 填入 placeholder → baseline 小量測試 → 受控 ramp → 監控 error率、latency、CPU、mem → 異常觸發 kill → 打包證據。
* 建議閾值：error_rate(5min)>5% 或 avg_latency > baseline*3 → 停止。
---
## 6 證據 SOP
* 欄位：timestamp, request_id, client_ip, x_forwarded_for, asn, geoip, user_agent, path, status_code, response_time_ms, response_body_hash, username_hash, server_id, snapshot_id。
* 匿名化：PII 用 HMAC/SHA256(salt)。
* 打包：tar.gz → SHA256 → 公鑰加密或 presigned S3 → audit record。
* 保存期：30 天，刪除需提供刪除證明與 hash。
---
## 7 偵測特徵（ML / 規則）
* Per-request：latency_ms、response_length、http_status、body_hash、set_cookie_flag。
* Aggregated：requests_per_min_by_ip、distinct_usernames_by_ip、distinct_ips_by_username、ua_count_by_ip。
* Fingerprint：device_change_rate、TLS JA3、inter_request_jitter。
* 風險分數示例：risk = w1*z(distinct_usernames_by_ip)+w2*z(failed_rate)+w3*ip_reputation。
---
## 8 SIEM / 查詢範例（伪語句）
* Splunk 類：`index=auth_logs | stats count BY client_ip, username_attempted | where count>100 AND http_status=401`。
* ES/KQL 類：`auth_logs | where http_status==401 | summarize failed_count=count() by client_ip | where failed_count>50`。
---
## 9 統計驗證
* 每 case ≥50 次樣本。
* latency 與 body_length 用 Mann‑Whitney U 或 Welch t-test，p<0.01。
* 多重比較用 Bonferroni 校正。
---
## 10 Rate-limit 與緩解
* Edge 採 token bucket，應用層用 leaky bucket 平滑。
* Adaptive throttle：risk_score 高時降 RPS，要求 step-up auth（CAPTCHA/MFA）。
* Progressive delay：delay=base*2^k，不用永久鎖定。
---
## 11 Token 與 OAuth 建議
* Access token 短時效（5–15 分鐘）；refresh token 旋轉並 blacklist 使用過的 jti。
* 強制 PKCE，考慮 token binding。
---
## 12 取證保存
* append-only 存儲（S3 Object Lock）。
* 每日 bundle 計算 hash，上傳 attestation service。
---
## 13 交付物
* `repro_spec_{ID}.yaml`、`pseudocode.txt`、`postman_env.json`（模板）、`staging_checklist.txt`、`anonymized_logs.csv.gpg`、`README_DELIVERY.txt`。
---
## 附錄：示意檔案包（範例交付：META-IG-2025-001）
> 以下為示意交付包內容，包含 `repro_spec`（YAML）、`pseudocode.txt`、`postman_env.json` 範本與 `evidence_instructions.txt`。所有內容均使用 `{PLACEHOLDER}`，僅供受控 lab 轉譯與執行。請不要在 public 環境執行。
### 交付檔案目錄（示意）
```
/META_DELIVERABLES/META-IG-2025-001/
|- repro_spec_META-IG-2025-001.yaml
|- pseudocode_META-IG-2025-001.txt
|- postman_env_META-IG-2025-001.json
|- evidence_instructions_META-IG-2025-001.txt
|- README_DELIVERY.txt
```
---
### 1) repro_spec_META-IG-2025-001.yaml（範例）
```yaml
finding_id: META-IG-2025-001
summary: "登入 endpoint 在存在/不存在帳號情況下回傳差異化訊息，導致帳號枚舉與 credential stuffing 風險"
impact: "攻擊者可透過回應指紋辨識有效帳號，進一步進行大規模 credential stuffing 或社交工程攻擊。"
preconditions:
- "staging_base_url: {STAGING_BASE_URL}"
- "test_accounts: provided in test manifest CSV"
- "logging_level: DEBUG"
- "mock_services: mock-sms, mock-email enabled"
repro_steps:
- step: 1
action: "對 POST {STAGING_BASE_URL}/auth/login 發送 request，body: {\"username\":\"{TEST_USER_EXIST}\",\"password\":\"wrongpass\"}"
capture: ["status_code","response_body_length","response_time_ms","response_body_hash"]
repeat: 50
- step: 2
action: "對 POST {STAGING_BASE_URL}/auth/login 發送 request，body: {\"username\":\"{TEST_USER_NOT_EXIST}\",\"password\":\"any\"}"
capture: ["status_code","response_body_length","response_time_ms","response_body_hash"]
repeat: 50
expected_response:
- "兩種情況應回傳相同或統一化的 HTTP 狀態與錯誤訊息，無法從回應內容或 timing 區分帳號是否存在。"
actual_response_sample:
- exist_case: "{\"error\":\"account_locked\"}"
- not_exist_case: "{\"error\":\"user_not_found\"}"
metrics_to_capture:
- timestamp
- request_id
- client_ip
- username_hash
- http_status
- response_length
- response_time_ms
- response_body_hash
notes:
- "建議每個 case 收集 50–100 筆樣本以做統計測試"
- "請在 staging 中執行，切勿對外網執行"
```
---
### 2) pseudocode_META-IG-2025-001.txt（範例）
```
PSEUDOCODE: META-IG-2025-001 Reproducer (abstract, non-executable)
CONFIG:
ENDPOINT = "{STAGING_BASE_URL}/auth/login"
EXIST_USER = "{TEST_USER_EXIST}"
NOT_EXIST_USER = "{TEST_USER_NOT_EXIST}"
RPS = {REQUESTS_PER_SECOND} # e.g., 0.1
SAMPLES = 50
FUNCTION run_sample(username, password, samples):
for i in 1..samples:
rate_limiter.wait(RPS)
resp = SEND_AUTH_REQUEST(ENDPOINT, username, password) # internal implementation
log_record = {
'ts': now_iso(),
'req_id': resp.req_id or gen_uuid(),
'client_ip': resp.local_ip,
'username_hash': HMAC_SHA256(username, LOCAL_SALT),
'http_status': resp.status,
'resp_len': len(resp.body),
'resp_hash': SHA256(resp.body),
'latency_ms': resp.latency_ms
}
append_log_sink(log_record)
end for
end function
# Run
run_sample(EXIST_USER, "wrongpass", SAMPLES)
run_sample(NOT_EXIST_USER, "any", SAMPLES)
# After run: aggregate logs, compute descriptive statistics, perform Mann-Whitney U test on latency and resp_len
# If p < 0.01 for either metric, flag response-fingerprint as statistically significant
```
---
### 3) postman_env_META-IG-2025-001.json（範例環境檔）
```json
{
"id": "env-meta-ig-2025-001",
"name": "META-IG-2025-001-staging",
"values": [
{ "key": "STAGING_BASE_URL", "value": "{STAGING_BASE_URL}", "enabled": true },
{ "key": "TEST_USER_EXIST", "value": "{TEST_USER_EXIST}", "enabled": true },
{ "key": "TEST_USER_NOT_EXIST", "value": "{TEST_USER_NOT_EXIST}", "enabled": true },
{ "key": "TEST_PASSWORD", "value": "{TEST_PASSWORD}", "enabled": true },
{ "key": "EXPERIMENT_ID", "value": "{EXPERIMENT_ID}", "enabled": true }
]
}
```
---
### 4) evidence_instructions_META-IG-2025-001.txt（使用指引）
```
EVIDENCE PACKAGING & DELIVERY INSTRUCTIONS (META-IG-2025-001)
1) Export anonymized logs to CSV with columns:
timestamp, request_id, client_ip, username_hash, http_status, response_length, response_time_ms, response_body_hash, server_instance_id
2) Compress and compute hash:
tar -czf evidence_META-IG-2025-001_{TIMESTAMP}.tar.gz /path/to/anonymized_logs.csv
sha256sum evidence_META-IG-2025-001_{TIMESTAMP}.tar.gz > evidence_META-IG-2025-001_{TIMESTAMP}.sha256
3) Encrypt using recipient public key (PGP) or upload to presigned S3 URL provided by Meta with single-IP whitelist.
4) Provide audit record to Tester containing: filename, sha256, upload_timestamp, uploader_identity, presigned_url_expiry
IMPORTANT: All steps above to be performed in safe internal network by authorized operator only. DO NOT transfer artifacts over public email or non-encrypted channels.
```
---
### README_DELIVERY.txt（示例說明）
```
README: META-IG-2025-001 Delivery Package
Contents:
- repro_spec_META-IG-2025-001.yaml (重現規格)
- pseudocode_META-IG-2025-001.txt (測試殼層抽象模版)
- postman_env_META-IG-2025-001.json (Postman 環境範本)
- evidence_instructions_META-IG-2025-001.txt (日誌打包與交付指引)
Notes:
- Replace all {PLACEHOLDER} values with internal staging values prior to execution.
- Execution must occur in Meta staging, by authorized operator.
- Ensure Evidence SOP and operator checklist are followed.
```
---
## 進一步補充：其他攻擊向量的深度技術分析
> 說明：以下章節為研究/測試級詳細說明，每一向量包含：定義分類、攻擊者模型、實驗室測試設計、偵測指標、日誌欄位範本、偵測規則（pseudo‑rules）、統計與驗證方法、以及非執行性 pseudocode 範本。**我不會提供任何可直接執行的攻擊程式碼或 payload。**
### 一、Account Enumeration（帳號枚舉）
* **定義**：透過回應差異或 timing 差異辨識系統中是否存在某個 identifier（email/username/phone）。
* **攻擊者模型**：具備大規模自動化請求能力，能收集回應時間、HTTP code、body 長度。可用 proxy pools 分散來源。
* **實驗室測試設計**：
* 建立 exist / not_exist 測試帳號清單，各 50–200 筆。
* 對 `/auth/forgot-password`、`/signup`、`/login` 等 endpoint 送出帶不同 identifier 的請求，收集 `response_time_ms`、`status_code`、`response_body_length`、`response_body_hash`。
* 樣本量：每 case ≥50 次。
* **偵測指標**：顯著的 response content 或 timing 差異、同一 IP 在短時間查詢大量 identifier。
* **日誌欄位**：與 Brute‑Force 相同，並增加 `endpoint` 與 `request_body_snippet`（去標識化）。
* **偵測 pseudo‑rules**： 若同一 IP 在 10 分鐘內對 >100 個不同 identifier 查詢且 response_body_hash 呈兩類集群 → alert。
* **統計方法**：使用 cluster analysis（K‑means）判斷回應集群；用 Mann‑Whitney 比較 latency 分布。
* **pseudocode（abstract）**：
```
for id in identifier_list:
for i in 1..N_samples:
resp = SEND_REQUEST(endpoint, body_with(id))
record(resp_time, status, body_hash)
aggregate_by_id()
compare_clusters(exist_cluster, not_exist_cluster)
```
---
### 二、Session Hijacking / Token Theft（會話劫持與 Token 盜用）
* **定義**：透過 XSS、token 泄露、不安全存放或不當 CORS 設定，獲取 session cookie 或 API token，進而冒充使用者。
* **攻擊者模型**：具備發送釣魚連結、發現 XSS 點或分析客戶端儲存機制能力，能接收外發請求或 C2。
* **實驗室測試設計**：
* 建立可注入 XSS 的測試頁面（在 staging），測試管理端在瀏覽器打開該頁時是否會將敏感 token 傳出。
* 模擬不同 cookie flag（HttpOnly/Secure/SameSite）配置下的行為差異。
* **偵測指標**：同一 token 在不同 UA/IP 被使用；短時間多點使用同一 access token；出現非預期的外部 egress 連線記錄。
* **日誌欄位**：`token_id (hashed)`, `first_seen`, `last_seen`, `use_count`, `ua`, `client_ip_sequence`。
* **偵測 pseudo‑rules**：若同一 token_hash 在 1 小時內被來自 >3 個不同 ASN 的 IP 使用 → alert。
* **pseudocode（abstract）**：
```
# simulate client-side token exposure (abstract)
open_admin_page()
inject_test_script_that_reads_token_and_issues_request_to_collector()
collector_records(token_hash, origin_ip, ua, timestamp)
analyze_token_usage(token_hash)
```
* **防護要點**：HttpOnly cookie、短期 token + rotation、CSP、輸入過濾、限制 token 使用地理或 UA 綁定。
---
### 三、OAuth / Third‑Party Abuse（OAuth 濫用）
* **定義**：授權流程或 third‑party app 被濫用，範圍包括 scope 過大、refresh token 未輪替、revocation 無效等。
* **攻擊者模型**：建立惡意第三方 app、誘導使用者授權、或取得 client_secret/refresh token。
* **實驗室測試設計**：
* 建立 test third‑party app，在 staging 流程中授權並檢視可存取的 API 行為。
* 測試 revocation endpoint 是否能即時廢止 access/refresh token。
* **偵測指標**：異常的 long‑lived refresh token 使用、third‑party client_id 在短時間內存取大量用戶資料。
* **日誌欄位**：`client_id`, `scope`, `grant_time`, `refresh_count`, `revoked_flag`。
* **偵測 pseudo‑rules**：若某 client_id 在 24 小時內對 >1000 個 user records 發出讀取請求 → alert。
* **pseudocode（abstract）**：
```
register_test_app(client_id)
authorize_app_for_test_users()
perform_api_calls_as_app()
monitor_scope_usage_and_refresh_patterns()
```
* **防護要點**：最小權限、短期 refresh token 與 rotation、明確授權 UI、revocation audit。
---
### 四、Phishing / Social Engineering（釣魚與社交工程）
* **定義**：誘導使用者泄露憑證或點擊惡意連結（email/DM/短信/語音）。
* **量化測試**：可在授權情況下進行受控 phishing campaign（告知與同意下），量化開啟率、點擊率、憑證提交率、回報率。
* **偵測指標**：高開啟/點擊行為集中於特定 campaign、同一 IP 在短時間內呈現大量點擊不同受測者的情形。
* **日誌欄位**：`campaign_id`, `recipient_hash`, `click_timestamp`, `clicked_url_hash`, `submitted_credentials_flag`。
* **偵測 pseudo‑rules**：若 campaign click_rate > baseline_tick and submitted_credentials_rate > threshold → require user education followup。
* **pseudocode（abstract）**：
```
send_phishing_simulation(campaign_id, test_recipient_list)
collect_clicks_and_submission_events()
compute_metrics_and_generate_report()
```
* **防護**：SPF/DKIM/DMARC、user training、link scanner、browser phishing protection、reporting mechanisms。
---
### 五、API Abuse / Parameter Tampering（API 濫用與參數操控）
* **定義**：利用未妥善驗證的 API 參數或未限制的 endpoint 取得超過預期的資料或造成行為濫用。
* **測試設計**：對 API 執行 fuzzing（在 staging）、試探極端參數（大量 limit）、並檢查是否有 debug endpoints 或過度資訊回傳。
* **偵測指標**：endpoint 被大量掃描、異常高的 limit 參數值出現、debug headers 或 stack traces 在回應中出現。
* **日誌欄位**：`api_key_hash`, `param_values`, `response_size`, `response_errors`。
* **偵測 pseudo‑rules**：若單一 api_key 在 1 小時內對同 endpoint 發出 >1000 個不同 param patterns → alert。
* **pseudocode（abstract）**：
```
for param_set in test_param_space:
resp = SEND_API_REQUEST(endpoint, param_set)
record(param_set, resp.status, resp.size, resp.body_hash)
analyze_for_overexposure_patterns()
```
* **防護**：token scope/quotas、input validation、WAF 規則、API gateway rate limiting。
---
### 六、Client‑side XSS / CSRF（前端攻擊可被用於憑證竊取）
* **定義**：XSS 可導致 token/cookie 被讀取（若不為 HttpOnly）；CSRF 可在使用者不知情下發起授權操作。
* **測試設計**：在 staging 注入測試 payload（non‑exploit 模式）驗證 input sanitization 與 CSP 設定；CSRF 測試檢查 state token 與 Referer/SameSite 設定。
* **偵測指標**：出現非預期 external requests 或被注入的腳本行為。
* **日誌欄位**：`referrer`, `origin`, `csrftoken_valid`, `csp_violations`。
* **偵測 pseudo‑rules**：若 CSP violation 與未知 origin 的 postMessage 事件同時出現 → alert。
* **pseudocode（abstract）**：
```
submit_payload_to_candidate_fields()
monitor_csp_violations_and_external_requests()
```
* **防護**：CSP、HttpOnly cookie、輸入輸出編碼、CSRF token 檢查。
---
### 七、SIM Swap / Telephony Attacks（電信層風險）
* **定義**：透過社工或電信商漏洞將目標電話號碼轉移到攻擊者控制之 SIM，繞過 SMS MFA。
* **測試設計**：與電信商協作做流程審查（不實際換卡），或在 lab 模擬 SMS gateway 的失敗/延遲情況來觀測系統行為。
* **偵測指標**：使用者報告無法收到 SMS、同一帳號在短時間內出現 number change requests、或同一號碼在不同 IMSI 上出現登入活動。
* **防護**：不要把 SMS 作為唯一 MFA、提供 carrier‑level pin、鼓勵使用 Authenticator/FIDO。
---
總結
本文件為 Instagram 安全研究與滲透測試交付包示意，包含兩個層級內容：
一般使用者資安科普
介紹 IG 常見攻擊方式（釣魚、社交工程、弱密碼、SIM swap 等）與簡單防護建議，方便非技術背景使用者理解。
研究級攻擊向量分析（滲透測試專用）
各攻擊向量包括：Brute‑Force、Account Enumeration、Session/Token 竊取、OAuth 濫用、Phishing、API 濫用、XSS/CSRF、SIM Swap 等。
每個向量均提供：攻擊者模型、實驗室測試設計、偵測指標、日誌欄位範例、偵測 pseudo‑rules、統計與驗證方法、以及非執行性 pseudocode / curl / Postman 示意模板。
注意：示意程式碼或模板僅作為 Meta 內部 staging 參考，不可在公網執行。
---
## 免責聲明（Disclaimer）
用途限制與授權要求
本文件所載之技術分析、重現規格、示意模板與 pseudocode 僅供已獲授權之安全研究、滲透測試與修補驗證使用。任何未經明確書面授權之測試、執行或重複本文件中所述流程，可能違反法律或造成服務中斷與資安風險，使用者需自行承擔法律與實務後果。
不可執行與不可分發
本文件不包含、亦不提供任何可直接在公網或 production 上執行的惡意程式碼、payload、或完整 PoC。所有示意指令／程式片段均以 {PLACEHOLDER} 標示，僅為工程內部參考。嚴禁將本文件內容轉化為可攻擊外部系統之工具或散佈至未授權第三方。
執行環境要求
任何依本文件進行之測試必須：
在受控之隔離 staging / lab 環境執行；
由雙方事先同意之授權人員（operator）操作；
設定明確的速率限制、kill‑switch 與監控；
完成事前 risk assessment 並備妥回滾與通報計畫。
證據處理與保密
交付之日誌、artifact 與證據須依雙方協議進行匿名化、加密、與受控傳輸（例如 PGP 或 presigned S3 + IP 白名單）。交付後之保存期限、下載紀錄與刪除證明亦應在合約中明確規範。
責任限制
本文件作者/提供者不對任何因依據本文件內容在未授權或不當環境下執行所致之直接或間接損害負責。對於因使用本文件導致之系統中斷、資料遺失、第三方損害或法律責任，概不負責。若需進一步法律擔保或保險條款（例如 cyber insurance），請於合約中明確約定。
合規與法律建議
本文件不構成法律意見。若測試牽涉跨境資料、個資處理或高風險操作，建議同時諮詢公司法務或外部律師以確保合規性。
關於提供可執行 PoC 的流程
若對方（例如平台方）要求交付可執行 PoC，應先簽署附加協議（NDA/Access Agreement），並明確指定：接收者名單、執行環境、保存期限、稽核與下載記錄機制、責任歸屬與保險要求。本文件作者不會直接提供或上傳可執行攻擊程式碼，僅提供受控交付流程與指引。
Sign in with Wallet
Connect another wallet