HTTP/2: The Sequel is Always Worse : Back Hat USA와 DEF Con에서 발표한 연구 논문을 정리한 글로 HTTP/2가 바로 도입할 수 있는 프로토콜로 많이들 생각하지만, RFC의 불완전성이나 구현 결함으로 인해서 발생하는 HTTP/2에서의 공격 위협을 설명하고 있다.(영어)
프론트엔드 서버가 HTTP/2로 받아서 백엔드 서버로 보낼 때는 HTTP/1.1을 사용하는 경우 요청 길이를 Content-Length 헤더에서 파싱할 때 Transfer-Encoding 헤더에서 파싱할지 합의하지 않았기 때문에 발생한다. 이를 이용해서 요청의 길이를 착각하게 만들어서 공격자가 임의의 문자열을 요청에 넣을 수 있다.
프론트엔드 서버가 백엔드에 연결할 때 기존 연결을 사용할지 다시 새로 연결할지 정해야 하는데 기존 연결을 재사용할 때 터널링을 악용해서 공격에 필요한 정보를 알아내거나 캐시 중독을 일으킬 수 있다.
HTTP/2가 method나 path가 헤더에 있기 때문에 이를 중복해서 보내는 경우에도 허용하는 등의 HTTP/2가 가진 취약점
WebAssembly with Golang by scratch : Go 언어를 이용해서 간단한 WebAssembly를 작성하는 예제이다. 코드는 Hello World를 출력하는 정도이지만 Go로 작성한 코드를 컴파일해서 HTML 페이지와 연동해서 불러오는 방법을 보여주고 있다.(영어)
그 밖의 개발 관련
GitHub’s Engineering Team has moved to Codespaces : GitHub의 엔지니어링 팀이 GitHub.com의 개발 환경으로 GitHub의 Codespaces로 갈아탔다고 한다. Codespaces는 VS Code를 이용해서 클라우드 개발환경을 제공하는 GitHub의 기능이다. 이전에는 로컬의 macOS 환경에서 GitHub.com을 개발하고 있었고 개발환경을 설정하기 위해서 스크립트를 이용하고 열심히 관리했지만 자주 깨지고 유지하기가 쉽지 않았다. 다른 컴퓨팅 환경처럼 개발환경도 쉽게 띄우고 교체할 수 있는 환경으로 넘어가기 위해 Codespaces를 도입하기 시작했고 로컬에서 45분 걸리던 개발환경 설정을 5분으로 줄였다고 한다. GitHub.com의 코드 베이스가 너무 커서 shallow 클론을 진행하고 나이틀리 빌드로 devcontainer를 미리 만들어 놓고 사용하면서 5분까지 줄였으나 여기서 더 개선하기 위해 사전빌드를 진행해서 10초까지 줄였다고 한다. 이제 새 직원이 와도 10초 만에 개발환경을 띄울 수 있게 되었고 VM의 리소스 한 줄만 바꾸면 모든 개발자가 더 좋은 컴퓨팅 환경에서 개발할 수 있게 되었다고 한다.(영어)
GitHub Codespaces GA : 작년부터 클로즈 베타로 진행되던 Codespaces가 드디어 모두가 사용할 수 있도록 공개되었다. Codespaces가 유료임에도 GitHub의 Team이나 Enterprise Cloud 플랜을 사용하는 사람이자 조직만 Codespaces를 사용할 수 있다. Codespaces를 사용하려면 org 설정에서 활성화를 해주어야 하고 사용한 만큼 비용을 지불하는 구조이지만 9월 10일까지는 trial 기간으로 비용을 받지 않는다고 한다. 그리고 새로운 숏컷이 생겨서 GitHub.com의 저장소에서 .을 누르면 Codespace가 열린다.(영어)
SAML is insecure by design : single-sign on에 사용하는 표준인 SAML(Security Assertion Markup Language)이 왜 보안에 취약한지를 설명한 글이다. SAML이 서명에 사용하는 XML이 로우 데이터를 그대로 사용하지 않고 XML을 정리해서 다시 사용하기 때문에(예를 들어 불필요한 부분을 지우고 정돈된 XML로 만들어서) 공격자가 이를 이용해서 XML을 조작해도 서명을 동일하게 만들어서 공격할 수 있다고 설명하고 있다. 이는 XML의 서브 트리를 잘 다루기 위해서 이렇게 설계한 것으로 보이지만 이 때문에 보안에 취약해졌고 이를 최소화하려면 그냥 서명 검증뿐 아니라 라운드 트립 안전성 검사, XML 파싱, XML 캐노니컬라이제이션을 해주어야 한다고 한다.(영어)
FIDO at LINE: FIDO2 서버를 오픈 소스로 공개했습니다 : FIDO는 패스워드 없이 인증을 할 수 있게 하는 표준인데 Line에서 FIDO2 서버를 오픈소스로 공개했다. FIDO에는 생체인증이나 PIN 등으로 인증하는 UAF와 인증키가 포함된 하드웨어로 추가 인증하는 U2F, 이 둘을 통합해서 개선한 FIDO2가 있는데 FIDO2는 다양한 웹브라우저에서 지원하고 있기 때문에 FIDO2로 자리 잡는 분위기라고 한다. FIDO Alliance에서 상호 운용성 테스트를 진행해서 표준 준수 여부를 인증해 주는데 이 과정을 통해 테스트에 통과하고 그 결과물인 FIDO2 서버를 오픈소스로 공개한 것이다.(한국어)
GitHub 프로필을 iMessage 대화 메시지로 꾸며보기 : GitHub에서 자신의 프로필 페이지를 원하는 대로 꾸밀 수 있는 프로필 저장소 기능을 이용해서 프로필 페이지에 iMessage 형식으로 대화하듯 인사말과 날씨 들을 보여주는 기능을 구현하는 과정을 설명한다. 프로필에서 스크립트 등을 원하는 대로 사용할 수는 없으므로 액션을 이용해서 SVG로 생성해서 보여주는 과정을 거치게 되는데 해당 기능을 원래 구현했던 개발자의 소스를 참고해서 이 기능이 어떻게 구현되는지 설명한다. 다양한 프로필 아이디어가 있는데 꽤 잘 만들어진 프로필이다.(한국어)
Git Force vs Force with Lease : git push를 할 때 --force를 써야 할 때 더 안전한 --force-with-lease를 쓰라는 글이다. --force는 리모트 브랜치를 망가뜨릴 수도 있으므로 다른 브랜치에 리베이스하거나, 이전 커밋 메시지를 바꾸거나 합치거나 순서를 바꾸는 등의 작업을 할 때는 --force-with-lease로도 충분하므로 꼭 필요할 때만 --force를 쓰라고 하고 있다.(영어)
인프라 관련
패킷 덤프를 통해 확인하는 ALB와 NLB의 차이점 (1) - ALB 동작 원리, (2) - NLB 동작 원리 : AWS의 대표적인 ALB와 NLB를 서버와 클라이언트에서 직접 패킷 덤프를 보면서 뭐가 다른지 비교하면서 설명하는 글이다. 이렇게 차근차근 설명하면서 보여주기 때문에 ALB가 L7에서 동작하고 NLB가 L4에서 동작한다는 게 무슨 의미인지 이 때문에 어떤 차이가 생기는지 이해하기 좋다.(한국어)
Introducing the AppSource Controller for ArgoCD : ArogoCD의 애플리케이션은 어드민이 각각 만들어주어야 하는데 여러 애플리케이션을 만들어야 할 때 app-of-apps 구현이나 ApplicationSet CRD를 많이 이용하고 있었다. 하지만 이 두 방법도 중앙화된 방법이므로 어드민의 개입 없이 개발자가 직접 관리할 수 있게 하는 AppSource 프로젝트를 공개했다. AppSource 컨트롤러를 이용하면 어드민은 사용자가 네임스페이스 내에서 ArgoCD 앱을 배포하도록 해서 개발자가 직접 앱을 배포할 수 있다.(영어)
Applying flame graphs outside of performance analysis : grame graph는 성능 분석에는 자주 사용하지만 그 외에는 별로 사용되지 않았는데 트위터에서 매트릭 분석에 frame graph를 사용한 사례이다. Twitter 내부의 매트릭 수집은 매년 30~40%씩 증가하고 있었는데 최근에는 이 증가속도가 더 커지게 되어 분석을 시작했고 매트릭을 서비스의 어떤 기능이 가장 많이 보내고 있는지, 어떤 매트릭 키스페이스가 많은 매트릭을 생성했는지 알기 위해 frame graph를 적용했고 쉽게 어떤 매트릭 키스페이스가 큰지 찾을 수 있었다고 한다. 이 분석으로 가장 큰 서비스 중 하나인 광고팀의 매트릭을 33% 줄였다고 한다.(영어)
볼만한 링크
Agile at 20: The Failed Rebellion : 애자일 소프트웨어 개발 선언이 20년이 지난 지금 애자일이란 용어는 성공했지만, 실제 실행은 잘 안 되고 있다고 평가하는 글이다. GeekNews에 잘 요약되었으니 원문을 읽기 힘들면 요약문을 읽는 것도 좋다. 애자일 선언이 발표되고 각 회사에 도입되기 시작했지만, 창시자들이 생각한 방향으로 진행되진 않았고 오히려 오해도 많이 만들게 되었다. Ron Jeffries나 Dave Thomas는 애자일에 회의적인 글을 쓰기도 했다. 마지막에 가장 슬픈 일이 젊은 개발자가 Agile을 폄하하고 경영진이 개발자를 압박하는 수단으로 본다는 부분에 동의가 되었고 그런데도 애자일 선언의 원칙은 20년이 지난 시점에서도 현명하고 적절하다고 하는 부분에 오랜만에 애자일 선언에 관해 다시 곱씹어 보게 되었다.(영어)
정부의 웹사이트 총량제는 코로나19 방역을 어떻게 방해하나 : 정부의 웹사이트 총량제라는 게 있어서 한 기관은 하나의 공식 사이트만 사용해야 하고 기관의 명칭이 바뀌면 영어 명칭 규칙에 따라 사이트를 바꿔야 한다고 한다. 이 때문에 질병 관리청이 기존 cdc.go.kr에서 kdca.go.kr로 바꾸게 되어서 이전 cdc.go.kr을 참고하거나 인용했던 정보들이 소실된다는 점을 지적하고 있다. 우리나라는 사이트 주소뿐 아니라 퍼머링크 유지에 대한 의지가 부족하다고 생각하고 있어서 동의하고 있다. 특히 국가에서는 더 신경 써야 할 부분이라고 생각한다.(한국어)
Comments