問題タブ [magic-quotes]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
php - 一重引用符にスラッシュを追加するPHPfile()
5.3.3を実行しているPHPインストールがあり、以下のコードを使用すると、次のようになります。
私の一重引用符はすべてエスケープされます。なぜこれが起こっているのでしょうか。マジッククォートはサーバーで有効になっていますが(何らかの理由で、それは私の制御不能です)、マジッククォートはGET POST COOKIEとREQUESTにのみ適用されると思いましたか?最新のPHPでここに欠けているものが他にありますか?
何か案は?
php - php特殊文字の問題
スクリプトの特殊文字に問題があります。
これは私がこれまでに持っているものです:
$data
'のような特別な文字が含まれている場合'
、必要な文字列のチャンクを取得する代わりに、最初の部分のみを取得します。より詳細な例:
スクリプトは、Chrisの後に'を読み取り、異なる値を持ちます'
。$curlstrip[5]
希望は十分に明確です。
LE。この例に従う:
しかし
これは、'が次のように読み取られているためです。
どうも、
クリスティアン。
php - PHP バージョン 5.2.14 または同等の PHP バージョン 6 で get_magic_quotes_gpc を使用する
当サイトは PHP バージョン 5.2.14 を使用しています
最近、私たちのホストはおそらく魔法の引用符の定義を変更し、提案された解決策を思いつきました[コードベロー]
- このソリューションは PHP バージョン 5.2.14 で問題ありませんか?
- PHP バージョン 6 にアップグレードする場合、何を変更すればよいですか?
php - SQLで引用符をエスケープする
php.netによると 、非推奨になっているため、 mysql_real_escape_string()を使用し、魔法の引用符をオフにする必要があります。
それで、それをオフにしてmysql_real_escape_string()を使用しましたが、次のコードのように使用するだけで十分ですか?
データベース内のデータを確認すると、$ valueの場合と同じように見えますが、そう"It's Time"
ではありません"It\'s Time"
。これは正常ですか?これは引用符の前にスラッシュを追加するべきではありませんか?
php - mysql_queryからPDOに切り替える質問
mysql_query()
セキュリティ上の利点を利用するために、従来のパラメータ化されたクエリからPDOに切り替えています。いくつか質問があります。まず、magic_quotesに関して何かする必要がありますか?このWebアプリは、さまざまな構成のシステムにインストールされ、(残念ながら)オンになっているものとオフになっているものがあります。以前は、データの入力がオフになるまでifステートメント全体を実行していましたaddslashes()
...次のようなPDOクエリで実行する必要があることは次のとおりです。
また、最終的にデータベースハンドラーを閉じる必要はありますか?そうしないことの不利益は何ですか?PDOは、さまざまなサーバー設定にインストールされるCMSに適したオプションですか?PDOは、ほとんどのサーバーで有効になる場所で十分に普及していますか?
前もって感謝します!
php - MySQLPHPMyAdminLocalhostがMagicQuotesを受け入れます
PHPファイルからMySQLデータベースにアポストロフィで投稿されたデータを受け入れるためにUbuntuのローカルホストに小さな問題があります。
例:
私のローカルホストデータベースでは受け入れられず、それに付随するものも受け入れられません。
例:
アポストロフィが投稿されていない限り、ローカルホストデータベースとそれに付随する他のすべてのものに受け入れられます。
データベースに投稿されたデータでアポストロフィを受け入れるオンラインサーバーのようにローカルマシンを動作させるにはどうすればよいですか?これにより、開発中にコードが機能することがより確実になります。
mysql_real_escape_string()を使用せずにデータを受け入れるサーバーのようにローカルホストを作成したいと思います。
php - Special characters problem with database
I am trying to add special characters into database with JavaScript using encodeURIComponent
but it works in localhost and in server adding '
an extra /
is also added infront of '
.
How to prevent this?
This is what I have so far:
question_text
is the field ID.
admin
is my controller and then to model. If I enter special character like +'&
, all these characters are entered in local database correctly. But at server side the characters like '
entered but an extra /
is appended infront of '
.
php - PHP マジック クォートの質問
これまでに魔法の引用符がオンになっている環境でプログラミングしたことはありません。今、私はそれがあるプロジェクトに取り組んでいます。これは、ユーザーが受け入れたデータの状況を設定する方法です。
そのフィルタリングでは、マジック クォートが有効になっている場合でも、SQL インジェクション攻撃を受けやすいのでしょうか?
私は本当にクエリを壊すあらゆる種類のSQLインジェクションについてのみ心配しています...他のホワイトリスト、 htmlspecialchar() -ingなどは、他の領域のために用意されています。
いくつかの同様の SO の質問を見ると、代わりに魔法の引用符をチェックし、有効になっている場合はデータに対して「stripslashes」を実行し、常にエスケープ機能を実行することをお勧めしているようです。ただし、サイト内の既存のコードはすべてオンになっていると想定しているため、この方法で行うのは少し心配です。
ありがとう!
php - マジック クォートが有効な場合の SQL インジェクション
重複の可能性:
PHP では単一引用符は自動的にエスケープされますか? では、クリーニングの必要性は何ですか?
PHP マジック クォートにもかかわらず SQL インジェクションが成功する
今日、引用符の自動エスケープについて質問し、魔法の引用符について学びました。スレッドは、Are single quotes escaped automatically in PHP? にあります。では、クリーニングの必要性は何ですか?.
魔法の引用符だけでは不十分であり、準備されたクエリを使用するだけでなく、常にユーザー入力を検証してクリーンアップする必要があるというコンセンサスに達しました。
ただし、これはこの質問につながります.マジッククォートが有効なサーバーでは、どのような種類のSQLインジェクションがマジッククォートによって課されるセキュリティ対策をバイパスしますか? 魔法の引用符が安全でないのはなぜですか?
魔法の引用符が安全ではないことを私に納得させるために、これらの手段を回避する注射の実際の例を見たいと思います. 次のコードを使用して、ローカル サーバーにテスト セットアップを作成しました。
query() は、クエリを実行するために必要な通常のコードです。掃除は一切ありません。ただし、マジック クォートは有効です。
このセットアップで魔法の引用符をバイパスする注射の例はありますか?
乾杯、
エリック
php - PHP 5.3 はフォーム文字列から $_GET/$_POST を自動的にエスケープしますか?
私のサーバー管理者は最近 PHP 5.3 にアップグレードしましたが、奇妙な「バグ」(または、PHP 関係者が持っている機能) が発生しています。mysql_real_escape_string
明らかな安全上の理由から、文字列形式のデータのほとんどを使用していましたが、このエスケープは PHP によって既に行われているようです。
たとえばescape 'this test'
、を入力すると、これが出力されますescape \'this test\'
。POST
の代わりに使用する場合も同様ですGET
。
これは 5.3 のアップグレードに直接関連しているのでしょうか、それとも管理者が php.ini ファイルで自動切り替えをトリガーしたのでしょうか?
また、そのままにしておく必要があります (実際にすべての get および post 変数を正しくキャッチする優れた失敗防止メカニズムである場合)、またはそれを無効にする必要があります (可能であれば!) に戻る必要がありmysql_real_escape_string
ますか? 私の直感では、アプローチ 2 が最適ですが、アプローチ 1 はやや自動化されています。:)
編集:実際には、無効にする必要があります。フォーム データを収集し、何か問題があった場合 (つまり、フィールドが不足している場合) にそれをクライアント フォームに再送信することがあります。