mysql_real_escape_string()を回避するSQLインジェクション

678
Richard Knop 2011-04-21 21:56.

mysql_real_escape_string()関数を使用している場合でもSQLインジェクションの可能性はありますか?

このサンプルの状況を考えてみましょう。SQLは次のようにPHPで構築されます。

$login = mysql_real_escape_string(GetFromPost('login')); $password = mysql_real_escape_string(GetFromPost('password'));

$sql = "SELECT * FROM table WHERE login='$login' AND password='$password'";

そのようなコードはまだ危険であり、mysql_real_escape_string()関数を使用してもハッキングされる可能性があると多くの人が私に言うのを聞いたことがあります。しかし、私は考えられるエクスプロイトを考えることができませんか?

このような古典的な注射:

aaa' OR 1=1 --

動作しない。

上記のPHPコードを通過する可能性のあるインジェクションを知っていますか?

4 answers

393
Wesley van Opdorp 2011-04-21 22:05.

次のクエリについて考えてみます。

$iId = mysql_real_escape_string("1 OR 1=1"); $sSql = "SELECT * FROM table WHERE id = $iId";

mysql_real_escape_string()これからあなたを保護しません。クエリ内の変数を一重引用符(' ')で囲むという事実が、これからユーザーを保護します。以下もオプションです。

$iId = (int)"1 OR 1=1";
$sSql = "SELECT * FROM table WHERE id = $iId";
652
ircmaxell 2012-08-25 16:08.

簡単な答えは「はい」です。「はい」を回避する方法がありますmysql_real_escape_string()。#非常にあいまいなエッジの場合!!!

長い答えはそれほど簡単ではありません。これは、ここで示されている攻撃に基づいています。

攻撃

それでは、攻撃を示すことから始めましょう...

mysql_query('SET NAMES gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*"); mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

特定の状況では、それは複数の行を返します。ここで何が起こっているのかを分析しましょう:

  1. 文字セットの選択

    mysql_query('SET NAMES gbk');
    

    仕事へのこの攻撃のために、我々は、サーバーの両方のエンコードへの接続に期待していることエンコーディングを必要とする'ASCII、すなわちのように0x27 してその最後のバイトASCIIであるいくつかの文字持っている\すなわち0x5c。結局のところ、デフォルトでのMySQL 5.6でサポートされている5つのなどのエンコーディングがありますbig5cp932gb2312gbksjisgbkここで選択します。

    さて、SET NAMESここでの使用に注意することは非常に重要です。これにより、サーバー上の文字セットが設定されます。C API関数の呼び出しを使用した場合は、mysql_set_charset()問題ありません(2006年以降のMySQLリリースの場合)。しかし、なぜすぐに...

  2. ペイロード

    この注入に使用するペイロードは、バイトシーケンスで始まります0xbf27。ではgbk、これは無効なマルチバイト文字です。でlatin1、それは文字列¿'です。latin1 gbk0x27、それ自体がリテラル'文字であることに注意してください。

    このペイロードを選択したのは、それを呼び出すと、文字の前にaddslashes()ASCII、\つまり0x5c、が挿入されるため'です。我々が羽目になるだろうので0xbf5c27、その中にはgbk、2つの文字列です:0xbf5c続きます0x27。つまり、有効な文字の後にエスケープされていない'。が続きます。ただし、は使用していませんaddslashes()。次のステップに進みます...

  3. mysql_real_escape_string()

    へのCAPI呼び出しmysql_real_escape_string()addslashes()、接続文字セットを認識しているという点で異なります。そのため、サーバーが期待している文字セットに対して適切にエスケープを実行できます。ただし、この時点まで、クライアントは、他の方法で通知したことがないlatin1ため、接続にまだ使用していると考えています。使用しているサーバーに通知しましたgbkが、クライアントはそれでもそうだと考えていlatin1ます。

    したがって、への呼び出しmysql_real_escape_string()は円記号を挿入'し、「エスケープされた」コンテンツには自由にぶら下がっている文字があります。私たちが見にした場合、実際には、$var中にgbk文字セット、我々は参照してくださいね。

    縗 'または1 = 1 / *

    これはまさに攻撃に必要なものです。

  4. クエリ

    この部分は形式的なものですが、レンダリングされたクエリは次のとおりです。

    SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1
    

おめでとうございます、あなたはmysql_real_escape_string()...を使用してプログラムを攻撃することに成功しました。

悪い人

ひどくなる。PDOデフォルトでは、MySQLでプリペアドステートメントをエミュレートします。つまり、クライアント側では、基本的にmysql_real_escape_string()(Cライブラリで)sprintfを実行します。つまり、次の結果、インジェクションが成功します。

$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

ここで、エミュレートされた準備済みステートメントを無効にすることで、これを防ぐことができることに注意してください。

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

これにより、通常、真のプリペアドステートメントが生成されます(つまり、データはクエリとは別のパケットで送信されます)。ただし、PDOは、MySQLがネイティブに準備できないステートメントのエミュレートにサイレントにフォールバックすることに注意してください。マニュアルにリストされているステートメントですが、適切なサーバーバージョンを選択するように注意してください)。

ぶさいく

mysql_set_charset('gbk')代わりに使用すれば、これらすべてを防ぐことができたはずだと最初に言いましたSET NAMES gbk。2006年以降のMySQLリリースを使用している場合は、これが当てはまります。

あなたは以前のMySQLリリース、その後、使用している場合はバグではmysql_real_escape_string()、そのような私たちのペイロードのものと無効なマルチバイト文字が目的を脱出するための単一のバイトとして扱われたことを意味し、クライアントが正しく接続エンコーディングを知らされていた場合でもので、この攻撃は希望とをまだ成功しています。バグがMySQLの中で修正されました4.1.20、5.0.22および5.1.11。

しかし、最悪の部分は、5.3.6までPDOC APIを公開しなかったmysql_set_charset()ため、以前のバージョンで、考えられるすべてのコマンドに対してこの攻撃を防ぐことはできません。これで、DSNパラメーターとして公開されます。

節約の恵み

冒頭で述べたように、この攻撃が機能するには、脆弱な文字セットを使用してデータベース接続をエンコードする必要があります。utf8mb4脆弱ではありませんが、すべてのUnicode文字をサポートできます。そのため、代わりにそれを使用することを選択できますが、MySQL5.5.3以降でのみ使用可能になっています。代替手段はですutf8。これも脆弱ではなく、Unicode Basic MultilingualPlane全体をサポートできます。

または、NO_BACKSLASH_ESCAPESSQLモードを有効にすることもできます。これにより、(とりわけ)の操作が変更されmysql_real_escape_string()ます。このモードを有効に0x27すると、0x2727ではなくに置き換えられる0x5c27ため、エスケーププロセスは、以前は存在しなかった(つまり、まだ存在するなど)脆弱なエンコーディングで有効な文字を作成できません。したがって、サーバーは文字列を無効として拒否します。 。ただし、このSQLモードの使用から発生する可能性のある別の脆弱性については、@ eggyalの回答を参照してください。0xbf270xbf27

安全な例

次の例は安全です。

mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*"); mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

サーバーが期待しているのでutf8...

mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*"); mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

クライアントとサーバーが一致するように文字セットを適切に設定したためです。

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); $pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

エミュレートされたプリペアドステートメントをオフにしたためです。

$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

文字セットを正しく設定したからです。

$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*"; $stmt->bind_param('s', $param); $stmt->execute();

MySQLiは常に真のプリペアドステートメントを実行するからです。

まとめ

もし、あんたが:

  • 使用現代のMySQLのバージョンの(故5.1、すべて5.5、5.6、など)AND mysql_set_charset() / $mysqli->set_charset()(PHP 5.3.6≥中)/ PDOのDSNのcharsetパラメータ

または

  • 接続エンコーディングに脆弱な文字セットを使用しないでください(utf8/ latin1/ ascii/などのみを使用します)

あなたは100%安全です。

それ以外の場合は、使用しているにもかかわらずmysql_real_escape_string()脆弱です...

190
eggyal 2014-04-25 09:15.

TL; DR

mysql_real_escape_string()次の場合は、保護提供しません(さらに、データを破壊する可能性があります)。

  • MySQLのNO_BACKSLASH_ESCAPESSQLモードが有効になっています(接続するたびに別のSQLモードを明示的に選択しない限り、有効になっている可能性があります)。そして

  • SQL文字列リテラルは二重引用符を使用して引用符で囲まれます"

これはバグ#72458として報告され、MySQL v5.7.6で修正されました(以下の「TheSavingGrace」という見出しのセクションを参照してください)。

これは別の、(おそらく少ないですか?)あいまいなエッジケースです!!!

@ircmaxellの優れた回答に敬意を表して(実際、これは剽窃ではなくお世辞であるはずです!)、私は彼の形式を採用します。

攻撃

デモンストレーションから始めます...

mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"'); // could already be set
$var = mysql_real_escape_string('" OR 1=1 -- '); mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

これにより、testテーブルからすべてのレコードが返されます。解離:

  1. SQLモードの選択

    mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
    

    文字列リテラルで文書化されているように:

    文字列内に引用符を含めるには、いくつかの方法があります。

    • '」で引用された文字列内の「'」は、「」と書くことができます''

    • "」で引用された文字列内の「"」は、「」と書くことができます""

    • 引用文字の前にエスケープ文字(“ \”)を付けます。

    • '」で引用された文字列内の「"」は、特別な処理を必要とせず、二重化またはエスケープする必要もありません。同様に、「"」で引用された文字列内の「'」は、特別な処理を必要としません。

    サーバーのSQLモードにが含まれている場合、NO_BACKSLASH_ESCAPESこれらのオプションの3番目(で採用されている通常のアプローチ)mysql_real_escape_string()は使用できません。代わりに、最初の2つのオプションのいずれかを使用する必要があります。4番目の箇条書きの効果は、データの改ざんを避けるために、リテラルを引用するために使用される文字を必ず知っている必要があることに注意してください。

  2. ペイロード

    " OR 1=1 -- 
    

    ペイロードは、文字通り文字通りこの注入を開始し"ます。特定のエンコーディングはありません。特殊文字はありません。奇妙なバイトはありません。

  3. mysql_real_escape_string()

    $var = mysql_real_escape_string('" OR 1=1 -- ');
    

    幸い、mysql_real_escape_string()SQLモードをチェックし、それに応じて動作を調整します。参照libmysql.c

    ulong STDCALL
    mysql_real_escape_string(MYSQL *mysql, char *to,const char *from,
                 ulong length)
    {
      if (mysql->server_status & SERVER_STATUS_NO_BACKSLASH_ESCAPES)
        return escape_quotes_for_mysql(mysql->charset, to, 0, from, length);
      return escape_string_for_mysql(mysql->charset, to, 0, from, length);
    }
    

    したがって、SQLモードが使用escape_quotes_for_mysql()されている場合は、別の基礎となる関数、が呼び出さNO_BACKSLASH_ESCAPESれます。上記のように、このような関数は、他の引用文字がリテラルで繰り返されることなくそれを繰り返すために、リテラルを引用するためにどの文字が使用されるかを知る必要があります。

    ただし、この関数、文字列が一重引用符を使用して引用符で囲まれることを任意に想定しています'。参照charset.c

    /*
      Escape apostrophes by doubling them up
    
    // [ deletia 839-845 ]
    
      DESCRIPTION
        This escapes the contents of a string by doubling up any apostrophes that
        it contains. This is used when the NO_BACKSLASH_ESCAPES SQL_MODE is in
        effect on the server.
    
    // [ deletia 852-858 ]
    */
    
    size_t escape_quotes_for_mysql(CHARSET_INFO *charset_info,
                                   char *to, size_t to_length,
                                   const char *from, size_t length)
    {
    // [ deletia 865-892 ]
    
        if (*from == '\'')
        {
          if (to + 2 > to_end)
          {
            overflow= TRUE;
            break;
          }
          *to++= '\'';
          *to++= '\'';
        }
    

    したがって、リテラルの引用に使用される実際の文字に関係なく、二重引用符はそのままにします"(そして、すべての一重引用符の文字を2倍にします')。私たちの場合、に提供された引数とまったく同じままです—それはまるでエスケープがまったく行わていないかのようです。$varmysql_real_escape_string()

  4. クエリ

    mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');
    

    形式的なもので、レンダリングされたクエリは次のとおりです。

    SELECT * FROM test WHERE name = "" OR 1=1 -- " LIMIT 1
    

私の学んだ友人が言ったように:おめでとうございます、あなたはちょうどmysql_real_escape_string()...を使用してプログラムを攻撃することに成功しました。

悪い人

mysql_set_charset()これは文字セットとは何の関係もないので、仕方がありません。またmysqli::real_escape_string()、これは同じ関数のラッパーが異なるだけなので、できません。

問題は、まだ明らかではmysql_real_escape_string() ないにしても、後で決定するのは開発者に任されているため、リテラルがどの文字で引用されるを呼び出すことができないことです。したがって、NO_BACKSLASH_ESCAPESモードでは、この関数がすべての入力を安全にエスケープして任意の引用符で使用する方法は文字通りありません(少なくとも、2倍にする必要のない文字を2倍にして、データを変更する必要はありません)。

ぶさいく

ひどくなる。NO_BACKSLASH_ESCAPES標準SQLとの互換性のために使用する必要があるため、実際にはそれほど珍しいことではないかもしれません(たとえば、SQL-92仕様のセクション5.3 、つまり<quote symbol> ::= <quote><quote>文法の生成とバックスラッシュに与えられた特別な意味の欠如を参照してください)。さらに、ircmaxellの投稿で説明されている(修正されてから長い間)バグの回避策として、その使用が明示的に推奨されていました。誰が知っているか、一部のDBAは、のような誤ったエスケープ方法の使用を思いとどまらせる手段として、デフォルトでオンになるように構成することさえあります。addslashes()

また、新しい接続のSQLモードは、サーバーの構成に従ってサーバーによって設定されます(SUPERユーザーはいつでも変更できます)。したがって、サーバーの動作を確認するには、接続後に常に目的のモードを明示的に指定する必要があります。

節約の恵み

だから、限り、あなたはいつものように明示的に含まれないSQLモードを設定しNO_BACKSLASH_ESCAPES、それぞれ:、または単一引用符文字を使用してMySQLの文字列リテラルを引用し、このバグはリアないその醜い頭できescape_quotes_for_mysql()使用されることはありません、または引用符が意志を繰り返す必要かについての仮定正しいこと。

このため、一重引用符で囲まれた文字列リテラルを習慣的に使用することになるため、モードをNO_BACKSLASH_ESCAPES有効にすることをお勧めしANSI_QUOTESます。これは、二重引用符で囲まれたリテラルが使用された場合のSQLインジェクションを妨げるものではなく、その可能性を減らすだけであることに注意してください(通常の悪意のないクエリは失敗するため)。

PDOでは、同等の関数PDO::quote()とプリペアドステートメントエミュレーターの両方が要求します。mysql_handle_quoter()これはまさにこれを行います。エスケープされたリテラルが一重引用符で囲まれていることを保証するため、PDOは常にこのバグの影響を受けません。

MySQL v5.7.6以降、このバグは修正されています。変更ログを参照してください:

追加または変更された機能

  • 互換性のない変更: SQLモードが有効になっmysql_real_escape_string_quote()ているmysql_real_escape_string()と、後者の関数が文字を適切にエンコードできない可能性があるため、の代わりに新しいCAPI関数が実装されNO_BACKSLASH_ESCAPESました。この場合、mysql_real_escape_string()引用符を2倍にする以外にエスケープすることはできません。これを適切に行うには、引用符のコンテキストについて、利用可能な情報よりも多くの情報を知っている必要があります。mysql_real_escape_string_quote()引用コンテキストを指定するための追加の引数を取ります。使用法の詳細については、 mysql_real_escape_string_quote()を参照してください。

     注意

    アプリケーションはmysql_real_escape_string_quote()、の代わりにを使用するように変更する必要がmysql_real_escape_string()ありCR_INSECURE_API_ERRますNO_BACKSLASH_ESCAPES。これは、有効にすると失敗してエラーを生成するようになりました。

    参照:バグ#19211994も参照してください。

安全な例

ircmaxellによって説明されたバグと合わせて、次の例は完全に安全です(4.1.20、5.0.22、5.1.11以降のMySQLを使用している、またはGBK / Big5接続エンコーディングを使用していないと仮定)。 :

mysql_set_charset($charset);
mysql_query("SET SQL_MODE=''");
$var = mysql_real_escape_string('" OR 1=1 /*'); mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

...を含まないSQLモードを明示的に選択したためNO_BACKSLASH_ESCAPESです。

mysql_set_charset($charset); $var = mysql_real_escape_string("' OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

...文字列リテラルを一重引用符で引用しているためです。

$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1'); $stmt->execute(["' OR 1=1 /*"]);

... PDOプリペアドステートメントはこの脆弱性の影響を受けないため(PHP≥5.3.6を使用していて文字セットがDSNで正しく設定されているか、プリペアドステートメントのエミュレーションが無効になっている場合はircmaxellも同様です) 。

$var = $pdo->quote("' OR 1=1 /*");
$stmt = $pdo->query("SELECT * FROM test WHERE name = $var LIMIT 1");

... PDOのquote()関数はリテラルをエスケープするだけでなく、(一重引用符で')引用符で囲むためです。この場合ircmaxellのバグを回避するためにそのノートは、あなたがしなければならないPHP≥5.3.6を使用することにし、正しくDSNの文字セットを設定しています。

$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1'); $param = "' OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

... MySQLiで準備されたステートメントは安全だからです。

まとめ

したがって、次の場合:

  • ネイティブのプリペアドステートメントを使用する

または

  • MySQLv5.7.6以降を使用する

または

  • ircmaxellの要約にあるソリューションの1つを採用することに加えて、次の少なくとも1つを使用してください。

    • PDO;
    • 一重引用符で囲まれた文字列リテラル。または
    • を含まない明示的に設定されたSQLモード NO_BACKSLASH_ESCAPES

...その後、完全に安全である必要があります(文字列のエスケープの範囲外の脆弱性は脇に置きます)。

19
Slava 2011-04-21 22:01.

まあ、%ワイルドカード以外に、それを通過できるものは何もありません。LIKEステートメントを使用している%場合、それをフィルターで除外しないと攻撃者がログインと同じように配置する可能性があり、ユーザーのパスワードをブルートフォースする必要があるため、危険な場合があります。データがクエリ自体に干渉することはないため、プリペアドステートメントを使用して100%安全にすることを提案することがよくあります。しかし、そのような単純なクエリの場合、次のようなことを行う方がおそらく効率的です。$login = preg_replace('/[^a-zA-Z0-9_]/', '', $login);

Related questions

MORE COOL STUFF

「水曜日」シーズン1の中心には大きなミステリーがあります

「水曜日」シーズン1の中心には大きなミステリーがあります

Netflixの「水曜日」は、典型的な10代のドラマ以上のものであり、実際、シーズン1にはその中心に大きなミステリーがあります.

ボディーランゲージの専門家は、州訪問中にカミラ・パーカー・ボウルズが輝くことを可能にした微妙なケイト・ミドルトンの動きを指摘しています

ボディーランゲージの専門家は、州訪問中にカミラ・パーカー・ボウルズが輝くことを可能にした微妙なケイト・ミドルトンの動きを指摘しています

ケイト・ミドルトンは、州の夕食会と州の訪問中にカミラ・パーカー・ボウルズからスポットライトを奪いたくなかった、と専門家は言う.

一部のファンがハリー・スタイルズとオリビア・ワイルドの「非常に友好的な」休憩が永続的であることを望んでいる理由

一部のファンがハリー・スタイルズとオリビア・ワイルドの「非常に友好的な」休憩が永続的であることを望んでいる理由

一部のファンが、オリビア・ワイルドが彼女とハリー・スタイルズとの間の「難しい」が「非常に友好的」な分割を恒久的にすることを望んでいる理由を見つけてください.

エリザベス女王の死後、ケイト・ミドルトンはまだ「非常に困難な時期」を過ごしている、と王室の専門家が明らかにする 

エリザベス女王の死後、ケイト・ミドルトンはまだ「非常に困難な時期」を過ごしている、と王室の専門家が明らかにする&nbsp;

エリザベス女王の死後、ケイト・ミドルトンが舞台裏で「非常に困難な時期」を過ごしていたと伝えられている理由を調べてください.

セントヘレナのジェイコブのはしごを登るのは、気弱な人向けではありません

セントヘレナのジェイコブのはしごを登るのは、気弱な人向けではありません

セント ヘレナ島のジェイコブズ ラダーは 699 段の真っ直ぐ上る階段で、頂上に到達すると証明書が発行されるほどの難易度です。

The Secrets of Airline Travel Quiz

The Secrets of Airline Travel Quiz

Air travel is far more than getting from point A to point B safely. How much do you know about the million little details that go into flying on airplanes?

Where in the World Are You? Take our GeoGuesser Quiz

Where in the World Are You? Take our GeoGuesser Quiz

The world is a huge place, yet some GeoGuessr players know locations in mere seconds. Are you one of GeoGuessr's gifted elite? Take our quiz to find out!

バイオニック読書はあなたをより速く読むことができますか?

バイオニック読書はあなたをより速く読むことができますか?

BionicReadingアプリの人気が爆発的に高まっています。しかし、それは本当にあなたを速読術にすることができますか?

パンデミックは終わったかもしれないが、Covid-19 は終わっていない

パンデミックは終わったかもしれないが、Covid-19 は終わっていない

2021 年 6 月 8 日にニューヨーク市で開催された covid-19 パンデミックで亡くなった人々の命を偲び、祝うために、ネーミング ザ ロスト メモリアルズが主催するイベントと行進の最中に、グリーンウッド墓地の正門から記念碑がぶら下がっています。週末、ジョー・バイデン大統領は、covid-19 パンデミックの終息を宣言しました。これは、過去 2 年以上にわたり、公の場でそうするための長い列の中で最新のものです。

デビル・イン・オハイオの予告編は、エミリー・デシャネルもオハイオにいることを明らかにしています

デビル・イン・オハイオの予告編は、エミリー・デシャネルもオハイオにいることを明らかにしています

オハイオ州のエミリー・デシャネル みんな早く来て、ボーンズが帰ってきた!まあ、ショーボーンズではなく、彼女を演じた俳優. エミリー・デシャネルに最後に会ってからしばらく経ちました.Emily Deschanel は、長期にわたるプロシージャルな Bones の Temperance “Bones” Brennan としてよく知られています。

ドナルド・トランプはFBIのマー・ア・ラーゴ襲撃映像をリリースする予定ですか?

ドナルド・トランプはFBIのマー・ア・ラーゴ襲撃映像をリリースする予定ですか?

どうやら、ドナルド・トランプに近い人々は、今月初めにFBIによって家宅捜索された彼のMar-a-Lago財産からの映像を公開するよう彼に勧めています. 前大統領はテープを公開するかどうかを確認していませんが、息子はフォックス・ニュースにそうなるだろうと語った.

Andor は、他の Star Wars ショーから大きな距離を置きます。

Andor は、他の Star Wars ショーから大きな距離を置きます。

アンドールの一場面。数十年前、ジョージ・ルーカスがスター・ウォーズのテレビ番組を制作するのを妨げた主な理由は、お金でした。

ケイト・ミドルトンとウィリアム王子は、彼らが子供たちと行っているスパイをテーマにした活動を共有しています

ケイト・ミドルトンとウィリアム王子は、彼らが子供たちと行っているスパイをテーマにした活動を共有しています

ケイト・ミドルトンとウィリアム王子は、子供向けのパズルの本の序文を書き、ジョージ王子、シャーロット王女、ルイ王子と一緒にテキストを読むと述べた.

事故で押しつぶされたスイカは、動物を喜ばせ水分補給するために野生生物保護団体に寄付されました

事故で押しつぶされたスイカは、動物を喜ばせ水分補給するために野生生物保護団体に寄付されました

Yak's Produce は、数十個のつぶれたメロンを野生動物のリハビリ専門家であるレスリー グリーンと彼女のルイジアナ州の救助施設で暮らす 42 匹の動物に寄付しました。

デミ・ロヴァートは、新しいミュージシャンのボーイフレンドと「幸せで健康的な関係」にあります: ソース

デミ・ロヴァートは、新しいミュージシャンのボーイフレンドと「幸せで健康的な関係」にあります: ソース

8 枚目のスタジオ アルバムのリリースに向けて準備を進めているデミ ロヴァートは、「スーパー グレート ガイ」と付き合っている、と情報筋は PEOPLE に確認しています。

Plathville の Kim と Olivia Plath が数年ぶりに言葉を交わすことへようこそ

Plathville の Kim と Olivia Plath が数年ぶりに言葉を交わすことへようこそ

イーサン プラスの誕生日のお祝いは、TLC のウェルカム トゥ プラスビルのシーズン 4 のフィナーレで、戦争中の母親のキム プラスと妻のオリビア プラスを結びつけました。

仕事の生産性を高める 8 つのシンプルなホーム オフィスのセットアップのアイデア

仕事の生産性を高める 8 つのシンプルなホーム オフィスのセットアップのアイデア

ホームオフィスのセットアップ術を極めよう!AppExert の開発者は、家族全員が一緒にいる場合でも、在宅勤務の技術を習得しています。祖父や曽祖父が共同家族で暮らしていた頃の記憶がよみがえりました。

2022 年、私たちのデジタル ライフはどこで終わり、「リアル ライフ」はどこから始まるのでしょうか?

20 年前のタイムトラベラーでさえ、日常生活におけるデジタルおよびインターネットベースのサービスの重要性に驚くことでしょう。MySpace、eBay、Napster などのプラットフォームは、高速化に焦点を合わせた世界がどのようなものになるかを示してくれました。

ニューロマーケティングの秘密科学

ニューロマーケティングの秘密科学

マーケティング担当者が人間の欲望を操作するために使用する、最先端の (気味が悪いと言う人もいます) メソッドを探ります。カートをいっぱいにして 3 桁の領収書を持って店を出る前に、ほんの数点の商品を買いに行ったことはありませんか? あなたは一人じゃない。

地理情報システムの日: GIS 開発者として学ぶべき最高の技術スタック

地理情報システムの日: GIS 開発者として学ぶべき最高の技術スタック

私たちが住んでいる世界を確実に理解するには、データが必要です。ただし、空間参照がない場合、このデータは地理的コンテキストがないと役に立たなくなる可能性があります。

Language