사이버보안
보안의 3대 요소 (CIA Triad)
-
Credibility (기밀성)
정보의 소유자가 원하는 대로 정보의 비밀이 유지되어야 한다는 원칙
기밀성을 해치는 공격: 도청, 사회 공학, Sniffing, Snooping
기밀성을 보존하려면: 식별(Identification), 인증, 권한부여, 암호화 등 -
Integrity (무결성)
비인가된 자에 의한 정보의 변경, 삭제, 생성 등으로부터 보호하여 정보의 정확성, 안정성이 보장되어야 한다는 원칙
무결성을 해치는 공격: 위조(Forgery), 부인(Repudiation), 변경(Modification), 가장(Masquerading), 재전송(Replaying)
무결성을 보존하려면: 접근제어, 메시지(데이터) 인증 등 -
Availability (가용성)
정보 시스템은 적젏한 방법으로 작동되어야 하며 정당한 방법으로 권한이 주어진 사용자에게 정보 서비스를 거부하여서는 안된다는 원칙
가용성을 해치는 공격: 서비스거부공격(DoS, Denial of Service), 분산서비스거부공격(DDoS, Distributed DoS)
가용성을 보존하려면: 백업 솔루션 사용, 침입 탐지 시스템 운용 등 -
Authentication (인증)
사용자의 신원을 검증하고, 전송된 메시지 출처를 확인하는 것
인증성을 해치는 공격: 메시지 변조, 중간자 공격(MITM attack)
인증성을 보존하려면: 메시지 인증, 전자 서명(Digital Signature) 등 -
Accountability (책임추적성)
사용자의 모든 행동에 대한 로그를 남겨서, 나중에 공격이 일어나거나 에러가 발생했을 때, 분석해서 원인을 찾을 수 있어야 한다.
책임추적성을 해치는 공격: 직무 유기, 권한 남•오용
책임추적성을 보존하려면: 시스템 로그 관리, 포렌식 분석 등※ 로그(Log): 사용자가 시스템에 접속할 때마다, 사용자의 모든 액션이 시스템에 기록되고, 이러한 기록을 "로그 파일"이라고 한다.
Web 기초
통신 프로토콜: 서로 통신할 때의 규약
-
HTTP(Hyper Text Transfer Protocol)
-응용계층에서 동작하는 protocol
-Connectionless: 하나의 요청에 하나의 응답을 한 후 연결을 종료. 요청 마다 새로 연결함.
-Stateless: 통신이 끝난 후 상태 정보를 저장하지 않음. -
HTTP 통신
-서버는 HTTP 서버를 HTTP 서비스 포트에 대기 (일반적으로 TCP/80 또는 TCP/8080)
-클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석하여 적절한 응답을 반환
-네트워크 포트: 클라이언트와 서버가 정보를 교환하는 추상화된 장소.
-서비스 포트: 네트워크 포트 중 특정 서비스가 점유하고 있는 포트.0~1023: Well-known port / Privileged port
22: SSH
80: HTTP
443: HTTPS -
HTTP request 메시지
-GET: 가장 일반적인 HTTP request 형태로, 서버로부터 데이터를 가져옴.
데이터가 주소 입력란에 표시되므로 보안에 매우 취약한 방식.
ex) 브라우저에 웹 서버 주소 입력, 하이퍼링크 클릭 시 새로운 페이지 얻어오는 것
-POST: data를 서버에 제출하는 용도. 서버에 데이터를 추가, 작성.
데이터가 Body에 포함되어 사용자에게 노출되지 않아 보안적인 면에서 안전.
ex) 로그인 할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내짐
-
HTTP respone 메시지
-client의 HTTP request에 대한 respose를 반환하는 메시지
-요청 수행 여부, 상태 정보, 클라이언트에게 전송할 리소스 등 포함
-상태 코드: 요청에 대한 처리 결과를 세 자릿수로 나타냄. HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있는데, 각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류.
POST는 데이터가 Body로 전송되고, 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬의 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인가능
HTTPS(HyperText Transfer Protocol over Secure Socket Layer): HTTP의 POST 요청이 가로채질 수 있는 문제를 보완하기 위해 TLS(Transport Layer Security)프로토콜을 도입.
-TLS는 서버와 클라이언트 간의 모든 HTTP 메시지를 암호화하여 도청과
변조로부터 보호. (TLS는 공개 키 암호와 대칭 키 암호를 사용)
HTTP의 특징: Connectionless와 Stateless
-> 클라이언트의 IP 주소와 User-Agent는 매번 변경될 수 있는 고유하지 않은 정보이기 때문에 웹 서버는 클라이언트를 기억할 수 없다.
=> 상태유지를 위해서 쿠키와 세션 도입
- Cookie & Session
-cookie: 키(Key)와 값(Value)로 이루어진 일종의 단위이며 인증 상태를 나타내는 정보를 보관하고, 브라우저 내부에 저장된다.
서버는 클라이언트의 요청에 포함된 쿠키를 확인해 클라이언트를 구분 가능하다.
-session: 인증 정보를 서버에 저장하고 해당 데이터에 접근할 수 있는 키(유추할 수 없는 랜덤한 문자열)를 만들어 클라이언트에 전달하는 방식으로 작동한다.쿠키에 인증상태를 저장하지만, 이는 클라이언트에 저장되기 때문에 클라이언트가 인증 정보를 변조할수 있다. 이와 같은 경우를 막기 위해
=> 세션(Session) 사용
Client-Side Attack
- 클라이언트 사이드 취약점: 웹 페이지의 이용자를 대상으로 공격할 수 있는 취약점
- 클라이언트 사이드 공격은 클라이언트 사이드 취약점을 통해 이용자를 식별하기 위한 세션 및 쿠키 정보를 탈취하고 해당 계정으로 임의의 기능 수행
- 동일 출처 정책 (Same Origin Policy (SOP))
- XSS (Cross-Site Scripting)
동일 출처 정책 (Same Origin Policy (SOP))
-같은 Origin 출처의 서버로만 요청을 주고 받을 수 있다라고 규정한 것
사용자가 악의적인 페이지를 접속해서 페이지가 JS를 이용해 이용자의 SNS 웹 서비스로 요청을 보낸다면, 브라우저는 요청을 보낼 때 헤더에 해당 웹 서비스 쿠키를 포함시킬 거고, 따라서 JS로 요청을 보낸 페이지는 로그인 된 이용자의 SNS 응답을 받을 것. 그러면 마음대로 페이지 접속자의 SNS에 글을 올리거나 삭제하고, SNS 메신저를 읽는 것도 가능할 것
=> 이와 같은 문제를 방지하기 위해 나온 것이 동일 출처 정책
XSS (Cross-Site Scripting)
-공격자에 의해 작성된 스크립트가 다른 사용자에게 전달되는 것으로 다른 사용자의 웹 브라우저 내에서 적절한 검증 없이 실행되어 발생하는 보안 취약점
-목적: 사용자의 쿠키, 세션 정보를 탈취해 다른 사용자의 권한을 취득하고 악성코드를 배포하거나 피싱해 사용자의 중요한 정보 획득
- 종류
- Stored XSS: 악성 스크립트가 서버에 저장되고 서버의 응답에 담겨오는 XSS
- Reflected XSS: 악성 스크립트가 URL에 삽입되고 서버의 응답에 담겨오는 XSS
- DOM Based XSS: 악성 스크립트가 URL Fragment에 삽입되는 XSS
쿠키 & 세션 관련 문제 풀이
- Cookie 문제 링크
풀이
우선 guest로 로그인을 하면
"you are not admin"이라고 뜬다.
그 다음 도구 더보기 -> 개발자 도구 -> Application -> Cookies에 들어간다. 들어간 후 value 값을 guest에서 admin으로 바꿔준다.
다시 문제 링크로 돌아가면 "Hello admin"이라고 뜬다. 
마찬가지로 먼저 guest로 로그인 해준다. 그럼 역시나 "you are not admin"이 뜬다. 
url에 admin을 더해 입력해주었더니 창에 session정보가 나온다.
admin의 session정보를 도구 더보기 -> 개발자 도구 -> Application -> Cookies의 sessionid value 값으로 바꿔준다. 
다시 문제로 돌아가면 "Hello admin"이라고 뜬다. 
