📌 프로젝트 진행 기간: 23.04.~24.05.📝 프로젝트 배경우리 서비스는 매년 정보보호관리체계(ISMS) 인증을 받기 위해 보안 점검을 실시한다. 이 과정에서 다양한 보안 취약점을 점검하는데, 내가 프로젝트를 맡기 전 점검에서는 DB 접속 정보 관리 방식에서 보안 이슈가 발견되었다. 당시에는 쇼핑몰별 DB 접속 정보(ID/PW)가 웹서버의 설정 파일에 평문으로 저장되어 있었다. 이로 인해 웹 서버에 접근할 수 있는 누구나 해당 파일을 확인하면 DB 접속 정보를 유출할 위험이 있었다. 즉, DB 데이터가 직접 탈취될 수 있는 구조였으며, 보안 강화를 위한 개선이 시급했다. 이에 따라 DB 접속 정보 관리 방안을 개선하는 프로젝트를 진행하게 되었다.⚒️ 1차 개선안: 솔루션 내 암호화를 통한 보안 ..

📝 배경어느 날, DB에 이상한 값이 저장되어 있다는 확인 요청을 받았다. 쇼핑몰 관리자 페이지에서 결제 수단을 변경하였는데, 실제 DB에는 결제수단 정보 뿐만 아니라 브라우저 쿠키 값까지 저장되어 있었다. 이로 인해 주문 페이지에 진입할 때, 결제수단 정보를 제대로 파싱하지 못해 오류가 발생했고, 에러 페이지로 이어지고 있는 상황이었다. '최근에 관련 로직 개선이 아예 없었는데, 왜 갑자기?'라는 의문을 품고 로직을 다시 살펴보았다.🔥 이슈PHP에는 HTTP 요청으로 전달된 데이터를 처리하기 위한 주요 슈퍼 글로벌 변수로 $_GET, $_POST, $_REQUEST 3가지가 있다.🔖 $_GET- HTTP 요청 중 GET 메서드로 전달된 데이터를 가져옴- URL 쿼리 문자열에 포함된 값에 접근할 ..

* 상세 구현 내용은 모두 예시 값으로 변경하여 포스팅 작성하였습니다.📝 프로젝트 배경2024년 9월, 새로운 프로젝트가 시작되었다. 우리 회사 커머스에는 고**과 샵**라는 두 가지 주요 솔루션이 있다. (나는 고**개발팀에 속해있다)기존에는 각 솔루션의 상점이 독립적으로 최고 운영자 데이터를 관리해왔지만, 시간이 지나면서 구조적인 한계가 드러났다. 운영 데이터를 종합적으로 관리하기 어려워지는 등 비효율적인 운영 문제가 발생하면서, 이를 해결하기 위해 회원 시스템을 통합 구조로 전환하는 장기 프로젝트가 시작되었다. 그 첫 단계로, 고**에서는 최고 운영자 통합회원 로그인 연동 작업이 시작되었다.🔥 이번 프로젝트는 단순히 기존 인증 서버를 가져와 활용하는 것이 아니라, 커머스만의 독자적인 인증/인가 ..

📌 Intro고객 계층 관리를 위해 통합 로그인 기능 개발이라는 새로운 프로젝트를 담당하게 되었다. 이번 프로젝트에서는 보안 강화를 위해 Oauth 2.0 프로토콜에서 RTR(Refresh Token Rotation) 방식을 도입하고, 인증 방식으로는 JWT(Json Web Token)을 사용하기로 했다. 그러나 개발 과정에서 Refresh Token 동시성 이슈가 발생하여 간헐적으로 토큰 갱신이 실패하고 사용자가 로그아웃 되는 이슈가 있었다.다행히 이 이슈는 QA 과정에서 발견되었어서, 리얼 배포 전에 조치하였다🫠 이번 포스팅에서는 RTR 방식에서 발생한 Refresh Token 동시성 이슈와 이를 해결한 과정을 기록하고자 한다.🔖 용어 정리RTR: Refresh Token RotationJWT..

📝 들어가기 전맥을 초기화할 때마다 환경 세팅을 기억해내려고 매번 구글링하는 게 귀찮아서, 이번 포스팅을 통해 나만의 세팅을 백업 겸 기록해두려 한다!📌 homebrewmacOS 및 Linux에서 사용 가능한 패키지 관리자https://brew.sh/## 설치/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 📌 iterm2 설치macOS용 대체 터미널 애플리케이션, 기본 터미널보다 훨씬 기능이 다양하여 작업 효율성을 높여줌https://formulae.brew.sh/cask/iterm2## 설치brew install --cask iterm2테마 다운로드: https://iterm..

😮 개발자 2주년이 되었다취업 준비 기간 동안은 합격 소식을 기다리는 1~2일 조차도 시간이 굉장히 느리게 흘러갔던 것 같은데, 입사 후의 시간은 속절없이 빠르게 지나갔다. 그리고 2024년 8월 8일, 어느새 개발자로서의 2주년을 맞이했다.나는 회고를 좋아하기 때문에 8월 8일이 되자마자 회고 포스팅을 작성하고 싶었지만, 1주년 때처럼 가볍게 시작할 수가 없었다. 2주년 회고는 생각보다 더 많은 고민과 생각이 필요했다. 실무 경험이 쌓이면서 더 큰 규모의 중요한 이슈들이 다가왔고, 이제는 업무를 예전처럼 마냥 간단하게 처리할 수는 없었다. 뿐만 아니라 사회초년생인 만큼 다양한 사람과의 협업 속에서 처음 마주하게 된 이슈들이 많았고, 그 속에서 어떻게 대응하고 올바른 나만의 가치관을 형성해 나갈지 끊임..

사내 서비스에 소나큐브로 정적분석을 도입한 후, 무수히 많은 Bugs와 Code Smells가 발견되었다 😑대체 어떤 버그가 이렇게 많은 것일까.. 궁금했던 나는 Overall Code 기준으로 심각도가 높은 Bugs를 모두 파헤쳤고, 빈번하게 발생한 Bugs를 정리해보았다.최소한 기본적인 버그는 만들지 않는 개발자가 되자! 🤔 🚦 Levels: Blocker⛔️ Create class "Exception" in namespace or check correct import of class🔖 IssueClass of caught exception should be defined사용하는 클래스는 꼭 import를 해주자✅ How to fix// AS-IS// ..생략} catch (Exception ..

📌 이슈현재 회사에서 php 7.0와 8.2, 2개 버전의 서비스를 관리하고 있다.8.2로 버전업하면서 7.0에서 숨어있던 여러 레거시로 인한 에러들이 나타나기 시작했다.UPDATE {table}SET {column}={value}WHERE {column} IN ();최근에는 syntax 에러를 유발하는 동일한 쿼리임에도 버전별로 결과가 7.0에서는 에러가 무시되고 있던 것을 발견했다.📝 분석https://www.php.net/manual/en/mysqli-stmt.execute.php7.0에서는 이슈 쿼리를 execute()할 경우, UPDATE 처리할 대상이 없기에 아무런 동작도 발생하지 않고 함수가 종료되는 것을 확인했다.You have an error in your SQL syntax; che..