💩

Webアプリ受託界隈の品質有象無象問題を何とかしたい

2025/01/11に公開

Webアプリ受託界隈

ここでいうWebアプリ受託界隈とは、以下のようなイメージです。

  • 発注側は、年商数億〜数十億規模、非IT系の中小〜中堅企業(つまり社内に技術者はいない)
  • 受託側は、数人〜数十人規模のシステム開発会社
  • 予算数百万〜千数百万規模のWebアプリ(またはモバイルアプリ+Web API)新規開発

私はこんな界隈で仕事をしています。

品質有象無象問題

どうやらこの界隈では、品質、特にセキュリティ品質が、想像を絶するほどクソなものが、しれっと納品されていることがあるようです。

実体験を3つほど挙げます。

Case.1 某金融サービス会社の顧客マイページ

FXを中心とする金融商品を扱う会社の顧客マイページの案件です。

開発した会社の対応が悪いので、保守・追加開発を引き継いで貰えないかとの相談を受けました。

事前調査の契約を結び、稼働中のアプリのソースコードを確認してみると・・・

・利用者の運転免許証とマイナンバーカードの画像が公開ディレクトリに直接置かれていた。かつ、ファイルパスは連番で容易に推測可能だった。
・決済代行会社からのWebhookの署名検証等が一切行われておらず、容易に偽装入金が可能だった。
・テスト用と思われる入金処理APIが、本番環境でコール可能な状態になっていた。
・フレームワークのCSRF対策機能がコメントアウトされていた。

等々、致命的な脆弱性が多数見つかりました。

Case.2 事業者向け顧客管理・請求プラットフォーム

とある業界の事業者向けに、顧客管理、請求、エンドユーザに対する料金明細の提供などが行える、BtoBtoC のプラットフォームです。

元々の開発会社との契約を終了し、社内で内製化するための支援を行いました。

機能改修の作業を行う中で、致命的な脆弱性が多数見つかりました。

数百のAPIが存在していたのですが、そのほとんどのAPIで事業者のIDをパラメータから取得してたため、
パラメータを改ざんすることで、他の事業の顧客情報や請求情報等を、容易に閲覧・編集することができてしまいました。

Case.3 ビジネスマッチングアプリ

とある業界において、仕事を発注する事業者と、受託する個人をマッチングする、Webアプリ+モバイルアプリです。

新規事業として開発され、正式リリースする前のユーザテストの段階で、セキュリティ面を心配した運営会社から、弊社に相談がありました。

ソースコードを受領し、見てみると、

・リクエストのパラメータを改ざんすると、他のユーザの個人情報(身分証の画像を含む)を閲覧できる。
・リクエストのパラメータを改ざんすると、他人の発注情報を閲覧・更新できる。
・APIを直接コールすると、発注のステータスを自由に更新できる。
・APIを直接コールすると、ステータスを問わず発注内容を編集したり、削除したりできる。

等々、こちらも悲惨な実装でした。

今回の論点

非IT企業であるこの「界隈」の発注者の納品検査は、ユースケースに従って動作検証するのが関の山です。
そこで不具合が出なければ、検査に合格を出してしまいます。

そして、トンデモ脆弱性が眠っていることに気づかぬまま、運用を開始してしまうのです。

上記3ケースとも、もし実際に事が起こっていれば、大袈裟でもなんでもなく、発注者の会社が消し飛ぶ事態になっています。

発注者の責はといえば、発注先選定を誤ったことと、セキュリティ視点での納品検査をしなかったことでしょうか。

どちらも、この「界隈」の発注者にとっては酷な要求です。

そもそも、ここまで酷いものを納品する開発会社が存在するとは、夢にも思っていなかったでしょう。

そして、因果のバランスが悪すぎます。

我々業界側がなんとかしなければならないのでは、というのが、今回の問題提起です。

セキュリティ診断という選択肢

アプリケーションのセキュリティ診断を専門とする業者は少なからず存在しますが、
動的診断になると、概ね1APIあたり3〜5万円が相場のようで、アプリケーションの規模によっては数百万円になります。

モバイルアプリの診断まで入ってくるとさらに高額で、下手をすれば、開発金額を上回ってくることもあります。

この「界隈」の発注者にとっては、なかなか手が出ないのが実情です。

そもそもなんでそんな開発会社があるのか

これは超私見ですが、大きく分けて以下の2パターンがあるように思います。

独学独立パターン

独学でプログラミングを学び、そのまま勢いで仕事を受け、個人受託で独立、
場合によってはそのまま法人化までしてしまったパターンです。

このパターンの人全員が全員というわけではないですが、要求仕様を実現することに必死で、セキュリティに対する意識や知識が抜け落ちたまま、この仕事をしているケースがありそうです。

Web制作からの昇華パターン

Web制作をメインとしてきた会社が、背伸びしてシステムの仕事も受け始め、
エンジニアを採用して、レビュワーもいないまま1人で実装をさせているパターン。

あるいは、外注のフリーランスに丸投げしているパターンです。

何ができるか

パッと思いつくのは、システム開発業を認可制にして監督官庁をつけ、監査を入れるとか、

セキュアな開発ができる会社の認証制度を策定、普及させ、発注先選定の手掛かりにさせるとか。

あんまり現実的でもなく、実効性もなさそうです。

業界団体が存在し、協業が多く発生するような業界であれば、他社の品質を相互に把握でき、
業界団体が、業界外からの相談の受け皿にもなれるかもしれません。

しかしこの業界では、ほとんど見かけないですね。

そもそも開発者、開発会社を啓蒙すべき。

ド正論ですが、ZennやPHP Conferenceでいくら声高に叫んでも、届かない層は一定数います。

そもそも、品質は技術者個人の技量ではなく、プロセスで担保されるべきものですが、
現にそれを怠っているマネジメント層には、まず届かないでしょう。

発注者の啓蒙と診断のコモディティ化

非IT企業でも、新規事業やサービス充実のため、Webサービスを開発・運営するケースが増えているように感じます。

その際、どうしてもセキュリティ要件が漏れてしまったり、セキュリティ視点での納品検査ができなかったりします。

発注の際に開発会社に要求すべきセキュリティ要件を、非技術者でも理解できる形で、啓蒙していく必要があるように思います。

納品検査には、第三者の目を入れるべきことも、啓蒙していくべきです。

前述の通り一般的なセキュリティ診断は(この界隈にとっては)高額ですが、
例に上げた3つのケースは、数時間のコードレビューで、容易に脆弱性が発見できるものでした。

10〜20万の安価で簡易的な(それでいてクソレベルだけは確実に弾ける)静的診断が広く提供されるようになれば、
納品検査時に気軽に使ってもらえるようになるのではないでしょうか。

提供する側からすれば、責任が大きく、気軽には提供しづらいでしょうが、
発注者の啓蒙のためにも、我々が積極的にこうしたサービスを提供していくべきではないかと思います。

Discussion