깃허브 퍼스널 엑세스 토큰 노출에 따른 보안 위협

[DaleSeo]

관련 대화: https://discord.com/channels/775115965964222492/1289773425207803964/1294869211331428434

별도의 백엔드 없이 프론트엔드에서 바로 깃허브 API 연동을 하기 위해서는 엑세스 토큰이 사용자에게 노출된다. 우선은 엑세스 토큰에 읽기 권한만 부여하여 프로젝트를 진행하기로 했지만, 여전히 보안 측면에서 모범 사례에서 벗어나는 관행이다. 뿐만 아니라 나중에라도 실수로 엑세스 토큰에 쓰기 권한을 주었을 경우 우리 깃허브 조직 아래에 있는 데이터가 위험에 빠질 수 있다.

본 티켓을 통해 깃허브 엑세스 토큰을 좀 더 안전하게 관리할 수 있는 방법을 탐구하자.

[DaleSeo]

@Sunjae95 @HC-kang 당장 blocker는 아니지만, 프로젝트 후반에 재고해보면 좋을 것 같아서 일단 티켓만 생성해놓겠습니다. 혹시 조사하신 부분이 있으시면 댓글로 간단히 달아놓으시면 좋을 것 같습니다.

[Sunjae95]

토큰을 Fine-grained personal access tokens과 Personal access tokens 두가지 방법으로 만들수있습니다. 참고
제가 생각하기엔 Fine-grained personal access tokens은 beta버전이기에 적합하지않고 Personal access tokens으로 api 요청을 해야한다 가정하고 조사했는데요.
Discord에서 @HC-kang 님도 언급하신 내용처럼 프로젝트가 읽기가 필요한 api 토큰이기에 아래이미지처럼 토큰을 생성시 권한을 제한하는것이 좋아보입니다.

org의 read 권한으로 토큰생성해서 팀과 멤버에 대해서만 팀생성 api테스트했을 때 403 오류가 나와서 정상작동하는 걸로 확인돼요.
토큰 옵션 설정 범위 참고

제가 파일읽기 api는 어디 속해있는지 찾지못해서 이 부분 @HC-kang 님이 확인후 공유해주시면 감사합니다 😊

[HC-kang]

디렉토리 정보 조회에 대한 API는 Get a tree이고, 저희 레포(leetcode-study)가 Public 레포인지라 별도의 토큰 발급은 불필요합니다!

[DaleSeo]

제가 생각하기엔 Fine-grained personal access tokens은 beta버전이기에 적합하지않고 Personal access tokens으로 api 요청을 해야한다 가정하고 조사했는데요.

@Sunjae95 PAT를 쓴다면 GitHub에서 권고하는 데로 fine-grained personal access tokens를 선택해야합니다.

If possible, GitHub recommends that you use a fine-grained personal access token instead of a personal access token (classic)

https://docs.github.com/en/rest/authentication/authenticating-to-the-rest-api?apiVersion=2022-11-28#authenticating-with-a-personal-access-token

[sounmind]

#60 이 이슈를 해결하기도 하고 Github API를 사용하기 위한 Access Token이 실제로 소스코드에 필요한 순간이 왔습니다.
일단은 임시로 @DaleSeo 님이 만든 기간 제한적인 PAT를 사용하되 어떤 방법이 리스크가 적은지 조사를 병행해야겠습니다.

[DaleSeo]

#60 이 이슈를 해결하기도 하고

@sounmind 님, 흠... 두 이슈가 관련이 있지만 그래도 완전히 별개의 이슈가 아닐까요? #60 은 브라우저 환경에서 process 전역 변수를 사용했기 때문에 발생하는 버그이고요. 본 이슈는 어떻게 안전하게 GitHub API와 연동할 수 있을까? 좀 더 깊은 고려가 필요한 문제로 보입니다.

[sounmind]

@DaleSeo 말씀이 맞습니다. 별개의 이슈입니다.
Github API를 사용하려고 보니, 관련 코드에서 #60 이슈가 발생한 것이고,
Github API를 사용하기 위한 방법도 다시 알아봐야 했는데 #14 이슈가 다시 언급됐네요.

[HC-kang]

현재 상황

• PAT를 프론트엔드에서 직접 사용 중
• 토큰이 노출되어 보안 위험 존재

가능한 대안

1. PAT 현행유지

• 현재처럼 계속 사용
• 단점
  • 토큰 관리 소요와 부담이 큼
  • 보안 위험 지속

2. 신규 계정의 제한된 PAT 사용

• 새로운 깡통 계정 생성 / 팀 멤버로 추가
• 읽기 전용, 무기한 PAT Classic Token 발급
• 장점
  • 가장 적은 노력으로 개선 가능
  • 토큰 노출시 피해 최소화
• 단점
  • 여전히 토큰 노출됨
  • 계정 관리 소요 필요

3. GitHub App 사용

• GitHub App 생성 및 설정 필요
• 매 요청마다 Private Key로 JWT 생성 후 Installation Token 발급하는 로직 필요
• 장점: 토큰 만료로 인한 보안 강화
• 단점
  • 수정사항이 매우 큼
  • Private Key 노출되어야 하므로 여전히 보안 위험 존재

4. GitHub Actions 활용

• leetcode-study 레포에서 Action으로 JSON(등등) 생성/업데이트
• leaderboard에서는 public JSON만 참조
• 장점: 토큰 불필요, 가장 안전한 구조
• 단점: 저장소에 알고리즘 풀이 외의 코드(데이터)가 추가되어야 함

권장 순위

1. GitHub Actions (4)
2. 신규 계정의 제한된 PAT (2)
3. GitHub App (3)
4. 현행 유지 (1)