XSS, CSRF, SQL 삽입, 세션 탈취는 모두 웹 공격이지만 증거가 다르다.
입력이 어디에 들어갔는지, 어느 쪽에서 실행되는지, 쿠키와 토큰이
어떻게 움직였는지를 보면 정답과 방어책을 함께 고를 수 있다.
상황 지문입력이 어디에서 의미를 바꾸는가?문제의 payload가 쿼리, HTML, 자동 요청, 인증값 중 무엇에 닿는지
먼저 표시한다.
↓
DB 문법으로 해석SQL 삽입입력이 WHERE 조건이나 명령 일부가 되어 권한 밖 데이터에
접근한다.브라우저에서 실행XSS스크립트가 피해자 화면에서 실행되어 쿠키, DOM, 요청 흐름을
건드린다.쿠키가 자동 전송CSRF피해자 로그인 세션을 이용해 원치 않는 상태 변경 요청을
보낸다.인증값이 노출세션 탈취세션 ID나 토큰을 얻어 사용자인 척 요청을 재현한다.SQL 삽입은 쿼리 조립을 끊는다prepared statement와 입력 검증으로 문자열이 SQL 문법이 되지 않게
한다.XSS는 출력 위치를 보고 인코딩한다HTML, 속성, URL, 스크립트 문맥에 맞는 인코딩과 CSP를
적용한다.CSRF는 요청 의도를 증명한다CSRF 토큰, SameSite, 재인증으로 자동 쿠키 전송만으로는 처리되지
않게 한다.암호화는 모든 웹 공격의 직접 해답이 아니다HTTPS는 전송 도청을 줄이지만 취약한 쿼리 조립이나 출력 인코딩을
고치지 못한다.쿠키 속성은 공격마다 다르게 읽는다HttpOnly는 XSS 쿠키 탈취를 줄이고, SameSite는 CSRF 자동 요청을
줄인다.정답은 공격 경로를 직접 끊어야 한다범용 방화벽, 백업, 모니터링만으로 원인 입력 경로가 차단되는지
따져 본다.