php - 主な機能を実装した後に Web アプリにセキュリティを実装することは合理的ですか?

Question

これが Stackoverflow に投稿するにはあまりにも漠然としているように思われる場合は、申し訳ありません。

私の会社は、PHP と MySQL を使用して、3 人の開発者を雇って案内広告システムを実装しました。彼らは、フレームワークを使用せずに (フレームワークの使用に反対した)、基本的な機能 (ユーザーの登録と認証、広告のリストとフィルタリングなど) を実装してから 1 か月あまり作業を続けています。ただし、簡単なテストでは、システムが一般的な悪意のある悪用 (CSRF、XSS、ローカル ファイル インクルージョン) に対して脆弱であることが示されています。

コードを調べたところ、サーバー側にデータ検証手順が実装されていないことがわかりました (メールアドレスの検証に正規表現を使用し、SQL インジェクションに対して文字列をサニタイズするために mysqli_real_escape_string() を使用しているだけです)。彼らはいくつかの検証ルーチンを実装しましたが、JavaScript を使用してクライアント側に実装しました。明らかに、これは UI の一部であり、悪意のあるユーザーに対してセキュリティを提供するものではありません。

彼らは、完全な Web アプリケーションをゼロから開発するには 3 人の開発者では不十分なので (同意します)、特定の期限に間に合わせるために、最初に機能を実装し、次にそれらを適切に保護するつもりであると主張しています。私は決して経験豊富なプログラマーではありませんが、事後的にセキュリティを実装するには時間がかかると思います。さらに、彼らが何とかそれを行うことができたとしても、最初から実装されたデータ サニタイズ ルーチンと比較すると、標準以下になるでしょう。

そこで、私の質問は次のとおりです。(i) 機能を実装した後にセキュリティを実装する (つまり、少なくとも適切なサニタイズ ルーチンを実装する) ことは合理的ですか? (ii) (i) の答えが「いいえ」の場合、セキュリティが十分に扱われていないプロジェクトを管理するために、どの参考文献、セキュリティ フレームワーク (ただし、それらは Web フレームワーク自体に埋め込まれていると思います) などをお勧めしますか?

Answer 1

いいえ、プロジェクトが完了した後にセキュリティを実装することは、さまざまな理由で受け入れられません。まず、すでに述べたように、この法案を支持している人は誰でも、必要な製品をすでに持っているときにセキュリティ機能を実装するためにお金を払い続ける可能性は低いです。2番目の理由は、最初に正しくコーディングして、そのコードを記述しているときにセキュリティ対策を実装するよりも、セキュリティの脆弱性をすべて調べて見つけようとするのにはるかに長い時間がかかるためです。この方法で行うと、エスケープデータなどを実行するセキュリティライブラリを記述できるため、エスケープ関数/メソッドを呼び出すだけでコードを記述できるようになります。3番目の理由は、コードを振り返ってすべての脆弱性を見つける方法がまったくないためです。セキュリティバグなしでコードを書くことは十分に困難です（ほぼ不可能を参照）。ましてや、コードをさかのぼってそれらのセキュリティの脆弱性をすべて見つけることはできません。

提案されたフレームワークについては、フレームワークも使用したことがないため、実際にはフレームワークを持っていません。使用するために過去に作成したライブラリのみを使用しています。しかし、これは単に優れた開発者を見つけることであり、超低価格でそれを成し遂げることができると言っている開発者ではありません。PHP開発者プールは、これらの中途半端な開発者でいっぱいであり、かなりの数の開発者が既成のフレームワークを好んでいると思います。秘訣は、最初から良いものを見つけることです。このように記述されていないアプリケーションを保護するために実際に使用できる唯一のオプションは、WAF（Webアプリケーションファイアウォール）を取得して、サーバーに送信される悪意のあるコンテンツをフィルタリングすることです。コードの記述が不十分な場合でも、これは特効薬ではありません。私はそれをバンドエイドとは呼びません。

最後に、これを書いている3人の人員が不足していることに私は非常に同意しません。私は4年前に自分で似たようなものを3か月足らずで書きました（htmlの人がいました）。この3か月のうち2か月は、セクションを完全に書き直したものでした。これは、クライアントが完了したら気が変わって、分類されたサイトというよりもソーシャルネットワークに変わるサイド機能を書き込んだためです。その時間内に自分でそのほとんどを行うことができれば、3人で1か月半で簡単に（そして安全に）それを成し遂げることができるはずです。

Answer 2

後でセキュリティを実装するのは本当に合理的ではありません。

時間がかからないか、標準以下である可能性があります。より高速で優れている可能性があります。問題は、プロジェクトが遅れて予算オーバーになるため、おそらくまったく行われないことです。

Rails、Symfony、または Django を使用した 1 週間の仕事のように見えるフレームワークを使用しないという決定に驚いています。セキュリティが組み込まれているはずです。

Answer 3

セキュリティは、開発段階で常に考慮に入れる必要があります。セキュリティが見過ごされたり無視されたりした場合は、開発中の API の改善は、最初に利用可能なインスタンスで構築する必要があります。

最後にやりたいことは、コード構造自体に多くのセキュリティ/悪意のある穴があるスクリプトを公開することです。

したがって、これらの開発者には、自分の作業を確認し、既に作成された API に適切な変更を加えてセキュリティを強化するよう通知することをお勧めします。

セキュリティの側面が見落とされ、変更されていない場合、プロジェクトは遅れて予算を超えて終了する可能性があります. 手遅れになる前に、この問題に正面から取り組むことをお勧めします (公開トラフィックにリリースし、予想よりも長いダウンタイムに直面した場合)。

全体的なポイント..深刻な問題になる前に、お尻に釘付けにします。

Answer 4

他の人が提案したことを追加するだけで、最初からセキュリティを受け入れる必要があります。

これを行わないと、コードにエラーやバグが発生しやすくなります。

Microsoft Secure Development Lifecycle をご覧ください。

http://www.microsoft.com/security/sdl/default.aspx

また、潜在的な問題を特定するために、コードを確認するかペンテストすることをお勧めします。

ありがとうファビオ @fcerullo

Answer 5

開発の後期段階でセキュリティ問題に対処することは、それが単なる実装上の問題であり、設計上の根本的な欠陥でない限り、不合理ではありません。「安全性が高い」または「安全性が低い」というものはありません。システムが保護されているか、そうでないかのどちらかです。アプリケーションの動作を全体として考慮する必要があります。そのため、コードベースがまだ流動的である間にセキュリティを処理することは、それほど有益ではありません。セキュリティは開発プロセス全体に不可欠であると言うのが流行していますが、リソースが限られている世界では、そのようなアプローチは実用的というより学術的です。納品前に品質保証のための十分な時間を確保することで、より良いリターンが得られる可能性が高くなります。