웹 아키텍처 분석

웹 아키텍처

• 일반적인 웹 아키텍처는 클라이언트, 웹 서버, 데이터베이스의 형태로 되어 있다.
• 영역 별로 프론트 엔드(Front-End)와 백 엔드(Back-End)로 나뉜다.
• 그리고 오늘날의 웹 개발자들은 크게 프론트 엔드 개발자, 백 엔드 개발자, 이 둘을 전부하는 풀 스택 개발자로 나뉜다.

웹 아키텍처 동작 원리 분석

• 클라이언트 측에서 사용자가 웹 브라우저를 통해서 사이트 접속을 하게 된다.
• 그러면 웹 브라우저에서는 가장 먼저 도메인에 따른 IP 변환 작업을 한다.
• 이유는 데이터 전송을 위해서는 IP가 반드시 필요하기 때문이다.
• 이후에 요청 메세지를 제작한다.
• HTTP 프로토콜은 TCP/IP 통신을 기반으로 하기 때문에 TCP 연결의 특징인 3-way hand shake 과정을 거친 후 HTTP 데이터를 전송하게 된다.
• 요청에 따른 DB 연결 및 질의 과정을 거치며, 이에 따라 응답 메세지를 제작 후 전송을 한다.
• 응답 메세지를 받으면 이를 해석 한 후에, 바디에 있는 데이터인 HTML 코드를 웹 브라우저가 해석을 하여 사용자에게 깔끔한 인터페이스를 제공하게 된다.

클라이언트

• 클라이언트 프로그램은 대표적으로 웹 브라우저가 있으며, 그 종류로는 인터넷 익스플로러, 크롬, 사파리, 파이어 폭스 등이 있다.
• 웹 브라우저는 사용자가 입력한 URL을 이용해 서버에 자원을 요청하고, 서버로부터 응답을 받아서 해석 후 사용자에게 GUI 환경을 제공한다.

웹 사이트 구조 분석

• 웹 사이트 구조는 HTML, CSS, JAVASCRIPT 3요소로 구성이 되어 있다.
• 웹에 가독성 있는 인터페이스를 구성하기 위해 HTML, CSS가 사용되며 동적인 인터페이스 구성을 위해 JAVASCRIPT가 사용된다.
• 아래와 같은 일반적인 웹 사이트 구조는 웹 서버와 통신을 위해 HTML 태그를 사용하거나 JAVASCRIPT를 통해 통신이 가능하다.
• 오늘 날의 웹 사이트 구조는 이전의 구조에 비해 큰 변화를 가지고 있다.
• 바로 Ajax라는 기술로써 페이지 동기화 필요없이 서버에 요청/응답을 받아 페이지 재구성(렌더링)이 가능해졌다.
• 기존 웹 패러다임을 전환하는 기술로써 현재 많이 사용되고 있다.
• 또한, 백 엔드 측에 부하율을 낮출 수 있기 때문에 트래픽이 많이 발생되는 웹 사이트의 경우 Ajax기술을 적극적으로 사용하고 있다.

Ajax 기반 웹 사이트 진단

• Ajax 기반의 웹 사이트라고 해서 진단 방법이 달라지는 것은 아니다.
• 요청과 응답의 행위는 동일하게 때문이다.
• 그러나 이 과정에서 컨텐츠 타입(Content-Type)이 달라 당황하는 경우가 있는데 전혀 그럴 필요가 없다.
• 응답 컨텐츠의 경우 HTML이 아닌 xml, json 타입이라도 인터페이스를 구성하는 데이터로 사용되기 때문에 JAVASCRIPT를 분석 후 알맞게 데이터 변조를 하면 된다.

웹 서버 그리고 웹 어플리케이션 서버

• 웹 서버는 클라이언트 자원 요청에 따른 웹 서비스를 제공한다.
• 웹 서버의 종류는 아파치, IIS, Nginx, WebtoB, IBM, Oracle HTTP Server가 있다.
• JAVA Web Application 환경의 경우 웹 서버와 웹 어플리케이션 서버를 분리하여 웹 서버는 정적인 컨텐츠 자원 제공을 담당한다.
• 웹 어플리케이션 서버는 동적인 컨텐츠 자원 제공을 담당한다.
• 이를 통해 보다 효율적이며 유연한 서비스 제공을 목표로 한다.

웹 서버 동작 원리 분석

• 클라이언트 측에서 웹 서버에 요청 메세지를 보내면 웹 서버는 이를 요청된 자원 유/무를 검토하여 클라이언트 측에 응답 메세지를 실어서 보낸다.
• 이때 웹 서버 측에서는 어떤 동작 원리로 클라이언트가 요청한 자원을 호출할까?
  1. 먼저 요청 메세지가 오게 되면 최초의 웹서버는 요청 메세지 해석을 하게 된다.
  2. 메소드 파싱을 하게 되고, URL 파싱, 메소드에 따른 액션을 한다.
  3. 여기서 GET, POST 처럼 일반적인 자원 요청 관련된 메서드를 사용을 하게 될 경우에는 자원 유무를 체크하게 된다.
  4. 그러면 특정 파일 시스템에 자원이 있을 경우에는 객체 생성을 한다.
  5. 그 다음에는 해당 자원이 동적인지 정적인지를 구분하게 된다. 왜냐하면 행위가 달라지기 때문이다.
  6. 정적인 자원인 경우에는 스크립트 해석기 즉, 서버 사이드 스크립트에 대한 해석이 필요가 없기 때문이다.
  7. 반면에, 동적인 자원은 스크립트 해석기 즉, 서버 사이드 스크립트에 대한 해석이 필요하기 때문이다.
  8. 그래서 이러한 자원에 따라 구분을 해주게 되고 그 뒤에 결과를 반환한다.
  9. 반환 받은 결과를 토대로 이제 응답 메세지를 제작하고 그 다음엔 클라이언트쪽으로 전송을 하게 된다.
  10. 그러면 어떠한 기준으로 index.jsp를 호출했는데 어떠한 기준과 어떠한 경로에서 찾게 되는 것일까?
  11. 이러한 것은 웹 서버, 웹 어플리케이션 설정 정보를 보게 되면 웹 디렉토리 혹은 웹 루트, 도큐먼트 루트 등의 경로가 설정되어 있다.

웹에서 호출할 수 있는 자원이 있는 웹 디렉토리

• 우리가 URL로 서버에 자원을 요청하는 것들은 웹 서버에 어떠한 설정된 경로로 인해 가능하다.
• 이렇게 웹 서버에서 바라보는 경로를 웹 디렉토리, 웹 루트, 웹 도큐먼트 루트 등으로 부른다.
• 이러한 설정 파일들은 파일 다운로드/업로드 취약점 공격 시 많이 활용된다.
• 만약 여기에 자원이 없게 되면 당연히 404 Not Found의 응답값을 받을 것이다.

JAVA Web Application 환경의 3 - tier 구조 동작 원리

• 사용자 <-> 인터넷 구간 <-> 웹 서버 <-> 웹 어플리케이션 서버 <-> 데이터베이스
• 정적인 자원을 요청할 경우에 웹 서버에서 웹 어플리케이션 서버까지 가지 않고, 웹 서버에서 바로 요청에 대한 처리를 하고 응답을하게 된다.
• 동적인 자원을 요청할 경우에는 다시 웹서버에서 웹 어플리케이션 서버로 포워딩을 하게 된다.
• 그리고 로직에 따라 데이터베이스에 질의를 하고 응답메세지를 제작한 후 뿌려준다.

JAVA Web Application 환경의  WS/WAS 구성

• 웹 서버와 웹 어플리케이션은 하나의 서버에 구성되어 있는 경우가 있으나, 대부분의 기업은 물리적으로 분리한다.(논리적 vs 물리적)
• 대부분 하나의 회사에서 제공되는 웹 서버와 웹 어플리케이션 서버를 쌍으로 사용한다.
• 가격면이나 유지보수 등 대응면에서 훨씬 효율적이기 때문이다.

웹 서버	웹 어플리케이션 서버
Apache	Tomcat(무료)
WebtoB(TMAX)	JEUS(TMAX)
Oracle HTTP Server(Oracle)	Weblogic(Oracle)
IBM HTTP Server(IBM)	WebSphere(IBM)
Apache, Nginx	Jboss(Redhat)
Nginx	Tomcat

 

WAS는 정적인 자원을 처리하지 못할까?

==> 처리 가능하다.. 그러면 왜 굳이 분리를 해둔 것일까..???

웹 서버와 웹 어플리케이션 서버를 분리하는 이유

• 웹 서버는 정적 자원 처리에 대한 최적화가 되어 있고, 웹 어플리케이션 서버는 동적 자원 처리에 최적화가 되어있다.
• 업무 분담을 하여 자원처리에 대한 효율성을 극대화 시킨다.

데이터베이스

• 동적인 컨텐츠를 제공하기 위해 데이터를 저장해두는 저장소로 일반적으로 사용자 정보, 상품 정보, 커뮤니티 정보 등 수많은 정보들이 저장되는 곳이다.
• 예를 들어 게시판에 글을 쓰고 보고, 회원 가입을 하여 로그인을 할 수 있는 이유도 데이터베이스 때문이다.

Server Side와 Client Side에 대한 이해

• 웹 구조는 크게 Server Side와 Client Side로 나눌 수 있다.
• 웹 클라이언트에서 해석되는 스크립트(언어)를 Client-Side Script라고 한다.
• 웹 어플리케이션 서버에서 해석되는 스크립트(언어)를 Server-Side Script라고 한다.

Client-Side Script 기반 보안 검증이 안전하지 않은 이유

• 클라이언트 측에서 보안 검증 절차가 구현(JAVASCRIPT로 구현)되어있다 하더라도 서버 측 보안 검증 로직을 반드시 구현해야 한다.
• 웹 프록시 도구와 개발자 도구를 통해 Client-Side Script 조작 및 값 변조가 가능하기 때문이다.
• 사실살 검증 자체가 무의미하다. 뿐만 아니라 input 태그의 hidden 타입의 전송도 웹 프록시 도구 혹은 개발자 도구로 확인할 수 있다.
• 따라서 변조가 가능하기 때문에 해당 값을 신뢰해서는 안된다.