セキュリティ検出ツールによってスキャンされたプロジェクト プログラムのセキュリティ脆弱性について質問がありますか?
- WBOYオリジナル
- 2016-08-04 09:20:471070ブラウズ
クライアント企業は私たちのプロジェクトを評価するために評価ソフトウェアを使用し、SQLインジェクションやxss攻撃を含むいくつかのセキュリティ脆弱性を発見しました。セキュリティ脆弱性が発生しているサーバー側のプログラムコードを調べたところ、それらは基本的に脆弱性であることが分かりました。ページ指向のサービスでは、エンドが get または post データを送信する場合に脆弱性が発生します。バックエンドは、ユーザーが入力した情報をフィルタリングできる CI フレームワークに付属する入力クラスを使用してデータを受信します。また、CI 構成アイテムにも同様の機能があります。オンになりましたcsrf
テストツール: 
- 最初に受信したものであり、プロジェクト内の他の場所でもこのように受信したのは当然です。なぜこのような抜け穴が依然として存在するのでしょうか。
get和post数据的代码是这样写的$this->input->get('section_id)データを受信するサーバーに問題がある場合、このメソッドを使用するプロジェクト内のすべての場所に抜け穴があるはずですが、なぜそのような抜け穴がいくつかの場所にのみ現れるのでしょうか? get、postお客様はテストデータしか見ていないのですが、どのように説明し、伝えればよいでしょうか- ?
アドバイスをお願いします〜
返信内容:
クライアント企業は私たちのプロジェクトを評価するために評価ソフトウェアを使用し、SQLインジェクションや
xss攻撃を含むいくつかのセキュリティ脆弱性を発見しました。セキュリティ脆弱性が発生しているサーバー側のプログラムコードを調べたところ、それらは基本的に脆弱性であることが分かりました。ページ指向のサービスでは、エンドが get または post データを送信する場合に脆弱性が発生します。バックエンドは、ユーザーが入力した情報をフィルタリングできる CI フレームワークに付属する入力クラスを使用してデータを受信します。また、CI 構成アイテムにも同様の機能があります。オンになりました
テストツール: csrf
脆弱性の概要:
当初は
を受信していましたが、プロジェクト内の他の場所でもこのように受信されており、フィルタリングとセキュリティ対策が講じられているのは当然です。なぜこのような抜け穴が依然として存在するのでしょうか。-
get和post数据的代码是这样写的$this->input->get('section_id)データを受信するサーバーに問題がある場合、このメソッドを使用するプロジェクト内のすべての場所に抜け穴があるはずですが、なぜそのような抜け穴がいくつかの場所にのみ現れるのでしょうか? -
?get、postお客様はテストデータしか見ていないのですが、どのように説明して伝えればよいでしょうか -
アドバイスをお願いします〜
1 この種のテストソフトの判定は必ずしも正確ではありません。一般的には、異なるステートメントを結合して返された結果の文字長が同じであるかどうかを判定するだけです。
2 あまり多くを入れないでください。グローバル フィルタリングは自分で行う必要があります。ここで検出された XSS はストレージ タイプではないため、リスクはそれほど高くありません。この種のレポートは、出発点として最もよく使用されます 4 クライアントが望んでいるのは、レポートに抜け穴がないという安心感です。 5 彼に脆弱性をスキャンできないようにしたい場合。プログラム エントリでログ ファイルを書き込み、すべてのリクエストとパラメータを記録して、スキャン ソフトウェアが脆弱性の有無をどのように判断するかを分析します。6 スキャン ソフトウェアのレポートの脆弱性を変更します。個人的な経験から、これは渡すパラメーターに intval がないはずです。
7 エラー挿入を防ぐために mysql エラー プロンプトをオフにします
予防策
1 グローバル SQL キーワード フィルタリングを追加します。プログラム
2 PHP の一重引用符エスケープを有効にします (php.ini magic_quotes_gpc を変更します)。
3 Apache/nginx/iis はサービスログ、mysql スロークエリログ、およびプログラムエントリレコードリクエストログを有効にします
4 サーバーはセキュリティドッグなどの Web アプリケーションセキュリティソフトウェアをインストールします
5 gbk double を防ぐためにデータベースリンクに UTF-8 を使用します-バイトインジェクション
6 機能強化 mysql パスワードの複雑さ、mysql 外部リンクの禁止、およびデフォルトのポート番号の変更
7 プログラム mysql アカウントの権限を削減し、通常の追加、削除、確認、および変更の権限のみを付与します。ファイル操作権限を与えることは禁止されています
XSS クロスサイト攻撃の解決策
1 htmlspecialchars を使用してテキストが書かれている場所をエスケープする
2 SSL を使用して外部 js の読み込みと参照を禁止する
3 httponly を設定して Cookie の取得を禁止する
4 上記は、インジェクションがないことを保証するためのものです (場合インジェクションがあり、16 進数を使用して htmlspecialchars をバイパスして xss 攻撃の効果を実現できます)
5 バックエンドとフロントエンドに異なるルーティング ルールを持つ 2 セットのプログラムを使用するのが最善です。主要なバックエンド操作 (バックアップ データベース) を設定する必要があります。セカンダリ パスワードを追加し、CSRF を防ぐために複雑なリクエスト パラメーターを追加します
PHPセキュリティ
1 ファイルがアップロードされる場所にサフィックスフィルタリングを追加し、フィルタリング時に「論理否定」の判断を行わないようにします。
2 拡張子 php および htaccess を含むファイルをアップロードすることは禁止されています。ファイル名の拡張子を取得するためにクライアントによって送信されたデータを使用しないでください。拡張子とランダムなファイル名を追加するプログラムを使用する必要があります。
3 統一ルーティングを使用して制限します。不正アクセス。ウェブルート ディレクトリには、外部防御用のindex.php (エントリ ファイル) を 1 つだけ含めることができます。他のすべてのディレクトリは、nginx のリーチ防止機能で追加されます
4. PHP 分散処理、 Web ディレクトリ フォルダーとテキストの作成を制限します (プログラムで必要なフォルダーを除き、通常は書き込み権限を必要とするキャッシュ ディレクトリがあります)
5 IIS/nginx ファイル解析の脆弱性エクスプロイトをフィルターします
6 携帯電話の確認コードを使用して、メールボックスの取得には追加のサーバーを使用する必要があります。 (パスワード取得機能を通じて実際の IP が取得されないようにします)。ユーザーのメールボックスに送信されるパスワードをリセットするための最後のリンクには、複雑な暗号化パラメーターが必要です。
7 ユーザー ログイン システムには、単一のログイン機能が必要です。ユーザーがログインしている場合、他のユーザーには再度ログインするように求められます。
8
1 セキュリティに関する知識
1 Web アプリケーションはサイト ライブラリの分離を使用し、環境の Web ディレクトリのデフォルト パスを変更します。
2 統合環境を使用する場合は、インストールが完了した後、phpmyadmin および phpinfo だけでなく php プローブも削除する必要があります (プローブは Web パスを表示でき、phpmyadmin は激しくクラッキングされる可能性があります)
2 ユーザーパスワードは、パスワードソルティング後の md5 値を使用するのが最善です
3 ユーザーがログインする場所に確認コードを追加し、エラー数の制限を追加する方法ブルートフォースクラッキングを防ぐため
4 CDN アクセラレーションを使用して実際の IP を非表示にする
5 ユーザーがログインするとき、C 側のスニッフィングを防止し、ARP スプーフィングを通じてユーザーと管理者の平文アカウントとパスワードを取得するために、平文のアカウントとパスワードを渡さないでください。
6 PHP システムコマンドライン番号 exec、system などを無効にします。
7 Security Dog などのセキュリティソフトウェアをサーバーにインストールします。
8 Web ディレクトリに .rar および zip ファイルを保存することは禁止されています
RSAS と BVS についての私の理解では、この問題を解決しないと常にスキャンされることになるということです。最も基本的な方法は、これらの問題を自分で解決し、脆弱性を発見することです。それが他人ではないのではないかと顧客は心配しています。バックドア プログラムを作成する際、一部の顧客は説明の余地をほとんど残していません。