인가와 XSS,CSRF 예시
| topics | 705 보안 |
| index | 이론 |
컴퓨터 과목에서 보안하면 쉽게 떠올일 수 있는 공격이 XSS,CSRF이다.
나 또한 이를 많이 들어봤고 외우기도 하였지만 오랜만에 둘의 차이를 물으면 항상 햇갈리다.
인가할 때를 가졍하고 예시를 들며 이야기해보려고 한다.
XSS
사이트에 악성 스크립트 삽입
trigger가 해커의 행동
<div>검색: <%= q %></div>
// 공격자
// if 전역 변수에 accesstoken할당
?q=<script> token = window.accesstoken ; fetch("대충 토큰으로 의도치않은요청")
// if cookiedo
?q=<script> token = document.cookie ; fetch("대충 토큰으로 의도치않은요청")
이런 식으로 escape처리를 하지 않고, 토큰을 일반적인 전역변수에 저장하거나, httponly를 하지 않으면 의도치 않은 요청이 갈 수 있다.
- fe개발자
- 값 검증을 명확히
- escape처리 : react 쓰면 {변수} 이것들 자동으로 escape된다
- 전역변수할당 자제
- be개발자
- 쿠키를 httponly로 전송
CSRF
해커의 조작으로 인해서 사용자의 의도치 않은 행동
trigger가 사용자
쿠키는 브라우저가 닫히기 전까지 유지됨 << 이를 이용하는 방법
이 때 이 링크가 어떤링크냐에 따라 어떤 방식으로 공격이 들어가고 방어가 가능한지 설명할 것임
a도메인 링크긴 한데 특정패턴이 있음
주소창 : a.com?user=admin,newPw=1234
- 배경
- 만약 데이터를 수정, 변경, 삭제 하는 요청이 post,update,delete로 되어있지 않고 get요청으로 처리됨
- 결과
- 해당 링크를 누르면 브라우저에서는 토큰과함 께 get요청이 일어남 > admin비번이 1234로변경
- 해결 방안
- 읽기말고는 GET을 쓰지 말고 적절한 메서드를 사용하자
위조 사이트임
a.com사이트인줄알았는데 알고보니 aa.com사이트임
주소창 : aa.com
- 배경
- ui도 같게 만들어 사용자는 a.com으로 생각하고 서비스를 이용
- 해커는 aa.com실행 시
a.com?user=admin,newPw=1234요청을 보내도록 함 - 해커는 { credentials: 'include'}를 이용해 교차출처임에도 토큰을 보내도록 설정
- 결과
- 사용자는 의도치 않게 비번을 바꿧다.
- 해결방안
- 쿠키 : samesite 허용안함
- none 하면안됨
- none : cross origin 허용
- lax(Get만허용) or strict(모두 거절)
- none 하면안됨
- origin, referer체크
- Access-Control-Request-* 확인
- 이에 위반된게 요청되면 preflight단계서 거절됨
- 쿠키 : samesite 허용안함