flawopen.com/크로스 사이트 스크립팅/Javascript

크로스 사이트 스크립팅 in Javascript

높음 CWE-79 Draft — pending review
Language: English Português (Brasil) Español Français Deutsch Русский 简体中文 日本語 हिन्दी 한국어 Bahasa Indonesia
쉬운 설명 (ELI5)

Imagine a guestbook where a visitor writes a note containing hidden script tags that execute in the browser of the next person who opens the page.

이 페이지의 주요 용어
output encoding
Converting special markup characters into safe entities so browsers display them as text rather than script.

발생 원인

Cross-site scripting happens when untrusted user input is inserted into the DOM without proper HTML output encoding.

실제 피해 사례

In 2005, the Samy XSS worm infected over 1 million user profiles on MySpace in under 20 hours, forcing the platform offline.

Documented historical AppSec case study.

취약한 코드 vs 수정된 코드

VULNERABLE
// comment text parsed directly as HTML
function renderComment(el, comment) {
  el.innerHTML =
    `

${comment}

`; }
FIXED
// comment text inserted as safe plain text
function renderComment(el, comment) {
  const p = document.createElement('p');
  p.textContent = comment;
  el.appendChild(p);
}

수정 방법이 동작하는 이유

textContent inserts values strictly as plain text, preventing the browser from parsing markup into executable elements.

언어별 주요 주의사항

React dangerouslySetInnerHTML

Explicitly disables React auto-escaping. Must be paired with DOMPurify if used.

흔한 오해

"Frameworks prevent all XSS"

Template escape hatches and direct DOM APIs (innerHTML, outerHTML) bypass framework defenses.

취약점 확인 방법

grep -rn "\.innerHTML\s*=" --include="*.js" --include="*.ts" . grep -rn "dangerouslySetInnerHTML" --include="*.jsx" --include="*.tsx" .
Configure ESLint rule react/no-danger and DOMPurify for cases where HTML formatting is genuinely required.

예방 체크리스트

자주 묻는 질문 (FAQ)

Does Content Security Policy (CSP) replace escaping?

No. CSP provides defense-in-depth, but output encoding remains the primary defense.

참고 자료

참고할 취약점: SQL Injection Command InjectionPath Traversal