웹에서의 Proxy

동일 출처 정책(Same Origin Policy)

기본적으로 브라우저는 동일 출처 정책(Same Origin Policy)를 따른다.

⇒ 서로 다른 도메인에서 자원을 공유하는 것을 금지한다.

⇒ CSRF, XSS와 같은 보안 취약점을 노린 공격을 방어하기 위함

• Origin, CSRF, XSS ?
  • Orgin(출처)? URL 구조에서 살펴본 Protocol, Host, Port를 합친 것
  • CSRF(사이트 간 요청 위조) - 특정 작업을 무단으로 진행 (ex-계정 정보 변경)
  • XSS(사이트 간 스크립팅) - 웹사이트에 악성스크립트를 주입 (ex-사이트 변조, 세션 탈취)
    

CORS(Cross-Origin-Resource Sharing)

서로 다른 출처 간에 자원을 공유

그럼 프론트엔드와 백엔드의 출처가 다른데 어떻게 통신하나?

( 리엑트 기본 port - 3000, 스프링부트 기본 port - 8080 )

→ 그냥 통신하면 SOP를 어겨 CORS 오류가 나타난다.

→ 대리자(Proxy)를 세우자

---

프록시(Proxy)

Ref: https://inpa.tistory.com/entry/NETWORK-📡-Reverse-Proxy-Forward-Proxy-정의-차이-정리

일반적인 웹은 클라이언트 ↔ 서버간 통신을 통해 데이터를 전달한다.

이때 필연적으로 중복되는 데이터를 전달하는 상황이 발생하는데,

이런 리소스 낭비와 서버의 부하를 중간에 프록시 서버를 배치하여 방지한다.

• 클라이언트 입장 : 빠른 속도와 서비스
• 서버 입장 : 불필요한 부하 감소

특징

• 캐싱(Caching)
  • 포워드 프록시의 경우 어떤 웹 페이지에 접근하면 프록시 서버는 해당 페이지 서버의 정보를 캐싱(임시보관)한다. → 똑같은 페이지에 접근하거나 다른 클라이언트가 요청할 때 캐싱된 정보를 그대로 반환
    
  • 리버스 프록시의 경우 클라이언트(한국) - 리버스 프록시(한국) - 웹서버(미국)이라고 가정했을 때, 클라이언트는 한국의 리버스 프록시 서버와 통신하여 캐싱된 데이터를 사용해 더 빠른 성능을 보여줄 수 있다.
    
• 암호화(Encryption)
  • 포워드 프록시의 경우 → 클라이언트의 요청이 암호화되어 클라이언트의 IP를 감춰준다.
    
  • 리버스 프록시의 경우 → 본래 서버가 클라이언트와 통신할 때, SSL로 암호화하는 경우 비용이 높지만 리버스 프록시가 요청 암호화/응답 복호화를 하여 서버의 부담이 줄어든다.
    
• 보안(Security)
  • 포워드 프록시의 경우 ( 클라이언트 보안 ) 방화벽과 같은 개념으로 제한을 위해 사용된다. 포워드 프록시 서버에 룰을 추가해서 특정 사이트에 직접 접속하는 것을 막을 수 있다.
    
  • 리버스 프록시의 경우 ( 서버 보안 ) 본래 서버의 IP 주소를 노출시키지 않을 수 있다.
    

---

프록시 서버는 누구의 대리인인가, 어느 방향으로 데이터를 제공하느냐에 따라

포워드 프록시, 리버스 프록시로 나뉜다.

1. 포워드 프록시 (Forward Proxy)

                클라이언트 입장에서의 대리자

일반적으로 프록시 서버라 하면 포워드 프록시이다.

Ref : https://velog.io/@lsx2003/CS-React-리액트-Proxy-사용하기

백엔드 입장에선 프론트엔드가 클라이언트

프록시가 클라이언트임을 숨기고 통신한다 → CORS를 통과할 수 있다.

= 서버는 클라이언트가 누구인지 알 수 없다.

• 리액트에서의 프론트 프록시 구현 package.json에 "proxy" : "http://localhost:4000"와 같이 요청을 보내는 서버의 도메인 주소를 설정하면 기능한다.
  

2. 리버스 프록시

	서버 입장에서의 대리인
	서버가 여러 대인 경우, 포트 주소가 달라서 클라이언트가 요청을 하기 어렵다

클라이언트의 요청은 리버스 프록시 서버를 경유하여 리버스 프록시가 할당해준 서버로 전송된다.

(클라이언트는 각 서버의 주소에 대해 알 필요가 없다)

= 본 서버의 주소 정보를 숨길 수 있음.

• 역할

  1. 로드 밸런싱(부하 분산)

     로드 밸런서 :

     대용량 트래픽을 장애 없이 처리하기 위해 여러 대의 서버에 적절히 트래픽을 분배

     → 어느 Client가 요청하던 Request를 여러 대의 서버에 나눠서 분배

     • 세션 관리에 문제 발생 가능성이 생김.

       요청자 "ㄱ"이 로그인 요청을 보냄

       → A서버가 받아서 처리 이후, 새로운 요청을 전송

       → C서버가 전달받았는데 C서버의 세션에는 로그인 정보가 없음

       이에 대한 해결 방안은?
       

  2. Health check(보낼 서버가 살아있는지 체크)

     특정 웹 서버가 다운되거나, 정상적인 서비스가 불가능한 상태라면,

     그 서버가 정상적인 상태가 되기 전에는 로드 밸런서가 트래픽을 보내서는 안 된다.

• Nginx를 통해 구현한다.