CSRF & XSS

CSRF

Cross Site Request Forgery attack : 크로스 사이트 요청 위조 공격

사용자가 자신의 의지와는 무관하게 침입자가 의도한 행위를 서버에 요청하게 만드는 공격이다.

• 인증된 사용자가 웹 애플리케이션에 특정 요청을 보내도록 유도하는 공격 행위
• 생성된 요청이 사용자의 동의를 받았는지 확인할 수 없는 웹 애플리케이션의 CSRF 취약점을 이용
• 공격자의 요청이 사용자의 요청인 것처럼 속이는 공격 방식
• 사용자가 인증한 세션에서 웹 애플리케이션이 정상적인 요청과 비정상적인 요청을 구분하지 못하는 점을 악용
• 웹 애플리케이션이 사용자의 요청이 실제 사용자가 전송한 것인지 확인하지 않는 경우 발생

1. 침입자는 서버로 넘어가는 자금 전송에 대한 요청을 조작하려고 한다.

2. 침입자는 하이퍼링크에 자금 전송 요청에 대한 스크립트를 삽입하고 사이트에 로그인할 사람들에게 전송한다.

3. 사용자가 링크를 누르면, 의도치않게 서버로 자금 전송 요청을 보내게 된다.

4. 서버는 로그인된 사용자의 요청이기 때문에 정상적으로 인식하고 전송을 실행해 침입자에게 돈이 송금된다.

 

 

csrf의 2가지 조건

1. 사용자가 사이트에 로그인된 상태여야 하고,

2. 조작된 페이지에 방문(접속)해야 한다.

 

 

CSRF 공격 방식

• 데이터의 값을 변경
• 제품 구입, 계정 설정, 기록 삭제, 비밀번호 변경, 문자 전송 등
• 공격자는 자금 송금이나 로그인 정보 변경 등 원하는 요청을 위조한 후, 이메일이나 웹사이트에 요청이 삽입된 하이퍼링크를 심어 놓고, 사용자가 해당 하이퍼링크를 클릭하면 요청이 자동으로 전송되게끔 한다
• 사용자의 정보 탈취보다는 특정 작업을 무단으로 진행하기 위한 목적으로 이루어지는 경우가 많음
• 그렇다고 사용자 정보가 유출되지 않는건 아님 ㅜ 권한을 탈취당하게 되면 개인 정보가 그대로 노출되므로 다른 사이버 공격과 똑같음

 

 

CSRF 예시

• 웹 브라우저를 속여 사용자가 로그인한 애플리케이션에서 무단으로 특정 작업을 진행하는 방식으로 이루어진다. 예시를 위해 공격자가 사용자의 자금을 탈취하려는 상황을 생각해보자.

1. 공격자가 특정 은행의 계좌에서 공격자의 계좌로 천만 원을 송금하라는 요청을 위조한다.

2. 위조한 요청은 하이퍼링크에 삽입해 이메일로 전송하거나 웹사이트 자체에 삽입한다.

3. 사용자가 공격자가 생성한 이메일 하이퍼링크나 웹사이트 링크를 클릭하면 은행에 천만원을 송금하라는 요청이 전송된다.

 

 

CSRF가 왜 위험한가?

관리자 계정이 크로스 사이트 요청 위조 공격에 당하는 경우에는 공격자가 전체 서버 접근 권한을 탈취해 웹 애플리케이션과 API 등 서비스 전체를 마음대로 통제할 수 있기 때문에 위험하다.

 

 

CSRF 방지 방법 (사용자 관점)

1. 사용하지 않는 웹 애플리케이션 로그아웃하기

• 자동 로그아웃 기능을 활용하고 2단계 인증을 추가해 송금과 같이 중요한 요청은 반드시 직접 인증을 거치도록 설정하는 것이 좋다

2, 로그인 정보 안전하게 보관하기

• 여러 사이트에서 동일한 비밀번호를 사용하거나, 유추하기 쉬운 비밀번호 사용을 지양한다.

3. 브라우저에 비밀번호 저장하지 않기

4. 여러 웹사이트 동시에 사용하지 않기

• 여러 웹사이트를 동시에 사용하는 경우 현재 화면에 표시되지 않는 웹사이트에서 CSRF가 발생하고 있다는 사실을 알아차리지 못할 수도 있다. 따라서 필요한 웹사이트를 하나씩 사용하는 것이 좋으며, 웹사이트 사용이 끝난 후에는 로그아웃 후 다른 웹사이트를 사용하는 것이 좋다.

5. VPN 사용하기

• VPN을 사용하면 사용자 아이피를 가상 아이피로 대체해 보안을 강화할 수 있으며, 멀웨어와 바이러스를 방지해 CSRF 공격의 대상이 될 가능성을 낮출 수 있다.

 

 

CSRF 방지 방법(개발자 관점)

1. 요청 헤더(Request header)의 도메인과 일치하는지 refferer 속성 검증

• 같은 도메인에서의 요청이 아니면 차단한다.

2. CSRF Token 사용

• 랜덤한 UUID와 같은 임의의 난수를 세션에 저장해두고 해당 난수가 전달되지 않으면 요청을 거부

3. Security Token 사용

• 사용자 세션에 암호화된 값을 저장하고 사용자의 요청마다 해당 암호화된 값을 포함시켜 전송. 이후 서버에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청에 전달되는 토큰 값이 일치하는지 확인

4. CAPTCHA

• 기계는 인식할 수 없으나 사람은 쉽게 인식할 수 있는 텍스트, 이미지를 통해 사람과 기계를 구별하는 프로그램

 

 

XSS

• 웹사이트에서 의도치 않은 스크립트를 넣어서 실행시키는 기법
• 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 발생하며, 결과로 사용자는 의도치 않은 동작을 수행하거나 쿠키, 세션 등의 정보를 탈취당하게 된다. 사용자의 브라우저를 대상으로 한다는 점에서 CSRF와 동일하다.

1. Prepetrator (제 3의 침입자)는 사이트의 취약점을 찾는다.

2. 취약점을 찾아 세션 쿠키를 탈취하는 스크립트를 사이트에 삽입한다.

3. 사용자가 웹 사이트에 접근할 때마다 스크립트는 작동된다.

4. 작동된 스크립트를 통해 사용자의 세션 쿠키를 탈취한다.

 

 

XSS 대응 방안

1. 개인 정보같은 중요 정보는 쿠키 대신 서버에 저장한다.

2. 정보를 암호화한다.

3. httpOnly 옵션을 설정한다. (document.cookie를 이용해 쿠키에 직접 접근하라는 것을 방지)

4. Url encoding이나 문자열을 치환한다.

 

 

CSRF와 XSS 차이점

	XSS	CSRF
공격	인증된 세션 없이도 공격	사용자의 인증된 세션을 악용
원인	사용자가 특정 사이트를 신뢰	특정 사이트가 사용자를 신뢰
공격대상	사용자에서 스크립트가 실행	서버에서 스크립트가 실행
목적	사용자 PC에서 스크립트를 실행해 사용자의 정보를 탈취 => 쿠키, 세션 갈취, 웹사이트 변조	요청을 위조함으로써 사용자 몰래 송금과 제품 구입 등 특정 행위를 수행 => 권한 도용

 

 

 

 

한 줄 요약

XSS는 사용자가 특정 사이트를 신뢰하기 때문에 발생

CSRF는 특정 사이트가 사용자를 신뢰하기 때문에 발생

 

 

security를 사용해 로그인을 구현한 사람들이라면 FilterChain에 CSRF를 disable 해주었을 것이다.

 

왜 CSRF를 dsiable 하지 ??

 

spring security documentation에 non-browser clients 만을 위한 서비스라면 csrf를 disable 하여도 좋다고 한다.

이 이유는 rest api를 이용한 서버라면, session 기반 인증과는 다르게 stateless하기 때문에 서버에 인증정보를 보관하지 않는다. rest api에서 client는 권한이 필요한 요청을 하기 위해서는 요청에 필요한 인증 정보를(OAuth2, jwt 등)을 포함시켜야 한다. 따라서 서버에 인증정보를 저장하지 않기 때문에 굳이 불필요한 csrf 코드들을 작성할 필요가 없다. spring security에서는 기본적으로 csrf protection을 제공한다.

 

 

REFERENCE

크로스 사이트 요청 위조(CSRF)의 의미

 

XSS와 CSRF 차이점 및 대응 방안

 

[Spring]Spring security - CSRF란?, http.csrf().disable() ?