로깅에 대해 학습하고 기록한 글입니다. 이전 글에서 nginx 로그를 남기때 프록시 처리된 IP가 기록되는 상황을 해결하기 위해 http_x_forwarded_for 헤더 정보를 참고해야 한다는 점을 알게 되었습니다. http_x_forwarded_for 헤더해당 헤더는 커스텀 헤더로 사실상 표준으로 자리잡은 헤더 입니다. 프록시나 로드밸런서를 통해 접속하는 클라이언트의 원 IP를 식별하기 위한 헤더입니다. 이는 반드시 지켜야 한다거나, 해당 헤더가 무조건 존재한다는 보장이 없기 때문에 우선 Cloud flare 공식문서를 찾아 보았습니다. https://developers.cloudflare.com/fundamentals/reference/http-request-headers/ Cloudflare HT..

EC2를 대상으로 무작위 ip에서 공격이 있어 관련 내용을 기록하는 글입니다. Cloud Flare에서 도메인을 관리 중인데 EC2에 여러가지 무작위 IP에서 공격 시도가 매일 들어오고 있는 상황 입니다.찾아보니 로드밸런서를 통해 Private VPC에 애플리케이션 서버를 배포하고 Public VPC 진입접을 통해서만 접근이 가능 하도록 하는 방법과 Cloud Flare 에서 방화벽 설정으로 특정 이벤트를 차단하는 형태 두가지 방법이 있었습니다. 첫번째 방식은 Bastion Host 를 활용한 방식으로 게이트 역할을 하는 EC2를 하나 더 띄우는 형태 입니다. 돈이 두배지요 이 글에서는 두번째 방식으로 처리 하도록 하였습니다.우선 IP를 후이즈에 검색 해보았습니다. 모든 아이피가 해외에서 관리되고 있는 ..

이전 글에서 Rust의 소유권에 대해 알아보았습니다.이번 글에선 참조 및 빌림에 대해 알아보겠습니다. 참조 및 빌림이전에 튜플을 이용하는 방식은 소유권을 함수 밖으로 다시 가져온 형태인데,해당 방법을 사용하는 대신 참조자를 이용해 해당 참조자를 인자로 사용하는 함수를 정의하고 사용할 수 있습니다.러스트에는 여러종류의 참조자가 존재합니다. 우선 일반적인 불변 참조자 부터 알아보겠습니다.fn main() { let s1 = String::from("hello"); let len = calculate_length(&s1); println!("The length of '{}' is {}.", s1, len);}fn calculate_length(s: &String) -> usize { s...

Rust메모리 안전 언어로 저수준의 제어가 가능하면서도 메모리 제어를 사용자가 하지 않도록 하는 것을 목표로 하는 언어입니다.Java, Javascript 같은 언어들은 이미 개발자가 메모리 제어를 하지 않아서 별 신경을 안썻지만, C, C++ 같은 C 계열은 개발자가 메모리를 하나하나 제어해줘야 합니다. 예를들어 특정 메모리 공간을 할당만 해놓고 해제하지 않으면 해당 메모리 공간을 의미없이 점유하게 되는 문제가 생깁니다.이를 메모리 릭 (Memory Leak) 이라고 합니다 .메모리 릭은 힙 영역에 할당된 메모리를 해제하지 않아서 발생합니다. 힙 영역에 할달된 메모리는 함수호출이 종료되어도 해제되지 않습니다.개발자가 직접 명시적으로 해제 해야 해제 됩니다. 그로인해 함수가 호출되면 될수록 새로운 메모리..

벡터 임베딩 그리고 유사도 측정에 대해 공부하고 기록한 글 입니다. 벡터 임베딩벡터 임베딩은 데이터의 수치화된 표현을 의미합니다. 자연어 혹은 특정 사물, 주제, 이미지 등 기타 데이터를 수치화한 값을 의미합니다. 예를들어 "나무" 라는 단어를 [ 0.04128048 0.02086734 -0.00774979 ] 이런 형태로 숫자로 표현한다면 이는n차원의 벡터 공간에 "나무"라는 임베딩을 생성한 것 입니다. 해당 값은 사람이 보기엔 의미있는 수치가 아닙니다. 다만 AI 에겐 해당 수치가 유사성 판단의 근거가 됩니다.   유사도 측정특정 데이터가 얼마나 유사한지 측정하는 과정을 의미합니다.여러가지 유사도 측정 방식이 있지만 코사인유사도, 유클라디안 유사도 이렇게 두가지에 대해 설명하겠습니다. 코사인 유사도..

Nginx트래픽 제어 용도로 사용합니다. 새 버전이 Docker 컨테이너로 만들어지면 해당 버전으로 트래픽을 제어합니다.DockerGithub Actions를 통해 로컬에서 개발한 프로젝트 ( 예를들어 Spring Boot )를 실행가능한 형태로 빌드한 후 파일 형태로 만드는데 이를 실행하기 위한 공간입니다. Github ActionsGithub의 브랜치를 트리거하여 해당 브랜치에 이벤트가 발생하면 정의한 작업을 수행하도록 해주는 도구 입니다.여기서는 master 혹은 main 브랜치로 merge가 발생하면 배포하는 형태로 진행 합니다.  배포는 아래와 같은 순서로 이루어 집니다.코드 수정 후 github에 코드 업로드트리거된 브랜치로 mergeGithub Actions 에서 코드 빌드 및 EC2로 빌드..

gpt 모델을 활용하여 한층 강화된 모델을 사용할 수 있도록 해주는 도구 입니다. 기존 Chat GPT 3.5 모델에 추가 정보를 입력하여 모델에 참고 데이터를 제공 할 수 있습니다. https://platform.openai.com/assistants 링크에 접속하면 UI로 어시스턴트를 생성,수정 할 수 있습니다. Fine-tuning 좌측 탭을 보면 Fine-tuning 이라는 항목을 볼 수 있는데, 이미 훈련된 대규모 언어 모델에 특정 데이터셋을 사용하여 추가적인 학습을 수행하는 작업을 말합니다. 예를들어 Chat GPT 3.5 모델이 내가 원하는 방향으로 데이터를 제공하지 않는다면 이 항목을 통해 미세 조정을 할 수 있습니다. 챗봇을 제작할 때 답변의 형태를 일정한 형태로 유지한다던가, 항상 존댓..

Cross-Site Request Forgery (CSRF)는 웹 애플리케이션의 보안 취약점 중 하나로, 사용자가 자신의 의지와 무관하게 다른 사이트에서 생성된 요청을 보내는 현상을 말합니다. 이 공격은 사용자가 이미 인증된 웹사이트에 대해 악의적인 작업을 수행하도록 만듭니다. CSRF의 작동 원리: 사용자 인증: 사용자는 어떤 웹사이트(예: 은행 사이트)에 로그인하고, 브라우저는 이 사이트로부터 인증 쿠키를 받습니다. 악의적인 사이트 방문: 사용자가 공격자가 제어하는 다른 웹사이트(피싱 사이트 등)를 방문합니다. 이 사이트에는 인증된 웹사이트에 대한 악의적인 요청(예: 송금 요청)을 생성하는 코드가 숨겨져 있습니다. 자동 요청 전송: 사용자의 브라우저는 피싱 사이트에서 생성된 요청을 자동으로 실행합니다..

XSS의 이해, 방어에 관해 고민해본 글 입니다. 대부분 사이트에서 작동하지 않겠지만, 학습 목적으로 작성한 글이기에 악용시 책임은 코드를 사용한 공격자에게 있습니다. 브라우저는 script 태그를 만나면 자동으로 이를 실행 합니다. 예를들어 특정 게시글에 스크립트가 쓰여있다고 가정 해보겠습니다. 그럼 브라우저는 해당 태그를 읽고 알림창을 띄웁니다. 그럼 태그 전체를 문자열로 처리하면 되지 않느냐? 할 수 있는데 "" 이런 방식을 생각 했다면 이는 화면에 "" 를 표시하고 스크립트를 실행하는 것으로 해석됩니다. 자바스크립트 파일에서 변수에 문자열 할당하듯 처리한다고 되는 것이 아니기에, 어떤 형태로든 완성된 태그가 중간에 있으면 브라우저는 해당 태그를 해석 합니다. 이러한 특성을 악용한 공격이 XSS 입..

토큰기반의 인증 전략에 대해 고민해본 글 입니다. 이전 글에서 RTR이 토큰 탈취 대응 방안으로 어느정도 효과가 있는지 알아보았습니다. 여러가지 문제가 있었지만 간략 하게 정리하면 아래와 같습니다. RTR은 일부 케이스에선 효과가 있지만 그리 효과적이지는 못한 것 같다. XSS 공격에는 여전히 취약하다. 대부분 방어가 되어있긴 하지만 일부 취약한 부분도 있다. 어느정도 양보하면 세션과 다를게 없어진다. 그리하여 새로운 전략에 대해 이야기 해보려 합니다. Http Only 리프레시 토큰을 쿠키에 담아 보내는 방식 입니다. http only 속성을 부여하여 자바스크립트로 접근할 수 없도록 설정하는 방식입니다. 우선 자바스크립트로 접근 할 수 없기 때문에 여기서 대부분의 보안 취약점은 해결이 된 모습입니다. ..

JWT를 사용하던 중 이를 어떻게 관리하면 효율적이고 안전할까 고민해보고 작성한 글입니다. AccessToken & RefreshToken 가장 기본적인 방법 입니다. 유효기간이 다른 두가지 형태의 JWT를 생성하고 클라이언트는 토큰 재발급시 리프레시 토큰을 서버로 전송 합니다. 리프레시 토큰에 담긴 사용자 식별값을 토대로 유저를 식별하고 새로운 엑세스 토큰을 발급하여 전달 합니다. 이 방식은 가장 기본적이고 편한 방식이지만 리프레시 토큰이 탈취되었때 대비가 하나도 되어있지 않습니다. 리프레시 토큰이 탈취되면 해커는 해당 토큰으로 계속 재발급을 받아 자신이 해당 유저인 척 할 수 있습니다. 무상태성이라는 특성이 악용에 활용된 전형적인 사례입니다. RTR ( Refresh Token Rotate ) 엑세스..

환경 분리 Node에서 환경변수 관련해서 개발 환경별로 구분하고 싶을 때, env.prod, env.dev 형태로 나눴던 기억이 있습니다. Spring Boot 에서도 이와 비슷하게 환경을 분리 할 수 있습니다. 우선 dev 환경과 prod 환경을 나누기 위해 application.yaml 파일을 분리했습니다. .example이 붙은 파일은 github에 올라가고, 어떤 값이 필요한지 가이드 하는 역할입니다. application-dev, application-prod는 git ignore에 써두어서 업로드 되지 않도록 합니다. 각파일에는 아래 예시와 같이 on-profile: dev 형태로 환경의 이름을 씁니다. spring: config: activate: on-profile: dev 실행 설정 ID..