2

ユーザーが私のサイトにアクセスすると、スクリプトはユーザー ID とパスワードの一部を保存する 2 つの Cookie をチェックして、自動的にログインします。

Cookie エディターを使用して Cookie の内容を編集することは可能ですが、書き込まれた Cookie に悪意のあるコンテンツを追加することは可能でしょうか?

すべての Cookie 呼び出しに (または何か他のものを)追加する必要mysql_real_escape_stringがありますか、それともこれを許可しない組み込みのプロシージャがありますか?

4

9 に答える 9

8

本当に必要なのは、そもそもハッキング可能なこれらの Cookie 値を送信しないことです。代わりに、ユーザー名とパスワード、および (秘密の) ソルトをハッシュして、それを Cookie 値として設定してみませんか? すなわち:

define('COOKIE_SALT', 'secretblahblahlkdsfklj');
$cookie_value = sha1($username.$password.COOKIE_SALT);

次に、Cookie の値が常に 40 文字の 16 進数の文字列になることがわかり、ユーザーが送り返した値とデータベース内の値を比較して、それらが有効かどうかを判断できます。

if ($user_cookie_value == sha1($username_from_db.$password_drom_db.COOKIE_SALT)) {
  # valid
} else {
  #not valid
}

mysql_real_escape_stringところで、データベースに追加のヒットを作成します (多くの人は、DB 接続が必要であり、MySQL にクエリを実行する必要があることに気づいていません)。

アプリを変更できず、ハッキング可能な Cookie 値を使用することを主張する場合に、必要なことを行う最善の方法は、パラメーターがバインドされた準備済みステートメントを使用することです。

于 2008-09-18T06:57:18.393 に答える
3

mysql_real_escape_string のポイントは、インジェクション攻撃から保護することではなく、データがデータベースに正確に格納されるようにすることです。したがって、ソースに関係なく、データベースに入るすべての文字列で呼び出す必要があります。

ただし、SQL インジェクションから身を守るために、(mysqli または PDO を介して) パラメータ化されたクエリも使用する必要があります。そうしないと、Bobby Tables の学校のようになってしまう危険があります。

于 2008-09-18T07:03:56.193 に答える
1

変数を SQL ステートメントに挿入する前に、mysql_real_escape_string のみを使用します。変数の一部がすでにエスケープされていると、混乱するだけで、もう一度エスケープします。これは、初心者のブログ Web アプリケーションで見られる典型的なバグです。

誰かがアポストロフィを書くと、スラッシュが追加され続け、\\\\\\\ のページが台無しになります。

変数の値自体は危険ではありません。それを文字列などに入れると、危険な海域に迷い込み始めます。

もちろん、クライアント側から来るものは決して信用しないでください。

于 2008-09-18T06:42:55.527 に答える
1

プリペアド ステートメントとパラメーター バインドは、常に適切な方法です。

PEAR::MDB2 は、次のようなプリペアド ステートメントをサポートしています。

$db = MDB2::factory( $dsn );

$types = array( 'integer', 'text' );
$sth = $db->prepare( "INSERT INTO table (ID,Text) (?,?)", $types );
if( PEAR::isError( $sth ) ) die( $sth->getMessage() );

$data = array( 5, 'some text' );
$result = $sth->execute( $data );
$sth->free();
if( PEAR::isError( $result ) ) die( $result->getMessage() );

これにより、適切なデータとあらかじめ設定された量の変数のみがデータベースに入ることができます。

もちろん、ここまで到達する前にデータを検証する必要がありますが、ステートメントの準備は、実行する必要がある最終的な検証です。

于 2008-09-18T09:07:28.533 に答える
0

有害な可能性があるものはすべて mysql_real_escape_string にする必要があります。ユーザーが変更できるタイプの入力は決して信用しないでください。

于 2008-09-18T06:36:28.163 に答える
0

仰るとおりです。Cookie を変更して、悪意のあるデータを送信することが可能です。

Cookie を使用する前に、Cookie から取得した値をフィルタリングすることをお勧めします。経験則として、改ざんされる可能性のあるその他の入力をフィルタリングします。

于 2008-09-18T06:38:19.843 に答える
0

mysql_real_escape_string は時代遅れです... 最近では、代わりにパラメーター バインディングを使用する必要があります。

準備されたステートメントを参照していたことに言及して詳しく説明し、mysl_real_escape_string では不十分な場合があることを示す記事へのリンクを提供します。http://www.webappsec.org/projects/articles/091007.txt

于 2008-09-18T06:43:13.967 に答える
0

Yegor、ユーザーアカウントが作成/更新されたときにハッシュを保存できます。その後、ログインが開始されるたびに、サーバーに投稿されたデータをハッシュし、その1つのユーザー名についてデータベースに保存されたものと比較します.

（ゆるいphpで頭のてっぺんから-疑似コードとして扱います）：

$usernameFromPostDbsafe = LimitToAlphaNumUnderscore($usernameFromPost);
$result = Query("SELECT hash FROM userTable WHERE username='$usernameFromPostDbsafe' LIMIT 1;");
$hashFromDb = $result['hash'];
if( (sha1($usernameFromPost.$passwordFromPost.SALT)) == $hashFromDb ){
    //Auth Success
}else{
   //Auth Failure
}

認証が成功した後、ハッシュを $_SESSION またはキャッシュされた認証済みユーザー名/ハッシュのデータベース テーブルに格納できます。次に、ハッシュをブラウザーに (たとえば Cookie で) 送り返します。これにより、後続のページの読み込みでハッシュがサーバーに送り返され、選択したセッション ストレージに保持されているハッシュと比較されます。

于 2008-09-18T07:25:12.430 に答える
-1

mysql_real_escape_string の代わりに htmlentities($input, ENT_QUOTES) を使用することをお勧めします。これにより、実際の HTML コードが誤って出力されることも防止できます。もちろん、mysql_real_escape_string と htmlentities を使用することもできますが、なぜ使用するのでしょうか?

于 2008-09-18T06:49:48.163 に答える