마이의 개발 블로그

배경솔루션 개발 도중 XSS 취약점이 발견되어 이를 어떤 방식으로 해결할지 탐색하고 팀과 의견을 나누는 시간이 필요했습니다. XSS에는 여러 가지 방식이 있지만 특히 웹에서 텍스트 에디터를 통해 사용자가 게시글 본문을 입력하는 등 일반 유저가 HTML을 조작할 수 있는 경우에 해당 문제가 종종 보고되는 것을 발견할 수 있습니다. 보안유지를 위해 더 자세하게 기술할 수는 없지만 저의 경우도 비슷한 맥락의 문제가 발견되어 이를 해결하는 과정에서 알게된 내용들을 작성해보고자 합니다.크로스 사이트 스크립팅(Cross Site Scripting, XSS)이란?XSS는 관리자가 아닌 유저가 클라이언트측에 악의적인 스크립트를 삽입하여 이상 동작을 유발시키는 행위로 웹 어플리케이션의 서버 - 클라이언트 구조에서 주로 ..

상황 포스트맨을 이용한 API 테스트를 하다보면 로그인 후 발급되는 액세스 토큰이나 리프레쉬 토큰을 API요청에 포함하여 보내야하는 경우가 있습니다. 이 때 스크립트를 이용하여 토큰을 특정 변수에 할당하면 직접 복사를 하지않고도 편리하게 재사용이 가능해집니다. 방법 1. 좌측 메뉴에서 Environments 진입 2. 환경 추가(예제: env1) 후 사용할 변수 추가 - Globals에 전역 변수로 추가해서 사용하는 것도 가능하나, 프로젝트에 따라 분리하여 사용하기를 권장 3. 좌측 메뉴 - Collections로 복귀 후 우측 상단 환경 선택 (env1) 4. 로그인 API - Tests 탭 진입 후 스크립트 작성 - 포스트맨의 response code가 200일 때(상황에 따라 응답코드 입력) 1) ..

상황 서버에게 동일한 요청을 보낼 때 별다른 변화나 문제가 없음에도 응답코드가 200이 아닌 304로 표기되는 경우가 있습니다. 응답코드 304(Not Modified)가 리턴되는 이유 300번대 코드들은 요청된 자원에 대한 리디렉션을 의미하는데, 그 중에서도 304는 'Not Modified'로, 요청한 자원에 대해 변경된 사항이 없으므로 캐시되어있는 자원으로 리디렉션 하겠다는 의미를 갖습니다. 즉, 브라우저로부터의 최초 요청 시에는 200번 응답을 받지만 이후에 자원에 변화가 없다면 일정 시간 동안은 304번 응답을 받게되는 것입니다. 현재 개발중인 로컬 서버에서 이를 테스트 해보기 위해 시차를 두고 요청을 여러 번 보내며 응답코드를 관찰했습니다. 그 결과 꽤 오랜 시간동안 304번 응답이 유지되는 ..

스웨거 공식 문서에 기입된 스펙에 맞게 component를 작성한 후, 재사용되는 파라미터들(검색 창의 검색 파라미터)을 별도 문서에 정의하여 component별로 참조해서 사용하고자 하였다. 그러나 글 제목과 같은 에러메시지가 출력되어 원인을 검색해보니 다양한 이유와 해결방법이 제시되어있었는데, 나의 경우에는 순환참조로 인한 오류가 원인으로 드러났다(제목의 Component는 오류가 발생한 component의 이름을 의미한다). 내가 관리하는 스웨거의 구조에서는 경로관리파일, 컴포넌트(파라미터, 스키마 등) 정의 파일, 경로별/메서드별 정의(req 메서드, res 양식 등) 파일이 각각 다른 파일로 분리되어 있었는데 알고보니 컴포넌트 정의파일과 경로 파일이 서로를 참조하고 있었던 것이다. 문제의 원인이..

배경 테스트를 위한 도메인 연결을 하던 중 HTTPS로의 전환이 필요하여 절차를 간단히 정리해보았다. 이미 Elastic Beanstalk(EB) 인스턴스 생성, 도메인 연결, SSL인증서 발급이 완료되었다는 가정 하에 내가 지정한 도메인으로 접속 시 HTTP를 HTTPS로 전환하기 위해 필요한 절차를 정리해보았다. application 로드밸런서를 기준으로 한다. 설정을 통해 만들고자 하는 전반적인 플로우 1. (HTTP 리스너를 통해) HTTP로 진입 2. (HTTP 리스너에서 설정된 규칙을 통해) HTTPS로 리디렉션 3. (HTTPS 리스너를 통해) HTTPS로 진입 4. (HTTPS 리스너에서 설정된 규칙을 통해) 리디렉션된 페이지에서 해당 인스턴스로 포워드 절차 Elastic Beanstalk..