프론트엔드 보안: XSS와 CSRF, 그리고 방어 전략

"프론트엔드는 보안에서 안전하다?" 천만의 말씀입니다. 웹 애플리케이션의 로직이 클라이언트로 대거 이동하면서(SPA), 해커들의 공격 대상도 브라우저로 집중되고 있습니다. 가장 대표적인 두 가지 공격 유형인 XSS와 CSRF의 메커니즘을 이해하고, 이를 방어하는 방법을 알아봅시다.

1. XSS (Cross-Site Scripting)

사이트 간 스크립팅 공격입니다. 해커가 웹 페이지에 악성 스크립트를 삽입하여, 이를 열람하는 사용자의 정보를 탈취하거나 비정상적인 기능을 수행하게 만듭니다.

1.1 공격 방식

• Reflected XSS: 악성 스크립트가 포함된 URL을 사용자에게 클릭하게 유도합니다. (검색창 등에 스크립트 입력)
• Stored XSS: 게시판 글 내용이나 댓글에 스크립트를 저장하여, 해당 글을 보는 모든 사용자에게 스크립트를 실행시킵니다. "안녕하세요 <script>alert('hacked')</script>" 같은 내용이 DB에 저장되는 경우입니다.

1.2 방어 전략

• Input Sanitization: 사용자가 입력한 데이터는 무조건 의심해야 합니다. HTML 태그를 엔티티 코드로 변환(Escaping)해야 합니다. React는 기본적으로 렌더링 시 모든 데이터를 이스케이프 처리하므로 안전하지만, dangerouslySetInnerHTML을 사용할 때는 극도로 주의해야 합니다.
• CSP (Content Security Policy): 최후의 보루입니다. 서버 응답 헤더에 "이 도메인에서 불러온 스크립트만 실행해!"라고 명시하는 강력한 정책입니다.

2. CSRF (Cross-Site Request Forgery)

사이트 간 요청 위조입니다. 사용자가 로그인된 상태라는 점을 악용하여, 해커가 만든 피싱 사이트에서 사용자의 의지와 무관하게 공격 대상 서버로 요청(송금, 비밀번호 변경 등)을 보내게 만듭니다.

2.1 공격 방식

사용자가 은행 사이트에 로그인해 쿠키를 발급받은 상태에서, 해커가 보낸 메일의 링크(이미지 태그 등)를 클릭하면, 브라우저는 은행 사이트로 쿠키와 함께 요청을 전송합니다. 서버는 쿠키가 있으니 정당한 요청으로 착각하고 처리해버립니다.

2.2 방어 전략

• CSRF Token: 서버는 폼(Form)을 내려줄 때 임의의 난수(Token)를 같이 줍니다. 요청이 들어올 때 이 토큰이 있는지 검증합니다. 해커는 이 토큰을 알 수 없으므로 공격에 실패합니다.
• SameSite Cookie: 쿠키 설정에 SameSite=Strict 또는 Lax를 추가하면, 다른 사이트에서 일어난 요청에는 쿠키를 전송하지 않습니다. 최신 브라우저들은 이 설정이 기본값으로 되어가고 있습니다.

보안은 "나중에"가 없습니다. 개발 초기 단계부터 보안을 고려하는 Secure by Design 마인드가 필요합니다.