Scribble at 2024-07-26 09:47:54 Last modified: unmodified
This is such an enormous attack vector for all organizations that use GitHub that we’re introducing a new term: Cross Fork Object Reference (CFOR). A CFOR vulnerability occurs when one repository fork can access sensitive data from another fork (including data from private and deleted forks). Similar to an Insecure Direct Object Reference, in CFOR users supply commit hashes to directly access commit data that otherwise would not be visible to them.
削除したリポジトリのソース・コードに、フォークしたリポジトリからアクセスできてしまうという問題があるようだ。情報資産のリスクとしては「機密性（confidentiality）」に該当する話で、場合によっては重大な事案となり得る。
ただ、僕の運用条件や現況では問題にならない。そもそも、僕は殆どのリポジトリをプライベートに設定しているし、フォークしない方針を取っているからだ。一人で作業しているのにフォークなんてしても大して意味も効用もない。
ウェブ制作会社のプログラマというのは、単独で作業していることが多いので、そもそも GitHub はコラボレーションのために使っているわけではなく、敢えて言えばソース・コードのバックアップが目的だったりする。同じ目的で Dropbox などのクラウド・ストレージも使っているわけだが、別の経路でバックアップを取っていると、もしランサムウェアなどに感染して Dropbox のフォルダが暗号化されてしまい、その中にローカルで運用しているソース・コードがあったとしても、GitHub にコミットする作業は手動でやっているので、GitHub のリポジトリまでは影響を受けない。それこそ、ソース・コードだけでなく他の仕様書などのファイルも一緒にコミットしておけば、二重にバックアップしているのと同じである。
フォークする可能性があるといえば、過去に使ったコードを再び流用する場合だろう。実際、過去にフォークしても良かった事例はあるが、それをやると違うクライアントの案件で使うソース・コードを同じリポジトリに置くこととなって、開発としての都合はともかく、情報セキュリティなりビジネスとしての都合で考えるとよろしく無いわけである。プログラマだからといって異なるクライアントの成果物を同じリポジトリに置いて運用するのは不見識だという自覚が必要だと思うし、僕らのような有能な技術者であっても、そういう無知や不見識を免除されるとは思わない（というか、思っていないから20年にわたって電通案件で事故一つ起こしてない有能なんだけどさ）。