[Security FACT] 웹해킹 Week 2

웹해킹 2주차.pptx

2.41MB

인코딩

정보의 형태를 여러 이유때문에 다른 형태나 형식으로 변환하는 처리 혹은 그 처리방식.

컴퓨터는 문자를 인식할 수 없기 때문에 숫자로 변환하여 저장해야 한다.

그 기준이 되는 것이 문자코드(ASCII, 유니코드 등)

문자코드를 기준으로 문자를 코드로 변환하는 것을 문자 인코딩, 코드를 문자로 변환하는걸 문자 디코딩

ASCII Code

미국정보교환표준부호 (American Standard Code for Information Interchange)

최초의 문자열 인코딩. 1바이트 중 7비트를 사용해 128개의 문자 구성 가능.

Uni Code

영어 알파벳만 표현할 수 있던 것에서 벗어나 한 가지의 기준으로 전세계의 언어를 모두 표현하기 위해 나온 것.

유니코드는 총 1,114,112개의 문자를 표현할 수 있다. 같은 유니코드라도 실제로 컴퓨터에 어떻게 저장하느냐에 따라 여러가지 방식으로 나뉘어 진다. 

Code Point

식별 가능하게끔 하는 숫자. 유니코드의 0번째 문자는 0번째 Code Point라고 한다.

U+AC00 는 유니코드로 '가'를 나타내는데 이때 U+가 바로 Code Point. 유니코드라는 의미.

UTF-8, UTF-16

유니 코드를 이용하는 인코딩 방식.

이 유니코드표의 숫자 키들을 어떻게 표현하느냐에 따라 달린 것.

UTF-8은 1~4 바이트로 가변바이트를 사용하기 때문에, 1바이트로 표현이 충분한 A같은 경우는 0x41로 표현.

UTF-16은 16비트 즉, 2바이트로 표현하기 때문에, 0x0041 or 0x4100로 표현.

IP주소

인터넷에 연결된 모든 컴퓨터들이 갖게되는 고유한 식별 주소. 네트워크 인터페이스를 식별하는 역할도 하고, 패킷을 전달할 경로를 결정하는 라우팅(서로 다른 네트워크 중계, 적절한 통신경로 지정, 전송)의 기준이 됨.

네트워크 크기에 따라 클래스를 구분.

IPv4

8비트짜리 4도막으로 총 32비트 크기의 주소 체계. 각 도막마다 0~255까지의 숫자로 표현가능. 네트워크 식별 주소 및 노드 식별 주소에 따라 4개 클래스로 분류. 최대 약 40억 개의 서로 다른 주소부여 가능. but 컴퓨터 사용자가 급격히 계속 증가하면서 이것만으로는 부족할 수 있음. 그래서 ipv6 나옴.

IPv6

16비트씩 8도막으로 총 128비트 크기의 주소 체계. 콜론으로 도막 구분, 각 도막마다 16진수로 표현. 최대 약 1조 개 이상의 주소를 마련 가능. 또한, 실시간 서비스나 보안 기능이 ipv4보다 더욱 강화됨.

MAC 주소

네트워크 카드 하드웨어에 부여되는 고유한 주소. 모든 네트워크 장비나 랜카드에는 고유한 MAC 주소가 부여되어 있음.

네트워크 상에서 통신을 할 때 구분하여 인식하기 위해. tcp/ip를 이용해 ip주소를 사용하지만 이걸 mac주소로 변환하는 과정이 있음.=> arp 라고 함.

48비트로 구성. 16진수. 앞쪽 6자리는 제조사, 뒷 6자리는 시리얼 넘버

ip주소는 사설주소와 공인주소가 겹치는 일이 있지만, mac주소는 겹치지 않음.

프로토콜

네트워크 통신 시에 데이터를 원활하게 교환하기 위해 만든 공통의 통신규칙.

신호 체계 인증, 오류 감지 및 수정 기능 또는 데이터에 헤더를 붙이는 캡슐화와 동기화 등의 다양한 기능을 포함할 수 있음. (OSI 참조 모델의 계층을 넘어설 때마다 데이터를 캡슐에 넣거나 꺼냄.)

TCP

전송 제어 프로토콜(transmission control protocol)로 연결지향 프로토콜. 오류 제어, 흐름 제어 등의 기능. 데이터를 송신할 때마다 확인 응답을 주고받는 절차가 있어 중간에 데이터가 유실되면 재전송을 요청함. 통신의 신뢰성 보장.

3way handshaking / 4way handshaking

통신상의 신뢰성을 보장해주는 방법

3way handshaking – tcp에서 데이터를 주고받기 전, 서버와 클라이언트는 확인 패킷을 3단계로 교환하여 연결을 맺는다.

1단계. 클라이언트는 서버에 SYN(연결 요청 플래그)를 보내고 SYN-SENT 상태가 됩니다.

2단계. 서버는 클라이언트로부터 SYN을 받고, ACK(응답플래그)과 SYN을 보낸 후 SYN-RECEIVED 상태가 됩니다.

3단계. 클라이언트는 이에 대한 응답으로 ACK를 보내고, ESTABLISHED 상태가 됩니다.

서버도 그 ACK를 받으면, ESTABLISHED 상태가 되어 연결을 맺게 됩니다.

와이어샤크로 그 과정 실습했던 내용 (with 포트스캔): https://cafe.naver.com/secufact?iframe_url_utf8=%2FArticleRead.nhn%253Fclubid%3D28516594%2526articleid%3D248

SecurityFACT[건대 보안동아리] : 네이버 카페

4way handshaking – 3way hankshaking을 통해 연결했던 것을 종료하기 위해 수행하는 방법.

1단계. 클라이언트가 연결종료하겠다는 패킷 전송하고 대기상태로 바꿈. 아직은 연결된 상태.

2단계. 서버는 확인 패킷을 보내고 자신의 통신이 종료되기를 대기하는 상태로 바꿈.

3단계. 서버는 통신이 끝났으면 연결 종료 요청에 합의한다는 의미의 패킷 전송.

4단계. 클라이언트는 확인했다는 패킷을 전송.

그 패킷을 받고 서버는 연결 해제. 클라이언트는 잉여 패킷을 기다리는 과정을 거친 뒤 close.

UDP

비연결 지향 프로토콜. 최소한의 오류제어 기능만 수행. 단문 메시지를 교환하기 위해 사용되는 프로토콜. 데이터만 전송하고 확인절차를 생략해 통신의 신속성을 높임.

TCP와 UDP의 차이점

둘다 포트 번호로 서비스를 식별. 두 개의 차이는 신뢰인지 속도인지이다.

tcp- 메일, 파일 공유 등 데이터를 누락시키고 싶지 않은 서비스거나 용량이 큰 데이터를 전달해야 할 때 주로 사용.

udp- 주로 빠르게 전달해야 하는 음악이나 동영상 스트리밍 등.

 

HTTP

인터넷에서 텍스트 데이터를 주고받을 수 있는 프로토콜.

연결상태를 유지하지 않는 비연결성 프로토콜.

클라이언트가 어떠한 서비스를 url 등을 통해 요청(request)하면 서버는 해당 요청에 맞는 결과를 찾아 사용자에게 응답(response)함.

예를 들어 클라이언트 쪽에서 사용자가 회원가입시도-> 서버로 회원정보를 보냄-> 서버는 그걸 저장. 이러한 과정에서 http라는 규약을 이용.

HTTP method

URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작.

GET : 리소스를 가져오라는 메소드. 서버의 주소를 입력하거나 하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요하다. 이 리소스를 GET을 통해 요청해서 받아온다.

POST : 리소스로 데이터를 보내라는 메소드. 전송할 데이터는 보통 HTTP body에 포함된다.

HTTP Request / Response

클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답

둘다 HTTP 헤드와 바디로 구성

Request

클라이언트가 서버에 정보를 요청하는 것.

어떤 웹페이지를 어떤 방식으로 불러오고 싶은지 등의 정보로 구성.

시작줄+헤더+본문 구조

시작줄: 메소드 + 요청 타겟(url, 프로토콜, 포트) + http버전

자료 요청, 생성, 수정, 삭제를 요청 가능.

Response

클라이언트의 요청에 대한 결과를 반환하는 것.

요청받은 것을 읽어서 그 안의 명령을 처리한 뒤 결과를 담아 출력.

프로토콜 버전, 상태코드+헤더+본문 구조

숫자 세자리로 성공, 요청 오류 등등을 나타냄.

• 1xx (정보): 요청을 받았으며 프로세스를 계속한다
• 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다 ex) 200: 성공
• 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다 ex) 302: 다른 URL로 갈 것
• 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다 ex) 404: not found 
• 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다 ex) 500: 요청 처리중 에러 발생

HTTP/HTTPS 차이

HTTP는 암호화되지 않은 평문을 교환하기 때문에 중간에 가로채면 내용이 그대로 노출.

HTTPS: HTTP에 보안을 강화한 프로토콜. TLS 프로토콜을 도입하여 모든 HTTP 메세지를 암호화(공개키 암호화 방식).

 

1. 공개키로 암호화된 http요청이 오면 서버는 개인키를 이용해 암호화된 정보 해독.

2. 서버가 요청이 뭔지를 알고 응답을 다시 개인키로 암호화해서 클라이언트에게 전달.

3. 그럼 클라이언트는 공개키를 이용해 정보를 해독.

(이때 이 공개키는 공개키 저장소인 ca기업에 있음. 서버 기업은 ca기업과 계약을 통해 공개키 관리를 맡김. 그럼 그 기업만의 공개키와 암호키를 이용해 그 서버기업의 정보를 암호화한 인증서를 서버에 제공.

서버는 그 공개키로 암호화된 https 이외의 요청이 오면 이 인증서를 클라이언트에게 줌. 근데 신뢰가능한 ca기업의 공개키는 이미 클라이언트 측이 알고있을 확률이 높음. 그럼 그 공개키를 아는 클라이언트는 해독이 가능.)

URI

통합 자원 식별자(uniform resource identifier)

정보 리소스를 고유하게 식별하고 위치를 지정. 이것의 두 가지 형태가 있는데 그게 바로 URL, URN

URL(Uniform Resource Locator)

가장 흔한 형태의 URI. 서버에 있는 각 파일들의 위치를 표시하기 위한 것.

특정 서버의 한 리소스에 대한 구체적인 위치서술. (리소스가 정확히 어디에 있고, 어떻게 접근할 수 있는지를 분명히 알려줌.)

실제 이름이 아닌 주소니까 리소스의 위치를 옮길 경우 해당 URL은 다시 사용 불가.

그렇기 때문에 URN이 나옴.

URN(Uniform Resource Name)

컨텐츠를 이루는 한 리소스에 대해 그 리소스의 위치에 영향받지 않는 유일한 이름.

URN은 리소스를 여기저기로 옮겨도 동작.

이름을 유지하는 한 여러 종류의 네트워크 접속 프로토콜로 접근해도 동작. 그렇기에 그 지칭되는 리소스가 중복되지 않는 값이어야 함.

웹 (Web)

인터넷을 기반으로 구현된 서비스 중 HTTP를 이용하여 정보를 공유하는 서비스

웹 브라우저

서버와 HTTP 통신을 대신해주고, 수신한 리소스를 시각화.

이용자는 브라우저를 이용하여 쉽게 정보를 검색하고, 동영상을 보고, 파일을 내려받는다.

 

1. 주소창의 주소를 해석 ex) www.konkuk.ac.kr

2. www.konkuk.ac.kr에 해당하는 주소를 탐색 (DNS 요청)

3. HTTP를 통해 www.konkuk.ac.kr에 Request

4. www.konkuk.ac.kr의 HTTP Response 수신

5. 리소스 다운로드 및 웹 렌더링 (HTTP, JS, CSS)

웹 리소스

HTTP 요청 대상.

HTML, CSS, JS 및 문서, 사진 등 어떤 것이든 가능.

웹 서버

정보를 제공하는 주체.

정보를 받는 이용자를 웹 클라이언트 (Web Client)라고 한다.

클라이언트가 요청하는 각종 웹 리소스를 전달.

WAS (Web Application Server)

DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 서버

HTTP를 통해 컴퓨터나 장치에 앱을 수행해주는 미들웨어.

단순한 정적 컨텐츠는 웹 서버가 수행하고, 웹 서버 단독으로는 처리할 수 없는 동적 컨텐츠를 주로 제공하여 서버 부하를 방지한다. 

웹 렌더링

서버로부터 받은 리소스를 이용자에게 시각화하는 행위.

서버의 응답을 받은 웹 브라우저는 리소스의 타입을 확인하고, 적절한 방식으로 이용자에게 전달

예를 들어, 서버로부터 HTML과 CSS를 받으면 브라우저는 HTML을 파싱하고 CSS를 적용하여 이용자에게 보여줍니다.