\");\n echo(\"<\/div>\");\n echo(\"<\/form><\/body><\/html>\");\n}<\/pre>\n

?<\/p>\n

ご覧のとおり、リスト 1 のより危険なスクリプトは、セッション ディレクトリ內(nèi)のファイル (「セッション データの保護(hù)」を參照) や一部のシステム ファイル (たとえば、 \/etc\/passwd<\/code>)。デモンストレーションの目的で、この例ではユーザーがファイル名を入力できるテキスト ボックスを使用しますが、ファイル名はクエリ文字列で簡単に指定できます。 <\/p>\n

?<\/p>\n

ユーザー入力とファイル システム アクセスの同時(shí)構(gòu)成は危険であるため、同時(shí)構(gòu)成を避けるためにデータベースを使用し、生成されたファイル名を非表示にするようにアプリケーションを設(shè)計(jì)することが最善です。ただし、これが常に機(jī)能するとは限りません。リスト 2 は、ファイル名を検証するためのサンプル ルーチンを示しています。正規(guī)表現(xiàn)を使用してファイル名に有効な文字のみが使用されていることを確認(rèn)し、特にドット文字 ..<\/code> をチェックします。 <\/p>\n

?<\/h5>\n

リスト 2. 有効なファイル名文字のチェック<\/h5>\n

function isValidFileName($file) {\n    \/* don't allow .. and allow any \"word\" character \\ \/ *\/\n    return preg_match('\/^(((?:\\.)(?!\\.))|\\w)+$\/', $file);\n}<\/pre>\n
?<\/h2>\n
データベースを保護(hù)<\/h2>\n
2008 年 4 月、米國の州矯正局は、クエリ文字列で SQL 列名を使用して機(jī)密データを漏洩しました。この侵害により、悪意のあるユーザーが表示する列を選択し、ページを送信し、データを取得することが可能になりました。この侵害は、アプリケーション開発者が予期できない方法でユーザーがどのように入力を?qū)g行できるかを示し、SQL インジェクション攻撃を防御する必要性を示しています。 <\/p>\n
?<\/p>\n
リスト 3 は、SQL ステートメントを?qū)g行するサンプル スクリプトを示しています。この場合、SQL ステートメントは同じ攻撃を許可する動(dòng)的ステートメントです。このフォームの所有者は、列名を選択リストに制限しているため、フォームが安全であると考えている可能性があります。ただし、このコードには、フォームの不正行為に関する最後のヒントが 1 つ抜けています。コードがオプションをドロップダウン ボックスに制限しているからといって、他のユーザーが必要なコンテンツ (アスタリスク [*<\/code> を含む) を含むフォームを投稿できないというわけではありません。 ]）。 <\/p>\n
?<\/h5>\n
リスト 3. SQL ステートメントの実行<\/h5>\n
\n\n