chapter 8 - Attack & Defense (Web Security 2/2)

해당 게시글은 국민대학교 윤명근 교수님의
수업 내용을 바탕으로 작성하였습니다.

 

 

CSRF

[CWE-352] Cross-Site Request Forgery (CSRF)

 

웹사이트가 신뢰하는 사용자로부터 허가되지 않은 명령이 전송되는 악의적인 공격. 서버에서 발생하는 공격이다.

 

XSS가 사용자가 특정 사이트를 신뢰하기 때문에 발생하는 문제라면, CSRF는 특정 사이트가 사용자를 신뢰 하기 때문에 발생하는 문제이다. 

 

💡 CSRF의 2가지 조건
1. 사용자가 사이트에 로그인 상태여야 한다.
2. 사용자는 조작된 페이지에 방문(접속)해야 한다.

 

예시

[새로운 비밀번호로 변경 시 web server에서 기존 비밀번호를 요구하지 않는 경우]

 

공격자는 다음과 같은 request endpoint를 통해 비밀번호를 변경할 수 있는 걸 알게 된 상황이다.

/changepasswd.jsp?newpassword=[new_pwd]&confirmpassword=[new_pwd]

 

공격자는 XSS를 사용하여 다음 문자를 실행하게 한다.

( admin 계정에게 이미지를 클릭하도록 유도! (새 비밀번호로 바뀌게 됨) )

<img src="http://www.victim.com/changepasswd.jsp?newpassword=ATTACK&confirmpassword=ATTACK">

 

CSRF(Cross-Site Request Forgery)가 성공하기 위한 전제 조건

• 일반적으로 "Referer" 헤더를 확인하지 않는 사이트를 표적으로 삼아야 한다
• 대상 사이트에 폼 제출 기능이나 URL이 있어야 하며, 해당 폼이나 URL이 부작용(side effect)을 일으킬 수 있어야 한다
  (예: 돈을 송금하거나 피해자의 이메일 주소나 비밀번호를 변경하는 것).
• 폼이나 URL 입력값의 모든 적절한 값을 알아내야 한다. 만약 입력값 중 일부가 비밀 인증 값이나 공격자가 추측할 수 없는 ID라면 공격은 실패한다.
• 공격자는 피해자가 대상 사이트에 로그인된 상태에서 악성 코드가 포함된 웹 페이지를 방문하도록 유도해야 한다.
• 성공하기 드물지만 매우 강력한 공격이다.
  • 루트 사용자 권한(root user)이나 루트 PKI(Public Key Infrastructure) 등의 중요한 접근 권한 탈취 가능

 

대처방안

• 안전한 세션 관리
• HTTP Referer header 확인
• 쿠키 뿐만 아니라 GET, POST 파라미터에서도 인증 요구
• 인증 쿠키의 만료기한 설정.

---

SQL Injection

[CWE-89] SQL Query에 들어가는 데이터 살균 실패 공격

 

애플리케이션의 데이터베이스 계층에서 발생하는 보안 취약점을 악용하는 코드 삽입 기법

 

즉, 웹앱을 통해 SQL 명령을 악의적으로 전달하는 것

 

예시

 

위 브라우저에서 로그인에 대한 SQL Query가 다음과 같다고 하자

SELECT * FROM Members WHERE id='id' and password='password';

 

공격자가 만약 id 또는 pw에 ' or'1=1';-- 을 입력하면 어떻게 될까?

 

그럼 다음과 같은 SQL 문으로 바뀌게 될 것이다.

SELECT * FROM Members WHERE id='' or'1=1';-- ' and password='password';

SELECT * FROM Members WHERE id='admin' and password='' or'1=1'--;

 

즉, '1=1' 자체가 True를 의미하므로, 공격자는 모든 사용자 정보를 탈취하거나 관리자 계정 정보를 얻어올 수 있다.

 

MSSQL에서, --는 주석을 의미한다.

 

 

또한, ID 자리에 '; DROP TABLE members; -- 를 입력한다고 해보자.

 

SELECT * FROM users WHERE id = ''; DROP TABLE members; -- and password = '123123'

 

 

위 쿼리가 실행되며 members라는 Table이 전부 삭제가 된다.

 

 

대처 방안

• ID와 PW에 대한 유효성 검사. (id = 영어+숫자, PW=영어+숫자+8글자 이상!)
• 특별한 문자 (' " \ / 등) 에 대한 필터링.
• 에러 메시지를 노출하지 않는 것 (404 error를 보여주는 것도 보안적으로 취약! => 어떠한 정보도 주지 말 것!)
• DB 계정 특권을 낮추기.

---

Insecure Direct Object Reference

URL을 조작하여 정적 파일에 접근하는 것.

 

 

 

해당 url의 554를 555로 바꾸면 555화를 볼 수 있지 않을까? 라는 시도를 할 수 있을 것이다.

---

Access Control for Administration

admin page에 대한 접근은 제한되어야 한다. 따라서, 아래 이름들은 쉽게 예측될 수 있으므로 사용해선 안된다.

 

대처 방안

• 명백한 port 번호와 방화벽 접근 권한 설정.
• config 내 등록된 IP만 접근할 수 있게 웹서버의 접근 권한 설정하기.

---

Vulnerability Scanner

• 취약 점검 도구
• hardening CISCO router 또는 web server =>  brute force로 체킹 가능.

Data Leakage Prevention (DLP)

- 보안에 관련된 내용을 LLM과 같은 모델에 돌려선 안됨. (private LLM이 대두되고 있지만 성능이 좋지 않음 - tradeoff)

 

Black box와 White box 존재.