シリーズ第3弾は、これまでの「笑える話」とは打って変わって、少しシリアスな内容です。受託開発の現場で直面した、セキュリティと仕様の「闇」についてのお話です。
💡 【連載：開発の記憶】
本記事は、受託開発の現場で直面したトラブルや葛藤を振り返る全3回の連載です。
- 第1回：DBをFLOAT型にしても誤差は出るというお話
- 第2回：システムが出力したExcelが開けない！？犯人は「メモ帳」だった話
- 第3回：「セキュリティは不要」と指示されたエンジニアの葛藤（現在の記事）
事の発端：ログイン状態の引き継ぎ
ある時、既存の社内ポータルシステムから、私が開発しているシステムへ「ログイン状態を引き継いで」遷移させたいという要望がありました。
ログイン情報を別システムへ渡すわけですから、当然セキュリティを考慮しなければなりません。
本来であれば、「ワンタイムトークン」を別途発行して受け渡すような強固な仕組みを導入すべきです。しかし、呼び出し側（ポータル側）の実装変更に手間をかけさせたくないのと余り大きな変更は受け入れられないことがわかっていたこともあり、私は次のような「妥協案」を提案しました。
「渡される情報の改ざんを防止するためのせめてもの措置として、共通鍵によるハッシュ値（HMAC-SHA256）を付加し、それを受け取り側で検証する」という（リプレイ攻撃などいくつかのリスクがありながらも、自由自在にパラメーターを組み合わせてなんでもやりたい放題にしてしまうことだけは防止したいという最低限の）仕組みです。
1ヶ月半の無視、そして下された判断
この実装のために、呼び出し側システムの言語やバージョン（Javaのバージョン等）を教えてほしいと何度も依頼しましたが、回答は常にスルーされました。
そして質問から約1ヶ月半後、ようやく届いた仕様確定のメールには、目を疑う内容が書かれていました。
連携のインターフェースが決まりました。
パラメータ
・ユーザーコード
・ユーザー名
・権限区分（ロールID）指定のURLに、これらのパラメータをそのまま付加して呼び出すようにします。URLを教えてください。
つまり、URLの末尾に ?user_id=xxx&role=admin といったデータをそのまま（平文で）くっつけて遷移させるから、それを見てログインさせろ、という指示でした。
限界を迎えた私からの警告
これではURLのパラメータを書き換えるだけで、誰でも簡単に他人になりすませたり、管理者権限を奪取できたりしてしまいます。「社内システムだから」という甘えがあるのかもしれませんが、これではセキュリティはゼロに等しい状態です。
私は、エンジニアとしての矜持から、かなり強めの警告メールを送りました。
以前より何度も確認させていただいていますが、現状のプログラムは改ざん防止のハッシュ値が付加されることを前提としています。
パラメータをそのまま渡すだけでは、誰でも容易に権限を偽造できてしまい、セキュリティ上非常に危険です。このようなセキュリティ意識のないロジックだと理解したうえで、あえて私が実装を担当することは避けたいと考えております。どうしてもその仕様で進めるのであれば、そちらでコードを修正していただく方が良いかと思います。
サボりたいからではなく、将来そのシステムが脅威に晒されたときに困るのは発注元である、という一心での訴えでした。
結末：エンジニアの敗北
私の熱い訴えに対する直接の返信は、結局最後までありませんでした。
後日、別の担当者の方からこっそりと「あっちの担当者が『どうしても余計な加工（ハッシュ生成等）はできない』と言い張っていて、提案は通らなかった」という連絡をもらいました。
結局、不本意ながら私はハッシュ値による改ざんチェックのロジックをすべて破棄し、URLパラメータの生データだけでログインと権限付与を行う「ザル」の状態で納品せざるを得ませんでした。
まとめ：正論が通らない現場のリアル
「社内システムなら大丈夫」という考えは、今や全く通用しない時代です。
しかし、現場の担当者の「面倒くさい」「スキル不足」「既存の環境を変えたくない」といった都合だけで、明らかな脆弱性が放置されてしまう……という悲劇は、残念ながら現在でも起こり得ることです。
あのシステムが今もどこかのイントラネットで、URLをちょっと書き換えるだけで「事務局」になれてしまう状態で稼働しているのかと思うと、今でも少し胸が痛みます。
皆さんも、もし「パラメータだけで権限を渡してほしい」という指示を受けたら……どうか全力で抵抗してみてください。
以上、全3回にわたる当時の記憶をまとめてみました。
技術的な話からセキュリティの闇まで色々ありましたが、今となってはエンジニアとしての視点を磨くための貴重な経験だったと感じています。