cleanUrl: /data-intensive/encoding-and-evolution
애플리케이션은 시간이 지나면서 점점 변한다. 이 변화에 DB의 변화도 포함되고 column, field 가 추가되거나 삭제되며, data type이 변경되기도 한다.
이러한 DB 관점의 변경은 바로바로 적용된다. 하지만, application의 코드는 대체로 바로 적용되지 않는다.
application code 가 바로 적용되지 않는 이유
- code 의 update 방식은 rolling update(stage rollout) 으로 갱신된다.
- client 의 경우 사용자에게 달려있다. 종종 업데이트를 하지 않는 유저도 있기 때문이다.
이러한 이슈에도 불구하고 변경된 데이터에 시스템이 원활하게 실행되려면 양방향으로 호환성을 유지해야 한다.
- 호환성
- 하위 호환성
- 새로운 코드는 예전 코드가 기록한 데이터를 읽을 수 있어야 한다.
- 새로운 코드는 기존 데이터에 대해 알기 때문에 큰 문제가 없을 수 있다.
- 상위 호환성
- 예전 코드는 새로운 코드가 기록한 데이터를 읽을 수 있어야 한다.
- 새 버전의 코드에 의해 추가된 것을 무시할 수 있어야 하므로 더 어렵다.
- 우리같은 back end 개발자들은 상위 호환성을 고려해야할까? 아무래도 우리 상황에선 생소한 개념인것 같다 (계속 햇갈림 ㅠ)
데이터 부호화 형식 - Formats for encoding Data
- 프로그램은 보통 최소 두가지 형태로 표현된 데이터를 사용해 동작한다.
- 메모리 객체(object), 구조체(struct), list, array, hash table, tree
- 이러한 데이터 구조는 CPU 에서 효율적으로 접근하고 조작할 수 있도록 (포인터를 이용해) 최적화 된다.
- 파일에 쓰거나 네트워크로 전송할때 json 과 같은 타입으로 encoding (부호화) 해야한다.
- pointer 는 다른 프로세스가 이해할 수 없다.
- 바이트열은 메모리에서 사용하는 데이터 구조와 상당히 다르다
서로 다른 두 타입을 메모리에서 byte로 변경하는 것을 부호화(encoding, serialization or marshalling)이라 하고, 반대를 decoding(parsing, deserialization, unmarshalling) 이라 한다.
<aside>
💡 직렬화 라는 단어가 더 직관적일지라도 transaction 맥락에서도 사용되기 때문에 단어의 중복을 피하기 위해 여기서 사용하지 않는다.
</aside>
언어별 형식 Language-Specific Formats
언어에서 인코딩을 위한 기능이 제공된다. java.io.Serializable
쉽게 인메모리 객체를 저장하고 복원하지만, 심각한 문제점이 많다.
- 다른 언어에서 표현된 데이터를 읽는것은 시스템 통합에 방해가 되기 때문에 각 시스템으로 전송할때 부호화를 수행한다.
- 데이터를 복원하기 위해 복호화 프로세스는 임의의 class를 instance화 할수 있어야 한다. 그런데 이는 보안 문제에 연관되기도 하는데 임의의 인스턴스를 생성하여 원격으로 특정 코드를 실행시킬 수 있기 때문이다.
-
CWE-502: Deserialization of Untrusted Data
CWE - CWE-502: Deserialization of Untrusted Data (4.3)
- 인스턴스 생성에 어떠한 제약이 없다면 공격자가 어떠한 공격을 코드에 심어 실행시킬 수 있다.
-
What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.
What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.
구체적인 예시를 들어 설명하는데 바이트 코드에 추가 코드를 삽입하여 deserialization 과정에서 특정 코드를 실행하도록 만든다.