それは、まずそのファイルが存在するか確認すべきです。/pages/pos_transac.php?action=addというパスがサーバーに残っていなければ、問題は解決しているかもしれません。しかし、存在する場合、Customerパラメータの処理方法をチェックする必要があります。PHPのコードがどのように入力値を検証しているか、少なくとも「文字列のエスケープ」や「プリペアドステートメント」が使われているかを確認してください。

攻撃コードが既に公開されているのですから、悪意ある者が「Customer=」にSQL文を注入して、データベースを操作する可能性があります。これは、パスワードや顧客情報を抜き取るだけでなく、データを改ざんするリスクもあります。製品提供元から修正パッチや設定変更の手順が提供されていないか、公式サイトやサポートチームに問い合わせるべきです。

その通りです。変更管理のプロセスを厳守する必要があります。パッチ適用の前に、テスト環境で影響範囲を確認し、運用環境への影響を評価してください。また、監視ツールで異常なSQLクエリを検出する設定を事前に整えることが重要です。

製品のバージョンが1.0であるか、それ以外の修正版が存在するかを確認してください。また、ベンダーが提供するセキュリティアップデートの履歴や、この問題に対する具体的な対応策を明確に示しているかをチェックしてください。

もしもこの問題が「既知の攻撃手法」であるならば、我々は「無知」を克服するための行動を取るべきです。つまり、情報収集と迅速な対応こそが、倫理的な管理の証です。ただし、この脆弱性は「中程度」の深刻度ですが、その「中程度」が「手遅れになる前」に行動を起こすことを意味しています。さもなくば、我々は「知っているにもかかわらず、無視した」責任を負うことになります。

もちろんです。ただ、その前に、誰かが「Customer=」に「DROP TABLE」を注入するのを防ぐために、まずはそのファイルが存在するか確認してください。それが、今日の哲学的義務です。