脆弱性情報が公開されてから48時間足らずの間に悪用コードが投稿され、脆弱性のあるサイトを探して攻撃を試す動きはインターネット全体に広がった。ハッキングされたWebサイトの数は6万6000以上にのぼり、現在も増え続けている。 1月下旬のパッチで修正された、WordPressの深刻な脆弱性を突く攻撃が、わずか2週間足らずの間に激増し、多数のWebサイトが改ざんなどの被害に遭っていることが分かった。この問題を発見したセキュリティ企業のSucuriが2月6日のブログで伝えた。 WordPressは1月26日に公開した更新版の4.7.2で複数の脆弱性を修正した。このうち特に深刻なWordPress REST APIの脆弱性については、2月1日まで待ってから情報を公開していた。この問題を悪用された場合、認証を受けないユーザーがWordPressサイトのコンテンツやページを改ざんできてしまう可能性が指摘
エグゼクティブサマリ WordPress 4.7と4.7.1のREST APIに、認証を回避してコンテンツを書き換えられる脆弱性が存在する。攻撃は極めて容易で、その影響は任意コンテンツの書き換えであるため、重大な結果を及ぼす。対策はWordPressの最新版にバージョンアップすることである。 本稿では、脆弱性混入の原因について報告する。 はじめに WordPress本体に久しぶりに重大な脆弱性が見つかったと発表されました。 こんな風に書くと、WordPressの脆弱性なんてしょっちゅう見つかっているという意見もありそうですが、能動的かつ認証なしに、侵入できる脆弱性はここ数年出ていないように思います。そういうクラスのものが久しぶりに見つかったということですね。 WordPress、更新版で深刻な脆弱性を修正 安全確保のため情報公開を先送り Make WordPress Core Conten
プラグインを作成していたのでメモ。 WordPressをインストールしたディレクトリ直下にあるwp-config.php 内の定数「WP_DEBUG」をtrueにします。 define('WP_DEBUG', true); // デバッグモードを有効化 // ログファイルに保存する場合は、以下を書き足します。 if ( WP_DEBUG ) { // debug.log ファイルに記録 define( 'WP_DEBUG_LOG', true ); // ブラウザ上に表示しない define( 'WP_DEBUG_DISPLAY', false ); // ブラウザ上に表示しない @ini_set( 'display_errors',0 ); } [19-May-2014 05:25:00 UTC] PHP Notice: load_plugin_textdomain was called
WordPress 4.3 will be rewritten in Node.js by · April 1, 2015 Warning: This Article was posted on April 1, 2015, So its a April fool prank. One of the leading developers of the core WordPress team Ryan Boren told “A significant part of WordPress version 4.3 the popular CMS functionality will be rewritten in Node.js, while maintaining backward compatibility with previous versions.” WordPress and No
ステータスとは そもそもステータスですが、記事がどういう状態で保存されているのか、ということを表していると理解すれば大丈夫です。 誰にでも見れる(公開)なのか、まだ見れないように保存している(下書き)なのか、という感じです。 WordPressの管理画面上で目にするステータスの種類は、下記のものがあります。 公開(publish) 予約投稿(future) 下書き(draft) 保留(pending/レビュー待ち) 非公開(private) また、管理画面上では目にしないけれどもWordPressがちゃんと動くために裏で使われている、下記のステータスもあります。 auto-draft(自動下書き) inherit(継承) trash(ゴミ箱) 日本語のちゃんとした名前を知らないので、言葉の順序が逆になっています。それでは、下記で、全てのステータスの状態を説明していみたいと思います。
WordPress には xmlrpc.php というファイルがあります。これは投稿設定でXML-RPCによる投稿を許可する場合に有効にするようですがが、私は利用してないためOffの状態で使っています。 ところが、このファイルへ海外からPOSTでアクセスしてくる奴が結構いて、一体何が目的だろうかと思っていました。Webログには、以下のようなアクセスログがたくさん残っています。 178.32.233.175 - - [01/Dec/2012:04:36:57 +0900] "POST /notes/xmlrpc.php HTTP/1.0" 200 523 今日、ようやく、xmlrpc.php へアクセスされる理由が分かりました。というより、推測出来ました。 iTunes のAppStore に iPhone/iPad用アプリ WordPress というものがあるのを発見。これは、iPhone
SPDY、流行ってますよね。 魔少年?それはビーディー。 ワンダー?それはスティービー。 次世代の香りがするシャレオツプロトコル?それはスピーディー。 というわけで、このブログをSPDY対応にしてみました。 このブログは、Nginxの2重構成となっていて、片方がリバースプロクシ、もう片方がWordPressのPHP実行環境とFastCGIでつながる用。 SPDYパッチを当てたNginxをビルドする NginxでSPDYを有効にする場合、OpenSSL 1.0.1以降が必要とのことですが、システムにそれをインストールする必要はないようです。 Debianなので、aptitudeでもろもろ入れています。 # ビルドに必要なものを入れる sudo aptitude install build-essential libpcre3-dev zlib1g-dev # Nginxのtar ball取っ
全然パフォーマンスチューニングの経験や能力が無いけれど、とにかく面白そうだしスゴいヒトたちのチューニング方法を知るのは勉強になりそうだ、と思ったので、参加してきました。 いろいろチューニングしてパフォーマンスを競うバトルイベント開催!「Tuningathon」 #tuningathon on Zusaar 出されたお題は「Amazon EC2のインスタンス上で動くwordpressへのコメント書き込みパフォーマンスを向上させる」というもの。wordpress自体に手を加えるのはNG。 ということで自分が手を出せそうなのはApache, MySQLのあたりだと思ってhttpd.confやmy.cnfをちょいちょい設定値いじってみたりしたものの、全然早くならない… 途方に暮れていたところAPCってのを入れると一気に早くなる、ということをきいて、それをやってみました。それ以外にはほとんど何もでき
第6回 GAE上でWordPressを動かす 萩原 巧 リトルソフト株式会社 中越 智哉 株式会社ナレッジエックス 2010/6/3 今回は趣向を変えて、PHPで書かれていて広く普及しているブログ作成アプリケーション「WordPress」をGAE上で動かしてみます(編集部) 連載6回目にあたる今回は、今までとは少し趣向を変えて、実際に広く使われているPHPのオープンソースソフトウェアがGAE上で動作するかについての検証を行い、動作の実現性や問題点について言及するとともに、画面表示やデータベースアクセスを含めた動作について検証を行っていく過程を通して、PHPのアプリケーションをGAE上で動作させるために必要となるテクニックなどを紹介していきます。 GAEにインストールするアプリケーションについて GAE上にて動作検証を行うアプリケーションとして、星の数ほど(大げさですが...)存在するPHP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く