web-dev-qa-db-ja.com

ハッカーは、以下の機能を使用しているサーバーファイルとデータベースを削除できますか？

ハッカーからウェブサイトを保護する方法を知りたい。私はphp-mysql開発者です。データベースからデータをフェッチするには、常にMySQLiを使用します。私のウェブサイトをSQLインジェクションから防ぐために、私は常にPHPの$db->real_esacpe_string()関数を使用しています。私のWebサイトがXSS（クロスサイトスクリプティング）にならないようにするために、次の関数を使用しました。

function parsing($text)
{
global $db;
        $text=$db->real_escape_string($text);
 $text= @trim($text);
       $text= strip_tags($text);
 if(get_magic_quotes_gpc()) {
            $text= stripslashes($text);
        }
    $text=str_replace('<','',$text);
    $text=str_replace('>','',$text);   
       $text=htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
    return($text);
}
$name=parsing($_POST['name']);

あなたの側からの提案は大歓迎です。前もって感謝します。

phpxsswebservermysql
2
Dinesh Gurjar

正直言って、この関数は多かれ少なかれ役に立たないか有害であり、時には矛盾する手順の任意のコレクションであり、そのほとんどはセキュリティとはまったく関係ありません。今最も重要な部分に。

SQLインジェクション

私のウェブサイトをSQLインジェクションから防ぐために、私は常に$db->real_esacpe_string()を使用します

それはあなたが間違っていることです。あなただけではありませんが、私はそれを 最も悪名高いPHP妄想 としてリストします。そのページからの引用：

この関数は、安全性や注入とはまったく関係がなく、SQL文字列リテラル内の特殊文字をエスケープするだけで、副作用としてSQLインジェクションの影響を受けませんが、テーブル名から数値リテラルまで、他のクエリ部分にはまったく役に立ちません。 。 SQLインジェクションから保護するには、2つの単純なルールに従う必要があります。

  • 変数データリテラル（文字列や数値など）はすべてパラメータで置き換える必要がありますが、実際の値はバインド/実行プロセスを通じてクエリに個別に送信する必要があります。
  • たまたま変数を介して追加される他のすべてのクエリ部分は、許可された値のハードコードされたリストによって明示的にフィルタリングする必要があります。

生のmysqliは準備されたステートメントではかなり厳しいので、代わりにPDOを使用することを強くお勧めします。

したがって、SQLセキュリティに関連するものはすべてそのような関数に含まれるべきではないという主な考えはまったくありません。

XSS

悪意のある_<_および_>_文字で何をしているのか見てみましょう。

  • 最初に、すべてのタグがstrip_tags($text);によって削除されます
  • 次に、これらの記号（すでにテキストから削除されています）は空の文字列に置き換えられます
  • 最後に、存在しない文字がHTMLエンティティに変換されます

「過剰」を定義するように依頼された場合は、この機能を紹介します。 htmlspecialchars()だけで、ページ本文のXSSを防ぐことができます。

さらに重要なのは、間違ったデータ入力でこの関数を使用しているようです。特定のメディアのフォーマットルールに従って、テキストを出力の直前にフォーマットする必要があります。 HTMLページ本文に出力する場合は、htmlspecialcharsになります。テキストがJavaScriptに送られる場合は、別のフォーマットにする必要があります。

役に立たないもの

  • trim()はセキュリティとは何の関係もありません。この関数を使用すると便利です。
    • 余談ですが、この_@_演算子を使用しないでください。それはあなたのプログラミング経験にとって有害で​​す。
  • stripslashes()も、セキュリティとは関係ありません。その上、この関数は役に立たないだけで、まったく賢明なことをすることはありません。
  • 言うまでもなく、get_magic_quotes_gpc()は2度役に立たず、10年前にPHP=）から削除された値を返します。

結論

  • この関数を取り除く
  • sQLインジェクションを防ぐには、上記の2つのルールに従います
  • xSSがデータまたはその他の適切なフォーマットを出力するときにhtmlspecialcharsを使用しないようにします。
6
Your Common Sense

@YourCommonSenseの答えは良いですが、少し追加すると、SQLiとXSSだけが重要なWebアプリケーションセキュリティの脅威ではありません！実際、コマンドインジェクション（特にユーザーが指定した入力を含むシェルでサーバーがコマンドを実行する場合のリスク）やその他の方法など、私はそれらの上にかなりの数を置きます。潜在的に任意のコード実行を取得する（実行可能ファイルのアップロードと実行、逆シリアル化攻撃など）。この種の攻撃は、いずれにせよ、誰かがXSSやSQLiよりもサーバーファイルを削除する可能性が高くなります。

あなたのサイトが何をしているか、そしてそのセキュリティモデルについてもっと知らなければ、私はあなたが危険にさらされているセキュリティの脆弱性の適切なリストを作成することはできませんが、XSSとSQLi以上のものであることを保証します。たとえば、CSRFはほぼ間違いなくリスクです。認証とセッション管理を間違って実行する方法は山ほどあります。あらゆる種類のファイルのアップロードは潜在的なリスクです。 XMLの処理はリスクです。暗号化を行うことは、正しく行うのが非常に困難です。クリックジャッキングはリスクです。これは、決して完全なリストではありませんが、うまくいけば、あなたはそのアイデアを理解できます。

OWASPは、Webアプリケーションの安全性を確保するための信じられないほど幅広い方法について学ぶための適切な場所です。

2
CBHacking