[면접 준비 - CS]XSS, CSRF, SQL Injection

목차

 

XSS, CSRF, SQL Injection은 웹 보안에서 가장 많이 발생하는 취약점들이다.

 

말을 바꾸면 좋지 않은 의도를 가진 사람이 해당 서비스나 서비스를 이용하는 사용자를 공격하는 방법들인데,

 

이 글에선 하나씩 개괄적으로 보고 그 방지책에 대해 알아본다.

 

XSS(Cross-Site Scripting)

 

XSS는 악성 스크립트를 삽입하여 해당 페이지를 요청하는 사용자의 브라우저에서 실행되도록 하는 방식이다.

 

이 공격은 주로 사용자의 개인정보가 담긴 쿠키나 세션을 하이재킹해 권한을 탈취하는 것을 목적으로 한다.

 

최악의 경우 탈취한 권한으로 사용자의 계좌에서 돈을 인출하는 상황도 발생할 수 있기 때문에,

 

XSS는 최악의 보안 위협으로 간주되고 있다.

 

이를 방지하기 위해서는 입/출력 값의 스크립트 태그 검증 및 이스케이핑, HTTP Only 설정, CSP, HTTPS사용,

 

주기적인 웹 보안 테스트 등이 중요하다.

 

이스케이핑: 문자열에 포함된 특수문자 혹은 예약어를 다른 문자열로 치환하는 작업(ex: ' → \')

 

HTTP Only: 쿠키를 브라우저-서버 사이에서만 사용하도록 제한하는 설정. JS를 통해 접근할 수 없다.

 

CSP: HTTP 헤더를 사용하여 브라우저가 로드하는 리소스가 허용하는 출처를 명시적으로 작성하는 방법.

 

CSRF(Cross-Site Request Forgery)

 

CSRF(Cross-Site Request Forgery)는 위조된 요청(링크)을 클릭하도록 유도해

 

사용자가 모르는 사이에 공격자가 의도한 행위를 실행하도록 하는 공격 기법이다.

 

이때 주로 원래 페이지와 비슷하게 만들어진 위조 페이지가 전송되며, 이를 눌러 접근 시

 

원래 플랫폼은 해당 요청이 사용자의 정상적인 요청이라 판단해 수행하게 된다.

 

당연하게도 금융 범죄에까지 사용될 수 있으며, 잘 알려진 취약점이다.

 

추가로 이를 방지하기 위해서는 CSRF 토큰 사용, SameSite쿠키 속성, Referer 검증 및 추가 검증이 필요하다.

 

• CSRF 토큰
  사용자의 세션에 CSRF 토큰을 저장한 뒤 모든 요청에 포함하도록 하는 방식. 
  공격자의 요청은 CSRF 토큰이 없기 때문에 서버에서 거부하게 된다.
• SameSite 쿠키 속성 사용
  쿠키 전송을 같은 사이트 내에서만 허용하는 속성.
  이를 통해 타 사이트에서 요청하는 CSRF 공격을 막을 수 있다.
• Referer 검증
  HTTP 요청 헤어 중 Referer 값을 검증하여 같은 사이트에서 온 요청인지 판단하는 방법.
  Referer 값은 쉽게 변조가 가능해 완전한 방어는 어려움.

 

SQL Injection

 

 

SQL Injection은 쉽게 말하면 사용자의 입력값을 조작해 서버에 쿼리를 날려 디비 자체를 공격하는 방식이다.

 

대부분의 웹 애플리케이션은 사용자가 입력한 데이터를 그대로 SQL 쿼리에 삽입하는데,

 

이때 해당 데이터에 디비에서 실행될 수 있는 SQL 문법을 포함하면 공격자는 디비 자체를 조작할 수 있다.

 

예를 들어 로그인 폼에서 "admin'--'"이라는 이름을 입력하면 아래와 같은 SQL문이 생성된다.

SELECT * FROM users WHERE username = 'admin'--' AND password = '입력한비밀번호';

이때 -- 이후의 구문은 주석처리가 되어 무시되기 때문에, 디비는 위 명령을 아래와 같이 해석한다.

SELECT * FROM users WHERE username = 'admin';

이렇게 되면 비밀번호 없이도 admin 계정으로 로그인할 수 있게 되는 것이다.

 

또한 비슷한 방법을 이용해 디비의 특정 데이터를 모두 삭제해 버린다거나 하는 일이 가능하기 때문에,

 

정상적인 서비스 이용을 위해선 반드시 막아야 하는 취약점이다.

 

SQL Injection을 방어하기 위해서는 가장 먼저 입력값 검증 및 이스케이프가 필요하다.

 

특수문자만 제거해 줘도 위와 같은 공격을 실행할 수가 없기 때문이다.

 

추가로 admin과 같이 디비에 바로 접근이 가능한 사용자에 대해서는 입력값 검증을 더욱 강화하는 방법이 있겠다.