티스토리 뷰
웹 개발자로써 아주 기본적으로 알고 있어야할 간단한 웹 보안에 대해서 정리한다.
아래 소개하는 공격방법과 웹 취약점들은 당연히 실제 서비스를 대상으로 실습하면 안된다. (정보통신법 위반)
뭐 어차피 웬만한 서비스들은 해당 공격들에 대해서 방어책들이 구비되어 있을 것이다.
인증과 검증은 프론트에서도 수행하고 서버에서도 수행해서 더욱 보안을 강화한다.
# 클라이언트 사이드
[XSS (Cross-site scripting)]
자바스크립트를 활용한 악의적인 스크립트를 실행하는 공격 기법. 이를 통해 공격자는 사용자의 인증 정보를 탈취할 수 있다.
저장(Stored) XSS = 악성 스크립트를 취약한 웹페이지 내부에 저장해놓는 방식
반사(Reflect) XSS = 웹 브라우저 URL로 악성 스크립트를 전송하여 공격하는 방식
XSS 방어기법
1. 신뢰하지 못한 데이터가 보여질 경우 추가 검증 필요 ex. <>의 경우 스트링으로 변환해서 저장
2. AntiXSS, ESAPI등 보안 라이브러리를 이용
3. 웹 방화벽 사용
*여담으로 Cross-site scripting을 이니셜을 따면 CSS인데, 이는 웹 디자인에 사용되는 그 CSS랑 이름이 비슷해서 XSS로 명명되었다.
# 서버사이드
[CSRF (Cross-site request forgery)]
악의적인 웹 사이트를 방문한 경우, 사용자가 이전에 방문했던 사이트의 인증정보를 이용해서 요청을 보낼 수 있음
즉, 사용자의 정보로 공격자가 악의적인 요청을 보내는 기법.
쿠키와 세션을 통한 공격 기법이다.
그래서 CSRF 공격이 가능케 될려면 다음과 같은 전제 조건이 필요하다.
- 사용자가 보안이 취약한 서버로부터 이미 인증을 받는다.
- 쿠키 기반으로 서버 세션 정보를 획득할 수 있어야 한다.
- 공격자는 서버를 공격하기 위한 요청 방법에 대해 미리 파악하고 있어야 한다. (예상치 못한 파라미터가 있으면 공격 불가능)
위 조건이 만족되면 다음과 같은 스텝으로 공격이 진행된다.
- 사용자는 보안이 취약한 서버에 로그인
- 로그인 이후 세션정보를 사용자 브라우저 쿠키에 저장
- 공격자는 서버에 인증된 브라우저의 사용자가 악성 스크립트 페이지를 누르도록 유도 (가짜 메일, 게시판 등등)
- 사용자가 악성 스크립트가 작성된 페이지 접근시 쿠키에 저장된 세션값은 브라우저에의해 자동적으로 함께 서버로 요청
- 서버는 쿠키에 담긴 세션값을 통해 해당 요청이 인증된 사용자로부터 온 것으로 판단하고 처리
CSRF 방어기법
1. Referrer 확인
- HTTP 헤더에서 Referrer를 확인할 수 있는데, 요청을 보낸 사람과 호스트가 동일한지 비교한다.
2. CSRF 토큰 검증 - 세션에 추가 검증 토큰값을 저장, 체크
3. Double Submit Cookie 검증 - 쿠키가 두번 사용되었는지 체크
[SQL Injection]
사용자로 부터 악의적인 SQL문을 입력받아 의도와는 다르게 쿼리문이 수행되는 공격 기법
SQL Injection 방어기법
1. 사용자 입력을 받지 않는 static query로 SQL을 작성
2. 사용자 입력을 하나의 파라미터 형식으로 받음 (prepared SQL)
*즉, SQL을 수행하기전에 꼭 서버측에서 검증을 해야한다. (물론 클라이언트 측에서도 검증을 해야함)