2021 05 08

2021-05-08¶

그림으로 배우는 Http Network Basic¶

5장. HTTP와 연계하는 웹 서버 - HTTP는 클라이언트와 서버 이외에 프록시/게이트웨이/터널과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능 - 프록시 - 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램 - Client <-> Proxy <-> Server - 캐시를 통한 네트워크 대역폭의 효율적 사용 - 조직 내에 특정 웹 사이트에 대한 액세스 정책 지키기 위함 - 게이트웨이 - 다른 서버 중계하는 서버로, 클라이언트로 부터 수신한 리퀘스트를 리소스를 보유한 서버인 것 처럼 수신 - 게이트웨이 너머의 서버가 HTTP 서버가 아닌 경우 사용 - Client <-> Gateway <-> Server (Http X) - 터널 - 서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속 주선 - 요구에 따라 다른 서버와의 통신 경로 확립 - SSL 같은 암호화 통신을 통해 안전하게 통신하기 위함 - Cache - 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스 사본 - 통신 시간 절약

6장. HTTP 헤더 - HTTP 프로토콜의 리퀘스트/리스폰스에는 반드시 메시지 헤더 포함 - Request: 메서드, URI, HTTP 버전, HTTP 헤더 필드 등으로 구성 - Response: HTTP 메시지, HTTP 버전, 상태 코드, HTTP 헤드 필드 등으로 구성 - 4종류의 HTTP 헤더 필드 1. 일반적 헤더 필드 - 리퀘스트/리스폰스 양쪽에서 사용되는 헤더 - Cache-Control: 캐싱 동작 지정 - Connection: 프록시에 더 이상 전송하지 않는 헤더 필드 지정, 지속적 접속 관리 - Date: 생성 날짜 - Pragma: 후방 호환성 - Trailer: 메시지 바디 뒤에 기술되어 있는 헤더 필드 미리 전달 - Transfer-Encoding: 전송 코딩 형식 지정 - Upgrade: 새로운 프로토콜으로의 전환 - Via: 리스폰스~리퀘스트 사이의 경로 - Warning: 경고 코드 2. 리퀘스트 헤더 필드 - 리퀘스트의 부가 정보와 클라이언트 정보, 리스폰스의 콘텐츠에 관한 우선 순위 등 추가 - Accept: 유저 에이전트에 처리할 미디어 타입과 미디어 타입의 상대적 우선 순위 - Accept-Charset: 유저 에이전트에서 처리할 수 있는 문자셋 우선 순위 - Accept-Encoding: 유저 에이전트가 처리할 수 있는 인코딩과 우선순위 - Accpet-Language: 처리할 수 있는 자연어 세트와 우선순위 - Authorized: 유저 에이전트의 인증 정보 전달 - Expect: 서버에 특정 동작 요구 - From: 유저의 메일 주소 전달 - Host: 리퀘스트한 리소스의 인터넷 호스트와 포트 번호 전달 - If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since: 조건부 요청 - Max-Forwards: 다음 서버에 리퀘스트 전송할 때 마다 1뺴면서 전송... 0되면 전송 X - Proxy-Authorization: 프록시 서버에서의 인증 요구 받아들인 때에 인증에 필요한 클라이언트의 정보 전달 - Range: 리소스의 일부분만 취득하는 범위 - Referer: 리퀘스트가 발생한 본래 리소스의 URI 전달 - TE: 리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선 순위 전달 - User-Agent: 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름을 전달하기 위한 필드 3. 리스폰스 헤더 필드 - Accept-Ranges: 일부를 반환하는 Range를 받아들일 수 있는 지 여부 전달 - Age: 얼마나 오래전에 오리진 서버에서 생성되었는지 - ETag: 일의적으로 리소스를 특정하기 위한 문자열 전달 - Location: 리스폰스의 수신자에 대해 리소스 액세스 유도 - Proxy-Authenticate: 프록시 서버에서 인증 요구를 클라이언트에게 전달 - Retry-After: 클라이언트가 일정 시간 후에 다시 시행하도록 전달 - Server: 서버에 설치된 HTTP 서버 SW를 전달 - Vary: 캐시를 컨트롤하기 위해 사용 - WWW-Authenticate: HTTP 엑세스 인증 4. 엔티티 헤더 필드 - Allow: 서버에서 사용가능한 method 전달 - Content-Encoding: 서버가 엔티티 바디에 대해 실시한 콘텐츠 형식 전달 - Content-Language: 엔티티 바디에 사용된 자연어 전달 - Content-Length: 엔티티 바디의 크기 - Content-Location: 메시지 바디에 대응하는 URI 전달 - Content-MD5: 메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해 생성된 값 전달 - Content-Range: 범위를 지정해 일부분만 리퀘스트 - Content-Type: 엔티티 바디에 포함되는 오브젝트의 미디어 타입 - Expires: 유효기간 - Last-Modified: 마지막 갱신 시간 - 쿠키를 위한 헤더 필드 - Set-Cookie - 리스폰스에서 전달 - NAME=VALUE: 쿠키에 부여된 이름과 값 - Expires=DATE: 쿠키 유효기간 - Path=PATH: 쿠키 적용 대상이 되는 서버 상의 디렉토리 - Domain=도메인 명: 쿠키 적용 대상이 되는 도메인 명 - Secure: HTTPS로 통신하고 있는 경우만 쿠키 송신 - HttpOnly: 쿠키를 JS에서 제어 못하도록 제한 - Cookie - 리퀘스트에서 전달 - status=enable

7장. 웹을 안전하게 하는 HTTPS - HTTP 약점 - 평문 통신이라 도청 가능 - 통신 상대 확인 안해서 위장 가능 - 완전성을 증명하지 않아서 변조 가능 - 해결 방안 - [평문 통신이라 도청 가능] - 통신 암호화 - SSL/TLS 프로토콜을 조합하여 HTTP의 통신 내용을 암호화할 수 있음 - 콘텐츠 암호화 - HTTP를 사용해 운반하는 내용을 암호화 (콘텐츠만 암호화) - [통신 상대 확인 안해서 위장 가능] - HTTP에서는 상대 누구인지 확인 안해서 누구든지 리퀘스트 보낼 수 있음 - 상대를 확인하는 증명서를 발급할 것 - SSL로 증명서 제공 - [완전성을 증명하지 않아서 변조 가능] - 수신한 내용이 실제 내용과 다를 수도 있음 - 공격자가 도중에 리퀘스트/리스폰스 뻇어 변조 (Man-in-the-Middle) - 변조 방지를 위해 HTTPS를 사용하자 (HTTP + SSL) - HTTPS - 서버나 클라이언트 인증 수단이 HTTP에는 X - HTTP는 SSL과 통신, SSL이 TCP와 통신 - private key - public key - public key를 통해 암호화한 정보를 받아들여, 자신의 private key로 복호화 - 많은 브라우저가 주요 인증 기관의 공개키를 사전에 내장한 상태로 제품 내놓음 - 안전한 통신을 하는 HTTPS의 구조 - SSL & TLS - SSL: 보안 소켓 계층을 이르는 말로, 인터넷에서 데이터를 안전하게 전송하기 위한 인터넷 통신 규약 프로토콜 - TLS: SSL의 뒤를 잇는 표준

8장. 누가 액세스하고 있는지 확인하는 인증 - HTTP 인증 방법
- BASIC 인증 - BASE64 인코딩 - 보안 등급 LOW, 안씀 - DIGEST 인증 - 서버가 준 챌린지 코드를 이용해 상대에게 리스폰스 보냄 - SSL 클라이언트 인증 - HTTPS의 클라이언트 인증서를 이용한 인증 방식 - FORM 베이스 인증 - 웹 애플리케이션에서 제각각 구현하는 폼 베이스 인증을 채용 - 세션 관리와 쿠키에 의한 구현

9장. HTTP에 기능을 추가한 프로토콜 - HTTP 에서는 서버 상의 정보가 갱신되지 않은 경우, 불필요한 통신 발생 - HTTP 병목 발생 - Ajax, Comet으로 해결 - SPDY의 등장 - HTTP라는 프로코톨 사용하는 이상, 병목 현상 해결 어려움 - WebSocket은 새로운 프로토콜과 API에 의해 이 문제 해결 - 웹 서버~클라이언트가 접속 확립하면, 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON,XML,HTML,이미지 등의 데이터 보내줌 - 서버 푸시 지원 - 통신량 삭감 - 핸드쉐이크/리퀘스트 (Upgrade) - 핸드쉐이크/리스폰스 (101 Switching Protocol)

10장. 웹 콘텐츠에서 사용하는 기술 - 동적 HTML - 정적인 HTML 내용을 클라이언트 사이드 스크립트를 사용해서 동적 변경 - CGI - 웹 서버가 클라이언트에서 리퀘스트를 프로그램에 전달하기 위한 구조 - 서블릿 - 서버 상에 HTML 등의 동적 콘텐츠 생성하기 위한 프로그램 - 서블릿은 웹 서버와 같은 프로세스 속에서 동작하기에 부하를 적게하여 동작시킬 수 있음 - 서블릿의 실행 환경을 컨테이너 혹은 서블릿 컨테이너라고 부름 - RSS/Atom으로 갱신 정보 송신

11장. 웹 공격 기술 - HTTP 구조의 단순함 떄문에 여러 보안 문제 발생 - 공격 패턴 - 능동적 공격 - 공격자가 직접 웹 애플리케이션에 액세스해서 공격 코드 보내는 타입 - 수동적 공경
- 유저에게 공격 코드를 실행시키는 공격 - 출력 값의 이스케이프 미비로 인한 취약성 - 크로스 사이트 스크립팅 - 취약성이 있는 웹 사이트를 방문한 사용자의 바르우저에서 HTML, JS를 오작동 시키기 - SQL 인젝션 - 데이터베이스에 SQL을 부정하게 실행하는 공격 - OS 커맨드 인젝션 - OS에서 사용되는 커맨드를 쉘을 경유해서 실행 - HTTP 헤더 인젝션 - 공격자가 리스폰스 헤더 필드에 개행 문자 등을 삽입 - 바디를 추가 - 메일 헤더 인젝션 - 메일 헤더를 부정하게 추가 - 디렉토리 접근 공격 - 비공개 디렉토리 파일에 대해 Path 통한 접근 (../../) - 리모트 파일 인클루션 - 스크립트의 일부를 다른 파일에서 읽어올 때 공격자가 지정한 외부 서버의 URL을 파일에서 읽게 함 - 웹 서버의 설정이나 설계 미비로 인한 취약성 - 강제 브라우징 - 웹 서버의 공개 디렉토리에 있는 파일중, 공개 의도가 없는 파일이 열람되는 것 - 부적절한 에러 메시지 처리 - 에러 처리가 사용자 웹 앱에 그대로 노출 - 오픈 리다이렉트 - 리다이렉트 되는 곳이 악성 웹 사이트 - 세션 관리 미비로 인한 취약성 - 세션 하이잭 - 유저의 세션 ID 입수해 악용 - 세션 픽세이션 - 공격자가 지정한 세션 ID를 유저에게 강제적으로 사용하게 하는 것 - 크로스 사이트 리퀘스트 포저리 - 인증된 유저가 상태 갱신 처리를 강제로 실행시킴 - 기타 - 패스워드 크래킹 - Password 논리적으로 이끌어내서 인증 돌파 - 네트워크 경유로 패스워드 후보 시험해보기 - Brute-force - Dictionary-attack - 암호 해독 등 - 클릭 재킹 - 투명한 버튼이나 링크를 함정으로 사용할 웹 페이지 심어두고, 유저에게 링크 클릭토록 함 - DoS 공격 - 서비스 제공을 정지 상태로 만들기 - 백도어 - 정규 절차 안밟고 서비스 사용하는 뒷문 - 정상 이용과 구별 어려워 발견 어려움

어노테이션¶

설명 - Java5 부터 추가된 기능 - 클래스나 메서드 위에 붙여 사용 ex)@Override - 소스코드에 메타코드(추가정보)를 주는 것 - 실행될 때, 어노테이션의 설정 값에 따라 클래스가 조금 다르게 동작 - 일종의 설정 파일처럼 설명하기도 함 - 사용자 정의 가능 (커스텀 어노테이션) - 자바 어노테이션은 코드에 붙일 수 있는 특별할 Comment - 자바 컴파일러에 instruction 삽입 - processing tool에 instruction 삽입 - 자바 애플리케이션이나 third party tool에서 런타임에 읽을 수 있는 meta data - Spring - Jackson - 어노테이션은 여기저기 다 붙일 수 있음 - 클래스 - 인스턴스 변수 - 생성자 - 매개변수 - 지역변수 - 메서드 - 하지만 이 중 하나의 곳에서만 쓰도록 설계

Bullt-in Java Annotation - 자바 컴파일러에게 알려줌 - @Override - 서브 클래스에서 수퍼 클래스의 메서드 오버라이딩 함 - @Depreciated - No Longer Use It! - 다른 메서드 찾아보세요~ - @SuppressWarnings

커스텀 어노테이션 - 필요성 - As passive documentation in code - 기능이 없을 수도 있음 - 그냥 문서화를 도와줌 - As input for a Java source code processor - 자바 소스코드 읽고, 자바 어노테이션을 통해 무엇을 하나 봄 - As input for a Java Library that accesses your annotations at runtime via Java Reflection - 자바 라이브러리를 구축할 때 - 클래스에 정보 주입 시킬때 - Spring, Jackson, Hibernate에서 사용

블로그 참고 - 참고 1: https://coding-factory.tistory.com/575 - 참고 2: https://honeyinfo7.tistory.com/56 - 자바 소스 코드에 추가하여 사용하는 메타데이터의 일종 - 클래스 파일에 임베디드 되어 컴파일러에 의해 생성된 후, JVM에 포함되어 동작 - 컴파일 과정과 실행 과정에서 코드를 어떻게 컴파일하고 처리할 것인지 알려주는 정보 - 어노테이션 사용처 1. 컴파일러에게 코드 문법 에러 체크하도록 정보 제공 2. SW 개발 툴이 빌드나 배치 시 코드 자동 생성토록 정보 제공 3. 실행 시 특정 기능을 실행토록 정보 제공 - 어노테이션은 Reflection을 사용하는 방법을 통해 어노테이션 값 활용 - 어노테이션 정보를 얻기 위한 메서드

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface MyAnnotation {
    String value() default "-";
    int number() default 15;

}

public class MyService {
    @MyAnnotation
    public void method1() {
        System.out.println("실행내용1");
    }

    @MyAnnotation("*")
    public void method2() {
        System.out.println("실행내용2");
    }

    @MyAnnotation(value = "*", number = 20)
    public void method3() {
        System.out.println("실행내용3");
    }
}

public class MyMain {
    public static void main(String[] args) {
        Method[] methodList=MyService.class.getMethods();

        for(Method m : methodList) {
            if(m.isAnnotationPresent(MyAnnotation.class)) {
                System.out.println(m.getName());
                MyAnnotation annotation = m.getDeclaredAnnotation(MyAnnotation.class);

                String value=annotation.value();
                int number=annotation.number();
                for(int i = 0 ; i < number ; i++) {
                    System.out.print(value);
                }
                System.out.println();               
            }
        }
    }
}

/*
[결과]
method2
***************
method3
********************
method1
--------------
*/

질문 - 어노테이션도 클래스이네...? - 애초에 왜 필요했을까? 그냥 클래스로 하면 안되나? - 뭐야..? 매개변수 받아서 뭐 어쩐단 거야?