Post

네트워크 기본

Posted
By futuremaker
35 min read
네트워크 기본

쿠키와 세션

쿠키

쿠키는 Key - Value의 구조이며, 클라이언트의 브라우저에 저장되는 작은 데이터 파일이다. 사용에 유효한 시간을 명시할 수 있으며, 유효시간이 정해지면 브라우저가 종료되도 유지된다. 쿠키는 사용자가 따로 요청하지 않아도, 브라우저가 자동으로 HTTP 헤더에 포함하여 서버에 전송한다.

  • 단점
    • 쿠키의 값을 그대로 보내기 때문에 보안에 취약하다.
    • 용량 제한이 있다.
    • 브라우저마다 쿠키에 대한 지원 형태가 다르기때문에 브라우저간 공유가 불가능하다.
    • 쿠키 사이즈가 클수록 네트워크 부하가 심해진다.

세션

세션은 쿠키를 기반하지만 사용자 파일 정보를 브라우저에서 자장하는 것이 아닌 서버측에서 관리하는 것을 의미한다. 서버에서는 클라이언트를 구분하기 위해서 세션 ID 값을 부여하게 되고, 서버에 접속해 있는 동안 인증상태를 유지한다.

  • 단점
    • SessionID를 자체를 탈취하여 클라이언트로써 서버에 접근이 가능하다.
    • 서버의 세션 저장소를 사용하므로 요청이 많아지면 서버 부하가 증가한다.

츨차


SOP와 CORS

absolute

출처란 URL의 구성요소중 scheme, domain name, port 세가지가 합쳐진것을 의미한다.

SOP(Same-Origin Policy, 동일 출처 정책)

동일 출처 정책(SOP)이란 웹 브라우저에서 보안을 위해 Protocol, Host, Port 가 동일한 서버로만 요청과 응답을 할 수 있도록 한 정책이다.

SOP 정책이 허용하는 것과 허용하지 않는것

  • script
    • 다른 출처(cross-origin)의 스크립트를 문서에 삽입(embed)하는 것은 가능하지만, Fetch API 등을 이용하여 다른 출처로 요청을 날리는 것은 불가능하다.
  • css:
    • <link> 혹은 @import로 다른 출처의 css를 삽입할 수 있습니다. 이때 올바른 Content-Type 헤더가 설정되어야 할 수도 있습니다.
  • iframe
    • X-Frame-Options 응답 헤더가 DENY 혹은 SAMEORIGIN이 아닌 이상, 일반적으로 다른 출처의 iframe을 삽입하는 것은 가능합니다. 하지만 자바스크립트 등을 이용하여 다른 출처의 iframe에 접근하는 것은 불가능합니다.
  • form
    • <form> 태그의 action 속성값으로 출처가 다른 URL을 사용할 수 있습니다. 즉, 다른 출처로 폼 데이터를 전송하는 것이 가능합니다.
  • image
    • 다른 출처의 이미지를 삽입하는 것은 가능합니다. 하지만 자바스크립트 등을 이용하여 다른 출처의 이미지를 읽는 것은 불가능하다. (자바스크립트를 이용하여 다른 출처의 이미지를 <canvas>에 삽입하는 경우)
  • multimedia:
    • 다른 출처의 오디오·비디오를 삽입할 수 있습니다.

CORS (Cross-Origin Resource Sharing, 교차 출처 리소스 공유)

교차 출처 리소스 공유(CORS)다른 출처의 리소스를 요청할 때 지켜야 하는 SOP가 허용하는 예외 조항이다.

1
2

origin: https://www.naver.com
access-control-allow-origin: https://www.google.com

웹 애플리케이션이 출처가 다른 곳에 요청을 보낼때 요청 헤더에 Origin이라는 필드를 함께 보낸다. 이후 서버가 응답을 할때 Access-Control-Allow-Origin이라는 헤더 필드에 허용하고자 하는 출처를 명시한다. 서버에 요청을 하는 출처(origin)가 Access-Control-Allow-Origin에 명시된 출처(origin)인지 확인하고 유효하면 응답을 보낸다.

요청 헤더

Origin- Origin 헤더는 출처가 다른 요청 혹은 preflight 요청의 출처를 나타냅니다.
- 값이 null 일 수도 있으며, 출처가 다른 요청의 경우 항상 Origin 헤더가 전송된다.
Access-Control-Request-Methodpreflight 요청을 보낼 때, 서버에게 실제 요청의 HTTP 메서드 정보를 알려주는 역할한다.
Access-Control-Request-Headerspreflight 요청을 보낼 때, 서버에게 실제 요청의 HTTP 헤더 정보를 알려주는 역할을 한다.

응답 헤더

Access-Control-Allow-Origin- 리소스에 접근할 수 있는 출처를 명시함
- 오직 하나를 명시하거나 와일드 카드(*)를 사용할 수 있음, 단 인증 정보 사용시 와일드카드를 사용할 수 없음
Access-Control-Expose-Headers- 브라우저의 스크립트에 접근할 수 있는 헤더를 지정한다.
- 기본적인 헤더의 종류 : Cache-control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma
Access-Control-Max-Age- prefilght 요청이 얼마 동안 캐시 될지를 나타낼 떄 사용한다.
Access-Control-Allow-Credentails- 요청의 인증 모드(ex, fetch api의 credentails)가 include 인 경우, 응답을 브라우저의 스크립트에서 접근 할 수 있도록 허용할지 를 나타낸다. credentails가 include 인 요청의 경우 Access-Control-Allow-Credentails 헤더 값이 true이어야만 스크립트에서 응답에 접근할 수 있다.
Access-Control-Allow-Methods- preflight 요청에 대한 응답에 사용되는 헤더로, 이후 본 요청에서 어떤 HTTP 메서드를 사용ㅇ할 수 있는지를 나타낼 때 사용된다.
Access-Control-Allow-Headers- Access-Control-Request-Headers 헤더를 포함하는 preflite 요청에 대한 응답에 사용되는 헤더로, 이후 본 요청에서 어떤 HTTP 헤더를 사용할 수 있는지를 나타낼 때 사용된다.

출처


REST API란

REST(Representational State Tranfer) API는 REST 아키텍처 스타일의 제약 조건을 준수하고 RESTful 웹 서비스와 상호 작용할 수 있도록 하는 애플리케이션 프로그래밍 인터페이스이다. RESTful API를 통해 클라이언트 요청이 수행될 때 RESTful API 리소스 상태에 대한 표현을 요청자 또는 엔드포인트에 전송한다. 이 정보 또는 표현은 JSON, HTML, XML 등의 몇가지 형식으로 전송된다.

그 외에 헤더와 매개 변수는 요청의 메타데이터, 권한부여, URI, 캐싱, 쿠키 등에 대한 중요한 식별자 정보를 포함하고 있기 때문에 RESTful API HTTP 요청의 HTTP 메서드에서도 중요하다. 요청 헤더와 응답 헤더가 있으며, 각각 고유한 HTTP 연결 정보 및 상태 코드가 있다.

REST API 의 요소들

  • 자원(Resource)
    • 데이터 또는 서비스를 나타내는 모든것을 의미한다.
  • 표현(Representation)
    • 자원의 상태를 나타내는 데이터이다. JSON, XML 등의 형식이 데이터를 말한다.
  • URI
    • 각 자원은 고유한 식별자인 URI를 가지고 있다. URI는 자원을 찾을 수 있는 주소이다.
  • HTTP 메서드
    • 자원에 대한 특정 작업을 수행하기 위해 사용되는 메서드이다. GET, POST, PUT, DELETE 등이 있다.
  • Stateless(무상태성)
    • 각 요청 간에 클라이언트의 상태를 서버에서 유지하지 않는다. 모든 요청에 있어 서버는 독립적으로 처리한다.


REST API에 대한 제약 조건들에 대한 설명

API가 RESTful로 간주되려면 다음 기준을 따라야 한다.

  1. 클라이언트-서버

클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트 서버 아키텍처로 이루어져야 한다.

  1. stateless(무상태성)

클라이언트-서버 커뮤니케이션에 있어 GET 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않다.

  1. Cacheable (캐시)

클라이언트-서버 상호 작용을 간소화하는 캐시 기능 데이터

  1. Uniform interface (일관성있는 인터페이스)

정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스로 여기에 필요한 것은 다음과 같습니다.

  • 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되어야 한다.
  • 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 한다.
  • 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 한다.
  • 하이퍼텍스트/하이퍼미디어를 사용할 수 있어야 한다. 즉 클라이언트가 리소스에 엑세스한 후 하이퍼 링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 한다. (HATEOS)
  1. Layered System (계층화된 시스템 구조)

요청된 정보를 검색하는 데 관련된 서버(보안, 로드 벨런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템이여야 한다.

  1. Code on Demand (Optional)

요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능이 있어야 한다.

출처 : https://www.redhat.com/ko/topics/api/what-is-a-rest-api


XSS 공격이란 무엇이고 어떻게 예방할 수 있는가

XSS(Cross-site Scripting)권한이 없는 사용자가 악의적인 용도로 웹 사이트에 스크립트를 삽입하는 공격기법을 말한다. 다른 웹사이트와 정보를 교환하는 식으로 작동하므로 사이트 간 스크립팅이라고 부른다.

XSS는 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 나타나며, 공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 실행하게 되어, 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등의 민감한 정보를 탈취한다.

absolute

XSS 공격순서

  1. 해커가 사전에 만든 웹페이지에 사용자가 브라우저로 엑세스를 시도
  2. XSS 공격 link가 포함된 휍페이지가 브라우저에 표시
  3. 사용자가 link 클릭
  4. 사용자가 느끼지 못하는 사이 취약한 사이트에 있는 해커의 스크립트에 엑세스 됨
  5. 사용자의 웹브라우저 상에서 해커의 스크립트가 실행

XSS 대응방안

  1. 입력 값 제한

사용자의 입력값을 제한하여 스크립트를 삽입하지 못하도록 해야한다. https://futuremaker019.github.io?page=1과 같이 URL에서 사용자의 입력값인 page가 화면에 바로 노출되는데, 이때 page의 값을 숫자만으로 허용한다면 그 외의 입력값에는 출력되지 않기 떄문에 대응이 가능하다.

  1. 입력 값 치환

XSS 공격은 기본적으로script 태그를 사용하기 때문에 XSS 공격을 차단하기 위해 태그 문자(<, >)등 위험한 문자 입력시 문자 참조로 필터링하고, 서버에서 브라우저로 전송 시 문자를 인코딩 한다. 예를들어, 문자 <는 동일한 의미와 HTML <로 변경한다. HTML 엔티티는 대부분의 인터프리터(특히, 브라우저)에서 특수한 의미를 가지지 않으며, 단순한 문자로 처리된다. 이렇게 인코딩하면 사용자는 script가 문자 그대로 보이지만 HTML 문서에서는 <script>로 나타나서 브라우저에서 일반 문자로 인식하고 스크립트로 해석되어 실행되지 않는다.

  1. 스크립트 영역에 출력 자제

이벤트 핸들러 영역에 스크립트가 삽입되는 경우 보호기법들을 우회할 수 있기 때문에 사용자의 입력을 출력하는 것을 최대한 자제해야 한다.

  1. 라이브러리 이용

XSS를 막아주는 Anti XSS 라이브러리를 여러 회사에서 제공하는데 이 라이브러리를 사용하면 손쉽게 XSS를 방어할 수 있다. Anti XSS에는 OWASP Antisamy나 Naver Lucy XSS Filter, ESAPI 등이 있다.

출처 : https://easymedia.net/Culture/EasyStory/?no=170&mode=view&IDX=1165&p=1


SQL Injection 이란 무엇이고 어떻게 예방할 수 있는가

SQL Injection 이란

SQL Injection이란 웹 애플리케이션이 백엔드에서 구동 중인 데이터베이스에 질의를 하는 과정에 사용되는 SQL 쿼리를 조작하여 데이터베이스를 대상으로 공격자가 의도한 악의적인 행위를 할 수 있는 Injection 기반의 웹 취약점이다. 공격자가 SQL Injection 공격에 성공하게 되면 조직 내부의 민감한 데이터가 개인 정보를 획득할 수 있으며, 심각한 경우에는 조직의 데이터 전체를 장악하거나 완전히 손상시킬 수 있다.

동작원리

  1. 사용자가 웹 애플리케이션에서 데이터베이스와 연동된 기능을 사용할 때 사용자에 의해 입력된 데이터(또는 웹 애플리케이션에 의해 셋팅된 데이터)는 HTTP 요청(GET 매개변수 또는 POST Body 매개변수 등)을 통해 웹 애플리케이션으로 전송된다.
  2. 전송된 데이터는 서버측 스크립트에 의해 미리 정의 및 저장되어 있던 SQL 쿼리 안의 지정된 위치로 대입된다.
  3. 서버측 스크립트는 데이터베이스에 완성된 SQL 쿼리 실행을 요청한다.
  4. 데이터베이스는 SQL 쿼리를 실행한 후 조건에 부합하는 레코드셋이나 Boolean 값(참/거짓) 또는 오류를 반환해준다.
  5. 서버 측 스크립트는 데이터베이스에서 반환된 데이터에 맞게 HTTP 응답 메시지를 만들어 사용자에게 회신한다.

absolute

예방

  1. 입력값 검사

HTTP 요청을 통해 전달되는 사용자 데이터에 SQL 구문으로 해석될 수 있는 문자 또는 공격에 사용되는 SQL 구문들의 포함여부를 검사하고 포함시 요청을 차단하거나 해당 문자를 제거(또는 다른 문자로 대체)해야 한다. 이 방법만으로는 SQL Injection 공격을 안전하게 방어할 수 없다.

  • SQL 기호: 홑따옴표(‘), 겹따옴표(“), 세미콜론(;), 대시(-), 샵(#), 슬래시샵 (/*) 등
  • SQL 구문: SELECT, INSERT, UPDATE, DELETE, UNION, GROUP BY, HAVING, ORDER BY 등
  1. 저장 프로시저 사용

웹 애플리케이션에서 데이터베이스에 접속하여 어떤 작업을 수행할 때 저장 프로시저를 사용하는 방법이다. 저장 프로시저 내에서도 SQL 쿼리가 사용되고, 저장 프로시저를 호출하는 명령의 매개변수로서 사용자 입력값이 안전하지 않은 방식으로 사용되는 경우도 위험하므로 여전히 SQL Injection의 공격에 노출된다.

  1. 매개변수화된 쿼리 적용

매개변수화된 쿼리는 Prepared Statement라고 불리며, 데이터베이스에서 사용되는 동일하거나 유사한 sQL 쿼리를 효율적으로 반복적으로 실행하기 위해 사용되는 기능이다. 매개변수화된 쿼리는 자주 사용되는 SQL 쿼리를 데이터베이스에 준비해두었다가, 해당 SQL 쿼리 실행에 필요한 값들만 매개변수로 전달하여 실행하는 방식이다. 매개변수화된 쿼리를 사용하면 공격자는 SQL 쿼리의 구조를 알 수 없고, 어떤 HTTP 매개변수가 SQL 쿼리의 어느 부분에 전달되는지 알지 못하므로 SQL Injection 방어에 유용하게 활용될 수 있다.

1
2
3
4
5
6

$conn->prepare("INSERT INTO crews (firstname, lastname, email) VALUES (?, ?, ?)");
$stmt->bind_param("sss", $firstname, $lastname, $email);
$firstname = $_POST['firstname'];
$lastname = $_POST['lastname'];
$email = $_POST['email'];
$stmt->execute();

쿼리구문에서 values절에 데이터가 입력될 곳은 물음표(?)로 표기된다. 이를 placeholder 라고 한다. 이 SQL 쿼리는 데이터베이스에 전송되고, 추후 사용자로부터 전달받은 데이터를 매개변수를 통해 전달(바인딩)하여 SQL 쿼리를 실행한다.

  1. 최소 권한 & 최소 기능 사용

웹 애플리케이션 서비스에 필요한 최소한의 권한만을 보유한 별도의 데이터베이스 계정을 사용해야 한다. 또한 편의상 제공되는 불필요한 기능들은 비활성화해야 한다.

  1. 데이터베이스 최신 패치 사용

최신 보안 패치를 수시로 확인하고 적용한다.

출처 : https://www.bugbountyclub.com/pentestgym/view/52


토큰이란

인증 및 승인의 경우 토큰은 요청을 수행하는 주 구성원의 ID 및 이들에게 승인된 엑세스 종류에 대한 정보가 포함된 디지털 객체이다. 대부분의 인증 흐름에서 애플리케이션 또는 애플리케이션에 사용되는 라이브러리는 애플리케이션이 액세스하도록 승인된 리소스를 결정하는 토큰에 대한 사용자 인증 정보를 교환한다.

서버기반 vs 토큰 기반

  • 서버(세션) 기반 인증 시스템

    • 서버의 세션을 사용해 사용자 인증을 하는 방법으로 서버측에서 사용자의 인증 정보를 관리하는 것을 의미한다.
    • 클라이언트 상태를 계속 유지해야하며, 사용자가 증가함에 따라 성능의 문제를 일으킬 수 있으며 확장성이 어렵다.

  • 토큰 기반 인증 시스템

    • 서버기반 시스템과 달리 상태를 유지하지 않고 사용자에게 토큰을 발급하여 인증받은 사용자인지 확인하는 작업만 수행한다.

absolute

동작방식

  1. 사용자가 아이디와 비밀번호로 로그인을 한다.
  2. 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급한다.
  3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고, 서버에 요청을 할 때마다 해당 토큰을 HTTP 요청 헤더에 포함시켜 전달한다.
  4. 서버는 전달받은 토큰을 검증하고 요청에 응답한다.

토큰 장식의 단점

  1. 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있다.
  2. Payload 자체는 암호화되지 않기때문에 유저의 중요한 정보는 담을 수 없다.
  3. 토큰을 탈취당하면 대처하기 어렵다. (사용기간을 제한한다.)

출처

  1. https://cloud.google.com/docs/authentication/token-types?hl=ko
  2. https://inpa.tistory.com/entry/쿠키-세션-토큰


URL, URI, URN의 차이점

absolute

URI

  • Uniform Resource Identifier의 약자
  • 인터넷의 자원을 식별할 수 있는 문자열을 의미한다.
  • URI는 URL과 URN을 포함하는 상위 개념이다.

URL

  • Uniform Resource Locator의 약자
  • 네트워크 상에서 리소스(웹 페이지, 이미지 파일, 동영상 파일 등)의 위치한 정보를 나타낸다.
  • URL은 HTTP 프로토콜 뿐만아니라 FTP, SMTP 등 다른 프로토콜에서도 사용할 수 있다.

구조

1

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
  • scheme : 사용할 프로토콜을 뜻하며 웹에서는 http 또는 https를 사용
  • user와 password : (서버에 있는) 데이터에 접근하기 위한 사용자의 이름과 비밀번호
  • host와 port : 접근할 대상(서버)의 호스트명과 포트번호
  • path : 접근할 대상(서버)의 경로에 대한 상세 정보
  • query : 접근할 대상에 전달하는 추가적인 정보 (파라미터)
  • fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보

URN

  • Uniform Resource Name의 약자
  • URN은 URI의 표준 포맷 중 하나로, 이름으로 리소스를 특정하는 URI이다.
  • HTTP와 같은 프로토콜을 제외하고 리소스의 name을 가리키는데 사용된다.

출처


웹 캐시란

웹 캐시 또는 HTTP 캐시는 서버 지연을 줄이기 위해 웹 페이지, 이미지, 기타 유형의 웹 멀티미디어 등의 웹 문서들을 암시 저장하기 위한 정보기술이다. 웹 캐시 시스템은 이를 통과하는 문서들의 사본을 저장하며 이후 요청들은 특정 조건을 충족하는 경우 캐시화가 가능하다.

웹 캐시 시스템은 일종의 어플라이언스나 컴퓨터 프로그램을 의미할 수 있다. 동일한 서버에 다시 접근할 때에는 근처에 있는 프록시 서버의 웹 캐시에 저장된 정보를 불러오므로 더 빠른 열람이 가능하다.

출처 : https://ko.wikipedia.org/wiki/웹-캐시


프록시란

프록시 서버란 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 프록시, 그 중계 기능을 하는 것을 프록시 서버 라고 부른다.

출처 : https://ko.wikipedia.org/wiki/프록시-서버


포워드 프록시란

포워드 프록시는 일반적으로 프록시, 프록시 서버 혹은 웹 프록시라고 불린다. 포워드 프록시는 클라이언트들 앞에 위치한다. 클라이언트들이 서버에 요청을 보내면 포워드 프록시가 해당 요청을 서버 대신 받아서 서버에서 전달해준다. 마찬가지로 서버의 응답을 포워드 프록시가 대신 받아 클라이언트에게 전달해준다.

포워드 프록시 이점

  • 접속 제한 회피: 일부 정부, 학교, 기타 조직은 방화벽을 사용하여 사용자들에게 제한된 엑세스를 제공한다. 포워드 프록시를 이용하면 사용자가 방문하는 사이트에 직접 연결하지 않고 프록시에 연결하여 이러한 제한츨 회피한다.
  • 특정 콘텐츠 제한 : 위와는 반대로, 사용자들이 특정 콘텐츠에 접속하는 것을 제한할 수 있다. 예를 들어 학교와 같은 곳에서 도박, 음란물 사이트와 같은 곳을 포워드 프록시의 필터링 규칙으로 제한할 수 있다.
  • 캐싱 기능 : 포워드 프록시는 캐싱 기능을 지원하기 때문에 동일한 요청에 대해 캐싱된 내용을 전달하여 성능을 향상시킬 수 있다.
  • IP 우회 및 보안 : 클라이언트에서 프록시 서버를 거쳐 요청을 보내게 되면, 서버 측은 클라이언트의 정보가 아닌 포워드 프록시의 정보를 받게 된다. 따라서 서버 측에 클라이언트의 정보를 숨길 수 있다.

출처: https://code-lab1.tistory.com/214


리버스 프록시란

리버스 프록시는 네트워크의 가장 끝에 있는 웹 서버들의 바로 앞에 위치하여 웹 서버로 향하는 모든 요청을 처리하고 필요할 때만 웹서버에게 자원을 요청할 수 있다. 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로써 성능을 개선할 수 있다. 리버스 프록시는 일반적으로 웹 서버의 이름과 IP 주소로 스스로를 가장 하기 때문에, 모든 요청은 서버가 아닌 이 프록시로 가게 된다.

Network
쿠키 세션 SOP CORS study
This post is licensed under CC BY 4.0 by the author.