ASAC 웹 풀스택

CORS 등장 배경CSRF(유저 비의도적 요청) 부분 방지를 위한 웹 브라우저 정책웹 브라우저는 자바스크립트를 동작시키는 엔진을 갖고있어, 무궁무진한 작업 수행이 가능함과 동시에 해커가 자바스크립트를 통해 위험한 작업을 수행할 수 있는 무한한 가능성을 갖게 된기도 한다.보안 취약성의 거의 대부분은 웹을 통해 이루어지며, 최전선에 있는 웹 브라우저는 보안에 예민할 수 밖에 없다.해커는 유저가 웹 브라우저를 정상적으로 사용할때, 악의적인 자바스크립트 수행으로 타 서버를 공격할 수 있다.웹 브라우저는 그런 요청이 발생하더라도 웹 브라우저 자신이 최대한 방지할 수 있도록 정책들을 마련해놓았다.W3C는 가장 먼저 SOP라는 정책 표준을 도입하여 웹 브라우저에서 단단하게 방어를 하도록 했는데API호출이 사실상 필수..

✅ HTTPS웹 통신 내 요청, 응답에 대한 암호화HTTPS(HTTP Secured, TLS): 웹 통신 내 end to end 회선 보호SSL(Secure Sockets Layer) 혹은 TLS(Transport Layer Seucurity) 프로토콜을 통해 HTTP 보안 강화✅ HTTPS 목적요청을 보내고, 응답을 받는 두 주체(end to end)만 HTTP 요청 및 응답을 읽을 수 있게 암호화목적: MITM(Man In The Middle) 공격 방지심화 : MITM (Man-In-The-Middle) 공격 종류🔹스니핑(sniffing, 도청): Wireshark 를 통해 여러분의 모든 웹 서핑 패킷 도청 가능보안되지 않았다는 것은 AP;access pointer 와 연결된 컴퓨터 사이에 암호화..

Session웹 서버 내 저장 + 단, SESSION_ID는 웹 브라우저 내 저장 및 전송session은 웹 브라우저 쿠키에 저장하던 값을 웹 서버측에 저장하기 위해 별개의 저장소 DB가 필요오해하지말자! Session을 사용한다고, Cookie를 사용하지 않는건 아니다.웹 브라우저 내 Cookie에는 어떤 세션인지 알기 위한 ID값 저장 필요Session의 대표적인 예: 웹 브라우저로부터 쿠키로 SESSION_ID를 받아 해당 요청 유저의 정보 조회속도가 매우 중요: API 수천번의 호출마다 Session 조회 필요그래서 현업에서 메모리 기반 DB인 Redis를 많이 사용 -> 비용 이슈..(메모리는 언제나 비싸다), 확장성 이슈(비싼 인스턴스)Session 의 장점Cookie의 단점 = Session..

이 Storage는 Cookie, Session처럼 Stateful HTTP를 위한 기술은 아니다.✅ Storage와 Cookie의 목적 차이🔹Storage웹 브라우저 저장소 (Stateful Http를 위한 기술은 아니다.)유저에 의해 변경된 옵션 상태 등 -> 필요에 따른 조회가 필요할 때(진짜 저장소)마지막에 어떤 소셜 계정으로 로그인했는지 저장하고, 1년 뒤 로그인할 때 표시하여 알려주기🔹Cookie웹 서버에게 웹 브라우저가 매번 전달할 특정 정보를 위한 저장소(Stateful)로그인 인증 정보 등 -> 웹 서버가 매번 요청할 때마다 필요한 정보를 웹 브라우저에 넣어두고 전달받아 쓴다.만료시간이 필요한 정보는 cookie를 사용 [Storage와 Cookie구분하기]사용자가 방문한 페이지 저장..

✅ Cookie웹 서버의 제어 + 웹 브라우저 내 저장 및 전송- 웹 서버의 제어: Set-Cookie헤더를 통해 어떤 데이터를 쿠키로 쓸것인지, 유효시간 및 보안 설정✅ 쿠키 사용의 기준: Dmain + Path웹 브라우저가 쿠키를 웹 서버에게 전송하는 기준(전송할지, 말지) = 해당 쿠키를 어떤 요청에 보낼지모든 쿠키에는 도메인이 연결되어있다.같은 도메인이더라도 각 페이지마다 보내줘야하는 쿠키가 다르다. 예를 들어서 웹 브라우저에 아래와 같이 저장되어 있는 쿠키 리스트가 있다고 쳐보자1번 쿠키 : h1 = w1 (Domain: `a.com`, Path: `/`)2번 쿠키 : h2 = w2 (Domain: `a.com`, Path: `/user`)3번 쿠키 : h3 = w3 (Domain: `b.com..

✅ HTTP 는 Stateless Protocol이다.💡Stateless?🔹Stateless(불연속성): 무상태, 서버가 클라이언트의 상태를 보존하지 않음최소한의 자원으로 서버 유지를 가능하게함 (수억명의 트래픽(Concurrent Users)커버 가능)   - Easier to scale, cache, and manage the service기본적으로 세션을 유지하지 않고, 서버는 Client specific세션 데이터를 저장하지 않기에 클라이언트는 끊임없이 자신이 누구인지 밝혀야한다는 것 -> JWT HTTP는 stateless 하게 설계되었으나 쿠키와 세션을 활용해서 stateful하게 사용할 수도 있다고 이해했다.✅ Stateful HTTP: Cookie & Session웹 서버는 웹 브라우저..

프록시를 사용하는 이유보안: IP 숨기기 혹은 프록시 서버를 방화벽으로 사용하기도 한다(프록시 방화벽)속도(캐시): 동일 요청이 들어오면 서버에 다로 접속할 필요가 없이 저장된 Cache 자원을 반환전송 시간 절약, 외부 트래픽을 줄여 네트워크 병목 현상도 방지 = 이는 서비스의 속도를 높여준다ACL: 사이트 접근 범위 정책 정의 (Proxy Server 에 접속할 수 있는 범위를 설정하는 옵션)Log/ Audit: 리포트, 모니터링(회사 내 직원의 인터넷/인트라넷 사용을 레포팅)지역 네트워크 제한 우회: 한국에서는 접속이 제한이 되는 사이트 (IP 검사로 한국에서의 접속임을 감지)이런 경우 프록시 서버를 사용하면 접속을 다른 나라로 우회proxy는 클라이언트측 Forward Proxy 와 서버측 Rev..

캐시할 데이터는 웹 서버가 반환하는 값-> 반환값에 대한 소유주: 웹 서버-> 웹 서버가 캐시를 모두 제어 Cache-control 헤더를 통한 세부 설정캐시 입장에서 누가 갑이고 누가 을인가?갑: 웹 서버: 웹 서버가 캐시를 하냐마냐 등을 모두 제어 -> Cache-control 헤더을: 웹 브라우저나 프록시: 웹 서버가 보내는 Cache-control헤더를 보고 하라는 대로 순종캐시 저장 여부: 캐시해? 말아?`no-store`: 캐시 안함`no-cache`: 캐시 함. 단, 매번 재검증 후 사용(패킷 경량화) -> 이름만 보고 캐시 안하는거아니야? 라고 헷갈리지 말기 캐시 저장 장소: 어디에 저장해?`public`: Private(웹 브라우저) + Shared(프록시) 모두에 저장 -> 브라우저에도..

재검증을 통한 캐시 값의 준실시간성 보장캐시 사용 여부: 실시간성이 중요하다면 성능에 문제가 되더라도 캐시는 사용하지 않는 것이 맞다. -> 실시간을 생각하는데 캐시사용? 재검증 필요HTTP Cache 동작 원리캐시는 임시 저장을 위한 전략준실시간성을 위해서 캐시해 놓은 데이터가 너무 오래된 데이터가 되지 않도록 특정 주기에 따라 재검증을 해주어야한다. 재검증: 캐시한 데이터의 원본 주인인 웹 서버가 설정한 특정 주기에 따라 캐시한 데이터가 오래됐는지 검증검증 방법: 조건부 요청 사용 = 재검증 기준이 되는 값을 앞으로 조건부 요청 2가지를 볼것임 (1. HTTP Cache 재검증, 2. CORS 요청 가능 여부 확인) 재검증 주기개발자들은 데이터의 갱신 특성에 따라 주기 설정재검증 기준캐시해놓은 데이터..