生成AIコーディングによってこれまでソフトウェア開発に手を出せなかった人であっても発想だけあれば新たな価値を提供できるようになってきた。通常ソフトウェアエンジニアが価値を見出さない部分に対しても新たな付加価値を見出す点は見習いたいが、そのためにあえてやらないことを実現してしまっているものも見受けられる。これはいい側面もあるが、大体はやるべきではないアンチパターンや、何度も繰り返し警告されてきた脆弱性を教科書通りに組み込んだものになっている。
しかし、あえてやらないことを見つけることは難しい。悪魔の証明みたいなもので、やらないことをあえてやっていないのか、本当に誰もやっていないブルーオーシャンなのかの区別がつきにくいからだ。
以下に最近見つけたサービスの中で危険だと指摘されたものをいくつか挙げる。着眼点は良かったものの設計に不備があり、利用に際して注意が必要なものである。
4×4 Pixel Diaryは4x4ピクセルの画像を共有できるサービスで、サーバーサイドのバリデーション不足やキーの流出などがあり、旧版は1日でサービスが終了した。その後、エンジニアの支援もあり復活。
URL RIBBONはURLやギフトコードにメッセージ追加してそのURLを共有できるサービス。一切のデータをサーバーに保存していないことがウリだが、入力内容が共有用URLのフラグメントとして表現されるようになっており、アクセスしなくても内容がわかってしまう。
どうしてそうなるの？
知識不足
ウェブ技術は先人たちの数多の成功や失敗を糧に発展してきており、今日ではやれフレームワークだやれライブラリだと非常に高度なソフトウェア資源によって構築されている。その中では過去の教訓から開発者があまり失敗しないようにするためのガードレールも敷かれているが、こうした状況であっても依然ソフトウェアの自由度は高く、知見がなければいくらでも失敗できる環境にある。少しソフトウェアをかじればHTMLのサニタイズやSQLのインジェクション対策は親の顔より見ることになるが、こうした前提知識なしにモノを作り出せることは講習なしに一般道を運転するようなものである。
もちろん生成AIに「セキュリティ的な課題はありますか？」と聞けば分析して解決方法を提示してくれるかもしれないが、どういった視点を持てばいいのかについては、ある程度の知識なしでは見当もつかないし、AIも万能ではないので抜け漏れは起こりうる。
ウェブ技術は非常に流動的で日々変化していくため情報を追うのも一苦労だ。しかし、基礎的な部分はあまり変わっていないので、学習の機会があれば、まずは技術評論社の書籍をあたるとよい。ウェブ技術や開発に特化した書籍がいくつか出版されており、プログラミング・システム開発を見ればいくつか自分に合いそうなものが見つかるはずだ。
金銭的な制約
こうしたセキュリティ的に課題があるサービスができる背景は一言で言えば知識不足だけでなく、金銭的側面もあると考えている。サーバーやデータベースがなくても実現できるということであれば、その提案は非常に魅力的に映る。サーバーは安くても月500円程度かかるし、データベースとなるともっと高いので、趣味で動かすには痛い出費になるし、契約の手間もある。最近では非常に安価で済むサーバーレス環境という選択肢もあるが、これは「わかっている人」のためのオモチャなのでいつでもどこでも使えるものではない。
そのためなるべく安く手間も抑えるということを一番の条件にすれば、多少のセキュリティリスクがあったとしても「なんかよくわからないけど、できたからヨシ！」となるのは想像に難くない。本来サーバーサイドがあることで隠蔽できるものが、フロントエンドだけで実現するようになっているか、本来公開すべきでない認証情報がクライアントに公開されていると、ちょっと仕組みを知っている人間からすれば簡単に悪用できてしまう。
どうすれば安全になるのか？
ではどうすれば「安全にウェブサービスを公開できるのか？」だが、すごく雑に言えば次の2つだ。時と場合によるが、これらが満たされていれば多少マズい設計がされていてもあとから修正もできる。
- サーバーを用意しよう
- 性悪説で考える
サーバーを用意しよう
サーバーを用意するのは非常に有効で、その最大の理由としてクライアントからはサーバー内のロジックがわからないことにある。設計が甘いとサーバーへのリクエストとそのレスポンスでロジックが割り出されてしまうこともあるが、ほとんどの状況ではそうはならない。隠蔽できる部分があるというのはそれほどに有利になる。
ただ、いつでもサーバーが必要かと言われるとそうでもない。隠す必要のないロジックやデータであればわざわざサーバーリソースを使うほどのことでもないし、JavaScriptやHTML5技術で処理させることができればそのコストをクライアントに押し付けることができる。サーバーとの通信もないので個人情報保護法にも抵触しない。
クライアントをサーバーのコントローラにすることも重要だ。すこし概念的に難しいかもしれないが、つまりはクライアント側はサーバーと通信して、その結果をグラフィカルに表示することだけに徹するということだ。ロジック的な処理は一切行わない。これであれば結果的にサーバーと直接やりとりしているのと同じであり、そのロジックはサーバーにあるので問題が起きようがない。
性悪説で考える
本当に悪意を持っているユーザーを防ぎ切ることは難しいが、そのための手間を増やすとか、行為自体を無意味な状況にすることは効果的な対策だ。また、サービス提供側はしばしば単一のユーザーの利用シナリオを考えがちだが、中には1ユーザーだけでは無理であっても、複数のユーザーが結託すると実現できるようになることもあるので、制度ハックができないかどうかの視点も養うべきである。
もちろんのことユーザーがユーザー情報を保存したり、コンテンツを作成できたりするサービスであれば、第三者による他人のデータの閲覧や利用ができていいものかどうかを考えなければならない。その程度によってはURLを推測しにくいものにしたり、時限式のトークンを埋め込んだり、認証機能を導入したりといった考慮も必要になってくる。