
해당 게시글은 국민대학교 윤명근 교수님의
수업 내용을 바탕으로 작성하였습니다.
WEB Overview
- TCP/IP 위에서 작동하는 Client/server model
- Stateless Protocol
HTTP Request Message (client -> server)

HTTP Response Message (server -> client)

URL (Uniform Resource Locators)

WEB Shell
첫 웹 공격 기법으로, MITRE(마이터 - 공격 표준 설정 단체) 에서 지정한 Common Weakness Enumeration이다.
웹 서버가 유저가 실행 파일을 업로드하는 것을 허용했을 때 발생하는 취약점이다.
예시
공격자가 업로드한 shell 파일(.sh)을 상대방이 다운 받으면 공격자는 설치된 디렉터리 위치를 알 수 있고, 실행 가능 권한이 생기게 됨.


한계
하지만 위 공격은 시도하기 까다로움 (위 조건을 모두 충족해야 공격 가능)
대처방안
- 파일 업로드를 제한해버리기.
- file extension type을 체크하기.
- 디렉터리의 실행 권한을 제거.
Cookie
접속할 때마다 sert-cookie 헤더를 통해 state 유지.
- 웹 서버에 의해 선택된 임의의 데이터 조각들이 브라우저로 전송된다.
- 브라우저는 해당 데이터를 변경하지 않고 다시 서버로 반환한다. 이를 통해 본래 상태를 가지지 않는(stateless) HTTP 트랜잭션에 상태(state, 즉 이전 이벤트의 기억)를 도입한다.
- 쿠키가 없으면 웹 페이지나 웹 페이지의 구성 요소를 각각 가져오는 작업은 서로 독립적인 이벤트로 간주된다.
Basic Operation
1. browser가 web page에 요청을 보낸다.
2. server는 페이지와 쿠키를 전송한다.

3. 브라우저는 이후 같은 서버에 요청을 보낼 때 Set-Cookie 헤더에 쿠키를 담아 전송할 수 있다.

Cookie 예제
쿠키는 name, domain, path로 식별 가능하고, 브라우저의 "cookie jar"에 저장된다.

domain이 서로 다르므로 위 두 쿠키는 별개의 쿠키로써 취급한다.
문제
- SSL 인증서를 통해 보호되지 않으면, 공격자는 해당 쿠키를 읽고 변조할 수 있다.
- 클라이언트는 무작위로 쿠키들을 조작하거나 삭제할 수 있으므로, 중요한 정보들을 쿠키에 저장하면 안된다.
- Set-Cookie: 150
- User가 쿠키 파일을 수정 (Cookie Poisoning)
- Cookie: 15 라고 변경 가능
대처방안
- 브라우징 이후 쿠키 설정, 조작 및 삭제 차단.
- 모든 페이지에 SSL 인증 (HTTPS)
- 암호학적 checksum 검증 (integrity) => HMAC과 비슷.
- 서버가 쿠키를 전송할 때 checksum을 붙여 전송한다.
- 클라이언트는 해당 checksum을 알지 못하면, 쿠키를 인증받을 수 없다.
Session Management
- 세션 관리(Session management)
- 웹 개발자가 상태를 가지지 않는(stateless) HTTP 프로토콜에서 세션 상태를 지원하도록 만드는 데 사용하는 기술이다.
- HTTP는 상태를 가지지 않는다(stateless)
- 사용자가 웹 서버에 본인을 인증한 후에는, 다음 HTTP 요청(GET 또는 POST)이 있을 때마다 서버가 사용자에게 다시 계정 정보와 비밀번호를 요구하지 않아야 한다.
- 세션 정보는 세션 식별자(session ID)를 사용하여 웹 서버에 저장된다.
- 세션 ID와 연관된 세션 데이터(사용자 이름, 계정 번호 등)의 "저장"은 로컬 메모리, flat files, DB 등 다양한 기술을 통해 웹 서버에서 이루어진다.
- 웹 개발자가 상태를 가지지 않는(stateless) HTTP 프로토콜에서 세션 상태를 지원하도록 만드는 데 사용하는 기술이다.

Session Token
- 브라우저 쿠키 (세션 쿠키)
- Set-Cookie: SessionToken=fdutyjdj21kdn
- URL link에 임베딩
- https://site.com/checkout?SessionToken=fdutyjdj21kdn
- Hidden form field
- <input type=“hidden” name=“sessionid” value=“kh7y3b”>
문제
1. URL link에 임베딩하는 방식은 HTTP Referer Header에 토큰이 그대로 노출될 수 있음.
HTTP Referer Header
원래 Referrer인데 오타 버전이 굳어짐.
request를 보내기 전, browser가 직전에 접속한 URL 정보를 나타냄.
2. Session hijacking
공격자가 특정 사용자의 세션 토큰을 훔쳐 본인인 척 할 수 있다.
3. 예측가능한 토큰
예측할 수 없게 랜덤한 토큰으로 생성해야 한다.
4. Cookie theft
Cross Site Scripting (XSS) 문제 발생 가능
5. session fixation attacks (세션 고정 공격)
공격자는 웹 애플리케이션 로그인 페이지에 액세스하여 생성된 세션 ID를 받은 다음 피해자가 제공된 세션 ID를 사용하고 인증하도록 하는 공격.
- 공격자는 특정 사이트 A에서 임의의 세션 토큰을 얻음.
- 피해자에게 공격자의 세션 토큰과 URL을 같이 보냄.
- User는 해당 URL을 클릭하여 A에 로그인하게 됨. (공격자의 토큰이 로그인되게 됨.)
- 공격자는 user의 세션을 훔쳐 세션 토큰을 사용함.
대처방안
- 항상 새로운 session ID를 발급할 것
- 강력한 세션 토큰을 발급할 것
- SessionToken = HMAC( k, SID(userID, exp.time, data(capabilities, user data, ...) ) )
- k = 사이트 내 모든 웹서버에게 알려진 key
- SessionToken = HMAC( k, SID(userID, exp.time, data(capabilities, user data, ...) ) )
- 서버는 만료시간이 지나면 무조건 logout 시키도록 user state를 엄격하게 유지해야 한다.
XSS (cross-site scripting)
MITRE(마이터 - 공격 표준 설정 단체) 에서 지정
-> CWE-79 (Improper Neutralization of Input During Web Page Generation)
-> [웹 페이지가 생성되는 동안 입력값의 중립화에 실패]
- 웹사이트에서 의도치 않은 스크립트를 넣어서 실행시키는 기법
- 코드 삽입(code injection) 유형 중 하나.
Persistent XSS (stored XSS)
Script 언어에 대한 필터링 없이 user input을 보여주는 것은 XSS를 일으킬 수 있다.
예시

JS 언어 입력시 웹 브라우저는 이를 스크립트로 인식하게 되어 JS 언어 ( ex> os 라이브러리) 를 통해 시스템에 접근할 수 있다.
따라서 공격자는, 게시판에 스크립트를 삽입한 후 공격 대상자가 해당 게시글을 클릭하도록 유도하는 것.
과정

Non-Persistent XSS (reflected XSS)
- 고전적인 잠재적 벡터(공격 경로)의 예는 사이트 검색 엔진이다.
- 사용자가 문자열을 검색하면, 검색 문자열은 일반적으로 결과 페이지에 그대로 다시 표시된다.
- 이는 사용자가 무엇을 검색했는지 보여주기 위함!
- 이 응답이 HTML 제어 문자(예: <, > 등)를 적절히 이스케이프(escape)하거나 거부하지 않는다면, XSS이 발생할 수 있음.
ex>
http://www.vulnerablesite.com/search.jsp?keyword="<SCRIPT> attack code </SCRIPT>"
대처 방안
- HTML sanitization
- 입력 필드에 위치한 바람직하지 않은 문자에 대해 검증하고 차단해야한다. ( < , > , \, ' 등)
str = str.replaceAll("<", "<");
str = str.replaceAll(">", ">");
str = str.replaceAll("\"", """);
str = str.replaceAll("'", "’");
- 스크립트 언어 사용 차단
'Computer Science > 정보 보호와 시스템 보안' 카테고리의 다른 글
chapter 8 - Attack & Defense (Web Security 2/2) (0) | 2024.11.30 |
---|---|
Chapter 9 - Attack & Defense (Network Security 3/3) (1) | 2024.10.24 |
Chapter 9 - Attack & Defense (Network Security 2/3 - TCP/IP level) (0) | 2024.10.24 |
Chapter 9 - Attack & Defense (Network Security 1/3 - ARP level) (1) | 2024.10.24 |
Chapter 7 - Security Protocol (Certificate Authority) (0) | 2024.10.24 |