오늘은 컴활 2급 필기 시험이 있어 1부 강의를 수강하지 못하였으나 2부 강의는 수강을 할 수 있었다.
2부에서 다룬 내용은 웹 서버의 역할에 대하여 깊게 다루었다.
그 중 웹 서버 소프트웨어중 이제 우리가 주로 사용할 Nginx 대하여 간략히 설명을 해주셨다.
일단 Nginx은 내가 웹 개발을 했을 때 가끔식 듣기는 했으나 주로 사용했던 것이 Apache였다. 그래서 Apache와 Nginx에 대하여 검색 해보니 아래와 같은 차이점이 존재하였다.
Apache
- 웹 서버에서 정적 파일을 제공을 목적으로 만들어진 소프트웨어
- 프로세스 기반 접근 방식 으로 하나의 스레드가 하나의 요청을 처리하는 구조
- 매 요청마다 스레드를 생성 및 할당해야 하기 때문에 리소스를 많이 잡아먹음
Nginx
- 대용량 트래픽을 처리하기 위해 가벼움과 높은 성능을 목표로 하는 제작된 소프트웨어
- 이벤트 중심 접근 방식 으로 하나의 스레드 내에서 여러 요청을 처리하는 구조
- 비동기 Event-Driven 구조 : Event Handler에서 비동기 방식으로 먼저 처리되는 요청을 진행
- 코어 모듈이 Apache보다 적은 리소스로도 많은 트래픽을 효율적으로 처리 가능
대략적으로 왜 Nginx를 사용하는지 알게 되었으니 이제 다시 강의 내용으로 돌아와서 튜터님께서 Nginx에 대해 설명을 해주셨을 때 Nginx에대해 자세한 기능적인 설명을 하기 보다는 우리가 서버에게 요청을 보냈을 때 어떻게 서버가 요청을 인식하는 지에 대한 설명을 해 주셨다.
우리가 일반적으로 웹 브라우져에서 웹 페이지(예를 들어 www.naver.com)를 를 요철을 했을 때 DNS 부분을 제외하고 서버로 넘어가는 부분만 이야기를 하자면 IP로 변경된 주소로 서버의 위치를 찾아 그곳에 가면 Apache 또는 Nginx 같은 소프트웨어가 해당 주소를 확인하여 설정 된 부분으로 넘겨주는 역할을 진행을 한다
이때 프로토콜이 http인지 https인지를 확인하여 해당 포트번호(http: 80, http: 443)로 넘겨준다.
이때 넘겨 받는 부분은 Django 같은 프레임워크로 넘겨 주고 넘겨 받은 요청을 이제 우리 같은 개발자 작성해 놓은 부분에서 찾아 응답을 해주게 되는 것이다
이부분이 전반적인 클라이언트/서버 통신의 대략적인 내용이 된다
이렇게 어제와 오늘의 특강에서 가장 중요하게 다룬 내용일 클라이언트/서버 통신에 대한 내용이였던거 같다. 아무래도 AI 웹 개발이다보니 AI는 일단 제쳐두더라도 웹 개발을 어떤식으로 진행하고 우리가 개발 웹이 어떤식으로 사용자가 다루는지 확실 아는게 중요하다 보니 계속 반복해서 강조하는 것 같다.
다시 돌아와 오늘 진행했던 내용 중 확실히 개념을 잡아야 될 부분(2개)과 알아 두면 좋은 것(1개)에 대하여 글로 남겨 둘려고 한다.
확실히 개념을 잡아할 부분으로는
- 세션과 쿠키
- RESTful API 지원하는 URI
알아 두면 좋은 좋은 것으로는
- Django의 웹정보 보안은 어떻게 하는가?
이 있다
그럼 먼저 개념 부터 알아보도록 하자
- 세션과 쿠키
- 세션(session)
- 반영구적이고 상호작용적인 정보 교환을 전제하는 둘 이상의 통신 장치나 컴퓨터와 사용자 간의 대화나 송수신 연결상태를 의미하는 보안적인 다이얼로그(dialogue) 및 시간대를 가리킨다. 따라서 세션은 연결상태를 유지하는 것보다 연결상태의 안정성을 더 중요시 하게 된다.(출처: 위키백과)
- 쿠키(cookie)
- 웹 서버에 의해 사용자의 컴퓨터에 저장되는, '이름을 가진 작은 크기의 데이터'(출처: 위키백과)
- 사용자가 어떠한 웹사이트를 방문할 경우 사용자의 웹 브라우저를 통해 인터넷 사용자의 컴퓨터나 다른 기기에 설치되는 작은 기록 정보 파일, 인터넷 사용자가 같은 웹사이트를 방문할 때마다 읽히고 수시로 새로운 정보로 바뀐다 (출처: 위키백과)
- 뭔가 장황하나 결국은 쿠키의 경우에는 사용자(클라이언트)에게 기록을 하게 하는 것이며 세션은 서버쪽에서 클라이언트와 연결이 되면 생성되어 관리하게 되는 것이다.
- 즉 주체가 서로 다른 것이다.
- 세션(session)
- RESTful API 지원하는 URI(참조: https://www.elancer.co.kr/blog/view?seq=74)
- URI( Uniform Resource Identifier, 통합 자원 식별자 )
- Uniform은 리소스를 식별하는 통일된 방식
- Resource란, URI로 식별이 가능한 모든 종류의 자원(웹 브라우저 파일 및 그 이외의 리소스 포함)을 지칭
- Identifier는 다른 항목과 구분하기 위해 필요한 정보
- URI는 인터넷상의 리소스 자원 자체 를 식별하는 고유한 문자열 시퀀스
- URL( Uniform Resource Locator, 파일식별자, 유일자원지시기 )
- 네트워크상에서 통합 자원(리소스)의 위치 를 나타내기 위한 규약
- 웹 사이트 주소 + 컴퓨터 네트워크 상의 자원
- 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크 상의 자원을 모두 나타내는 표기법
- 특정 웹 페이지의 주소에 접속하기 위해서는 웹 사이트의 주소뿐만 아니라 프로토콜(https, http, sftp, smp 등)을 함께 알아야 접속이 가능
- 네이버를 이용하여 간단하게 URI와 URL의 표현을 확인 해 보자
- URI
- www.naver.com
- https://www.naver.com
- https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=ss,
- naver.com
- URL
- http://www.naver.com
- URI
- 위의 방식을 보면 URL은 결국 프로토콜 + 식별자 만 가능한 방면 URI는 식별자가 들어간 모든 경우를 포함 되는 것을 확일 할 수 있다
- 즉 URL은 URI 보다는 작은 개념인것이다
- 이때 같이 알아 두기 좋은 내용은 URN이 있는데 이것은 식별자(도메인) 이후에 있는 부분을 말하는 것으로 알아두면 좋다
- 이제 URI는 확실히 알게 되었는데 그렇다면 RESTful API란 무엇인지를 알아 볼 필요가 있다
- 우리는 CS를 공부하다보면 API, API 문서등의 단어를 만날 수 있다
- API란?
- 소프트웨어 간의 상호작용을 가능하게 하는 인터페이스
- 웹 API는 HTTP를 통해 클라이언트와 서버 간의 데이터 교환 가능
- 예시: Twitter API, Google Maps API, OpenWeather API
- API 문서란?
- API는 어떠한 기능들의 집합이 되기에 이를 활요하기 위해서는 해당 부분에 대한 이해가 필요하다. 짧은 API는 보고 이해를 하면 되지만 만약 아주 큰 API를 쓰게 될경우 우리는 그것을 보고 이해하기까지 오랜 시간이 걸릴 것이다. 이때 그 시간을 단축하기 위하여 API를 제공하는 쪽에서 각각의 기능에 대한 설명을 담은 문서가 API 문서가 되는 것 이다.
- 아래의 사진은 APP에서 사용자의 전화번호를 서버에게 전달하는 기능에 대한 API 문서이다.
- 간략하게 설명하자면 APP에서 DataOutputStream.writeUTF 함수를 통하여 전화번호를 담은 문자열을 요청하면 서버에서 DataInputStream.readUTF 함수를 통하여 해당 전화번호를 받는것이다
- APP과 서버와 통신하는 API 문서인데 이것을 웹 개발쪽으로 적용한다면 우리는 어떠한 명칭이 URI 주소가 될것이 될것이고 인자는 Form 데이터의 양식이 될것이다. 또한 반환값에는 어떠한 주소가 될수도 있고 검색한 데이터들이 넘겨줄 수 있는 것이다
- 자 이제 API 문서까지는 이해가 끝났다. 그렇다면 RESTful은 무엇인가?
- 웹 서비스 디자인 아키텍처로, 클라이언트와 서버 간의 상호작용을 정의
- RESTful API는 자원을 URI로 표현하며, HTTP 메서드(GET, POST, PUT, DELETE)를 사용하여 자원에 대한 작업을 수행
- 원칙: 무상태성, 캐시 가능성, 계층화된 시스템, 통일된 인터페이스
- 교재에서는 위와 같이 설명을 하고 있다. 즉 API 문서는 통일된 인터페이스를 가지게 되고 이때 인터페이스 명에 URI가 들어가고 인자위치에 From 데이터 들어가는 대 추가로 메서드 항목이 생성되어 HTTP 메서드를 표시해 주어야 한다. 기능의 경우는 삭제 또는 유지가 될 수 있고 반환값 위치에는 주소 혹은 요청한 데이터의 검색 결과 데이터가 주어질 수도 있다.
- 이렇게 REST 기반의 다양한 HTTP 메서드들을 활용하여 제작된 API를 RESTful API라고 하며 만약에 HTTP 메서들이 각자의 역활맞게 주어지지 않았다면 그것은 RESTful API가 아닌 REST API라고 한다
- URI( Uniform Resource Identifier, 통합 자원 식별자 )
- Django의 웹정보 보안은 어떻게 하는가?
- 주요 웹 보안 위협 요소
- XSS(교차 사이트 스크립팅)
- 악의적인 스크립트를 삽입하여 사용자 정보를 탈취하거나 웹 페이지를 변조
- CSRF(교차 사이트 요청 위조)
- 사용자가 의도하지 않은 요청을 보내게 하여 피해를 입힘
- SQL Injection(SQL 인젝션)
- SQL 쿼리에 악의적인 코드를 삽입하여 데이터베이스를 조작하거나 데이터를 탈취
- Click Jacking(클릭 재킹)
- 사용자가 의도하지 않은 클릭을 하도록 유도하여 악성 사이트로 이동시키거나 악성 행위를 수행하게 함
- XSS(교차 사이트 스크립팅)
- Django
- XSS(교차 사이트 스크립팅)
-
from django.utils.html import escape - escape : <, >, &, \, " 같은 문자열을 안전한 문자열로 바꿔주는기능
-
- CSRF(교차 사이트 요청 위조)
-
from django.views.decorators.csrf import csrf_exempt, csrf_protect -
<form action="" method="POST"> {% csrf_token %} <table> {{form.as_p}} </table> <input type="submit"> </form> - from 안에 Django에서 제공하는 임의 토큰 값을 통하여 CSRF 방어
-
- SQL Injection(SQL 인젝션)
- 따론 원시적(select * from users where id=id) 형태로 하는게 아닌 raw() 혹은 execute()를 이용하여 직접적으로 전달하지 않고 raw('select * from user where id=%s',[id]), execute('select * from user where id=%s',[self.id]) 처럼 검색할 조건 값을 전달
- Click Jacking(클릭 재킹)
- 기본적으로 config/settings.py 의middleware쪽에서 해당 부분을 설정하여 방지
- 코드로 해당 부분을 방지하는 부분 또한 제공하고 있다
-
from django.http import HttpResponse from django.views.decorators.clickjacking import xframe_options_deny, xframe_options_sameorigin @xframe_options_deny def view_one(request): return HttpResponse("I won't display in any frame!") @xframe_options_sameorigin def view_two(request): return HttpResponse("Display in a frame if it's from the same origin as me.")
- XSS(교차 사이트 스크립팅)
- 주요 웹 보안 위협 요소
'CS > 더 깊게 깊게' 카테고리의 다른 글
| HTTP/HTTPS (0) | 2024.08.06 |
|---|---|
| OSI 7계층 및 알아 두면 좋은 프로토콜 (0) | 2024.07.30 |
| 객체지향 프로그래밍 (0) | 2024.07.29 |
| 개발 방법론 정리 (0) | 2024.07.29 |