facebook

必ず押さえておくべき WordPressとFacebookの連携方法②


以前、WordPressで投稿した記事をFacebookのウォールに書き込む、WPBookというプラグインについてブログを書きましたが、気がついたらWordPressの管理画面にこんなアラートが出る事案が発生。
WordPress ダッシュボード

“Facebookのアプリ用アクセストークンの有効期限が切れてるよ”
“新しいアクセストークンを設定しなさいよ”
“じゃないと、WPBookからFacebookにアクセスさせないよ”

と怒られている模様。

Facebookのアクセストークンについて調べてみたら、
こちらのページにあるように、3種類のアクセストークンがある。
で、Facebookのディベロッパーサイトで、アクセストークンを確認できるページがあるので、
アクセスしてみる。
トークンツール

見てみると、”User Token”と”App Token”の2つがある。
WPBookをインストールした際にWordPressの管理画面では、”App Token”の値を設定していたので、”App Token”の有効期限が切れたっぽい。
でも、調べてみると”App Token”は、有効期限が無いらしいので、Facebook側が仕様変更したのか、あるいは、Facebookのoffline_accessパーミッションが廃止された影響なのか、良く解らない。

とは言うものの、アラートをなんとかしなくちゃなので、以下の手順で改めてアクセストークンを取得してみる。

■Facebookのディベロッパーサイトにて
(1)アプリページにアクセス ※”アプリのシークレットキー”の値を念のためメモっとく
アプリ画面
(2)「設定を編集」リンクを押下
(3)基本設定ページで、「再設定」リンクを押下
基本設定
(4)ダイアログが出るので、「再設定」ボタンを押下
(5)アプリページに戻って、”アプリのシークレットキー”の値が変わっていることを確認
(6)https://graph.facebook.com/oauth/access_token?client_id=[アプリID]&client_secret=[アプリのシークレットキー]&grant_type=client_credentials にアクセス
(7)アクセストークンが表示される(アプリID|アクセストークン)ので、メモっとく
access token

■WordPressの管理画面にて
(8)管理画面メニュー「設定」から”WPBook”を選択
(9)Required Settings Facebook App Secretに、(7)でメモったアクセストークンの値を入力し、Saveボタンで保存

以上の操作で、WordPressの管理画面のアラートが回避できました。
回避はできたんだけど、ググってもWPBookのおんなじエラーで引っ掛かったページは見つからないし、なんかスッキリしない。

クールポコ

ワンクリックで犯罪予告が書き込まれて誤認逮捕!?CSRF脆弱性は怖いんです。


つい先日話題になった大学生の誤認逮捕の件。

なりすまし事件、4人は誤認逮捕か 4都府県警が謝罪へ
遠隔操作事件・真犯人と称する者からのメール全文

結局このお方は犯罪予告を書き込んだわけではなく、
ただ、掲示板のリンクをクリックしただけです(震え声)

なんでそうなっちゃったかと言うと、

(1)まず、某市Webサイトの問い合わせフォームあたり(?)にCSRF脆弱性があり、
(2)犯人が、掲示板に罠を仕掛けたURLを貼り、
(3)大学生が、その掲示板のURLをクリックし、
(4)そのURLに含まれたJavascriptがブラウザ上で実行され、※実行するブラウザは大学生のPC
(5)ブラウザ、犯人が作ったページを表示し、
(6)某市Webサイトで犯行予告が書き込まれる。※書き込んだIPアドレスは大学生のPC
(7)IPアドレスを元に、大学生が逮捕される。

たぶん、こんな感じだと思われます

CSRF(クロスサイトリクエストフォージェリ)は、Webアプリケーションの脆弱性の一種。
WebアプリにCSRF脆弱性があると、攻撃者によって誘導されたユーザーが、意図しない機能を実行させられてしまうことが起きる。

上のケースに当てはめると、
”某市Webサイト”にCSRF脆弱性があって、
”犯人”が掲示板に貼ったURLをクリックした”大学生”が、
”意図しない犯罪予告の書き込み”を実行させられた、ってことになる。

CSRFは「機能そのもの」が攻撃対象になるので、サイトの機能によっては、
・ECサイトで買い物をさせられる
・会員サイトで退会させられたり、パスワードを変更させられる

など、怖いことが盛りだくさんです。

Webアプリ側の対策は、ページ間の遷移が不正でないことを判定するため、以下のような実装が必要。
全機能(すべての画面)でCSRF対策が必須なわけではなく、要件としてどの機能を対象にするかを決めた方が良いです。

(1)ワンタイム/固定トークンを使用する
→セッションIDとトークンをセットで使用する。
→ただし、セッションIDの値をトークンとして使うのはダメ。
→リクエストはGETではなくPOSTで。

(2)CAPTCHAを使用する ※ワンタイムトークンとして実装する
→これもセッションIDとセットで。

(3)パスワードの再入力を求める

ユーザー側の対策は…
「クリックしない」くらいしかないと思われ。。
むやみやたらにリンクを踏まないっつーことですね。

mail

Webサービスを運用する際に、設定すべき迷惑メール対策あれこれ。


Webサービスからメールを送信する際、スパム扱いにならないようにしましょうね、の話。
まずどういった迷惑メール判定の仕組みがあるかについて。

(1)SPF(Sender Policy Framework) / Sender ID

どちらもIPアドレスベースの送信ドメイン認証。
受信先のメールサーバーが、「送信元のIP」と「Fromドメイン」をDNSサーバーに問い合わせて一致するかを判定する仕組み。

SPF SenderID

なので、メール送信側はSPFをDNSのTXTレコードに登録しておく必要アリ。
書き方はこんな感じで。

carp.com. IN TXT “v=spf1 +ip4:192.168.100.0/24 +ip4:10.0.0.0/24 ~all”

なお、SPFレコードが引けているかを確認する際は、以下のコマンドで可能。

$dig carp.com txt

これで、carp.comからのメールは、このネットワーク以外からは送りませんよ、となる。
Sender IDとSPFの基本的な仕組みはおんなじ。
ケータイキャリアのdocomo,au,softbankでも、この送信ドメイン認証を導入してます。

(2)DKIM / DomainKeys

これも送信ドメイン認証。
まず、送信元のメールサーバーが、暗号化した電子署名をメールヘッダに付加する。
身分証明書みたいなもん。

受信先のメールサーバーは、署名にある送信元ドメインのDNSサーバーに問い合わせて、
公開鍵を取得する。

なので、送信メールサーバー(SMTP)にDKIMやDomainKeysのロジックを実装する必要アリ。
なお、メール送信側/受信側ともに、サーバー負荷が増大するので、要注意。

(3)OP25B

これはプロバイダー(ISP)側の迷惑メール対策。
基本的に一般ユーザーがインターネットを使う場合は、プロバイダーと契約が必要なわけで、
プロバイダーの送信メールサーバー以外からメールを送ろうとした場合に、送信不可にする仕組み。

プロバイダー以外のメールサーバー向けをすべてブロックするパターンと、
携帯事業者のメールサーバー向けのみをブロックするパターン2つある。
迷惑メールが携帯電話宛てが多いから、携帯向けに絞っても効果が出るんだとか。
ちなみに、主要プロバイダーさんは、OP25Bに対応してます。

Webサービスでメールをユーザーなり、お客さん宛てに送付するサービスは多いと思いますんで、
迷惑メール扱いにならないように対策をー

全角スペースを半角スペースに変換する際に気をつけなきゃいけないこと(PHP&EUC-JPの場合)


PHP且つ文字コードがEUC-JPで、全角スペースを半角スペースに置き換える際のメモ。

検索サイトやWebサイトなどで、2つ以上の単語がスペースで繋いで入力された場合、
単語間の全角スペースを半角スペースに置換してるサイトが結構あったりする。
yahoo然り、gooも然り。

昔はUNIXの日本語環境だと、EUC-JPが標準だったみたいけど、LinuxではUTF-8が一般的になっている。

で、前置きが長くなりましたが、
(1)ユーザーが、テキストエリアに”特定の文字”を入力する
(2)システムが、全角スペースを検出して、半角スペースに置換する処理をする
(3)1.で全角スペースは入力されてないのに、全角スペースと判定されちゃう
というケースがあるので気をつけようぜ、という話。

1.の特定の文字というのは、前の文字のEUC文字コードが”A1”で終わり、後の文字のコードが”A1”で始まる組み合わせ。※EUC文字コードはコチラ

2.が、preg_replace(“/ +/”,” “,$carp);

という処理になっていて、例えば、$carp変数に”ファーストサーバ”という文字列が入ってくると、
“フ”+”璽好肇機璽”という2つの単語に分割されてしまう。

理由としては、”ァ”の文字コード”a5a1″と、”ー”の文字コード”a1bc”の組み合わせが、”a1a1″(全角スペース)と認識されてしまい、結果として、”フ”+”璽好肇機璽”になっちゃいます。

ググってみると、これでハマった人も何人かいるみたいで、preg_replace関数のバグだべ!っていう意見も出てたけども、
「文字コードがEUCで、文字列の全角スペースを半角スペースに置換する際は、preg_replace関数は使わないようにする。」が正解みたい。

EUC-JPで全角スペース→半角スペースの変換を行う場合は、
mb_convert_kana($carp,”s”,”EUC-JP”);
とすればおkです。※”s”は全角スペースを半角スペースに変換するオプション。

FireMobileSimulator

Google Chrome(PC)でスマートフォンサイトをチェックできる便利なエクステンション


Chromeのエクステンション”FireMobileSimulator”をインストールして、User-agentを偽造すれば、
サイトによっては(※注1)スマートフォンサイトを閲覧可能になるよ、というお話。

インストール方法はちょー簡単。
Chromeウェブストアにアクセスして、画面右上の”CHROMEに追加”ボタンをクリックするだけ。

FireMobileSimulator

インストールすると、Chromeのアドレスバーの右側にアイコンが出てくるので、そのアイコンをクリックしてリストから端末を選択。

FireMobileSimulator

チェックしたいページを表示させれば、以下のようにスマートフォンサイトが見れます。

FireMobileSimulator

終了するときは、再度アイコンをクリックして、”端末選択解除”をクリックすればOK。

その他”オプション設定”で端末毎に解像度などの設定ができて、”最新端末リストから端末を追加”で端末の追加が可能。

(※注1)
yahooやGoogleなんかは↓のように見れます。htmlやcss、cookieなんかは見れるけど、ちゃんとしたデザインの確認には使えなそう。

FireMobileSimulator

GREEやMobageなどのブラウザゲームは、OAuth認証で偽造を防いでいるっぽい。
それでもググるとあの手この手でやり方があるみたいだけど、利用は自己責任で。

スラィリー

Oracle文字列のサイズを取得する方法


Oracle(10g)で、文字数(バイト数)毎のレコード数を取得するクエリに関するメモ。

前提:会員ユーザは、会員登録時に会員ID(必須:半角6文字~15文字までの半角英数)を
登録する仕組みになっている。

やりたいこと:会員IDが、どの文字数でどれくらい登録されているのか、を文字数の昇順で出力したい。※結果によっては、6~15文字の仕様変更を検討したい、とか。

※テーブル名:carp_fanclub
※会員IDカラム名:kaiin_id

SELECT
  length(kaiin_id) as 文字数,
  count(*) as レコード数
FROM
  carp_fanclub
GROUP BY
  length(kaiin_id)
ORDER BY
  length(kaiin_id) asc

※文字数ではなく、バイト数毎に出力したい場合は、”length“を”lengthb“に変えればおk。

がんばれ広島カープ!
目指せクライマックス!!

友だち自動追加

ちょっとコワい??LINEに出てくる知り合いかも?は、本当に知り合いなのか。


結論としては、知り合いじゃない人が出てくる可能性がある仕組み。
知り合いかも?に出てくるケースは、3つほどあるみたいで、

(1)相手が自分の電話番号をケータイの電話帳に登録していて、友だちに追加した場合

→例えば、昔ケータイ持ちたてで浮かれてた頃に電話番号を交換して、自分のケータイの電話帳にはその人の番号が残っていなくても、相手方のケータイに残っていれば、普通に起こりえる話。

なので、知り合いっちゃ知り合いになるのか。う~ん、、、ヘンな感じ。

あと、ケータイ番号は使い回しされるものなので、過去に自分の電話番号を保有してた人の知り合いも普通に出てくる。この現象を防ぎたい!って場合は、アプリを起動して、
その他→設定→友だち自動追加 で、「友だちへの追加を許可」のチェックを外せばOK。

あとは逆に、自分のケータイの電話帳に登録している電話番号が、知り合いじゃない人の保有に変わっている場合。この場合も、その他→設定→友だち自動追加 で、「友だち自動追加」をオフにすればOK。

友だち自動追加

(2)「ID検索」で自分のIDが検索されて、友だちに追加された場合

→まー、意図的に出会い系の掲示板とかでIDを晒してなければ、検索されなそうだけど。
イヤヤという場合は、その他→設定→プライバシー管理 で、「IDの検索を許可」のチェックを外せばOK。

プライバシー管理

(3)同じグループに参加している人で、友だちになっていない場合

→知り合いの知り合いが出てくるイメージ。
これがイヤヤの場合は、グループを退会しちゃえば良し。

結局、このアプリは電話帳にアクセスをして、電話番号をキーにしていろいろやってるアプリなので、
電話帳に登録していたり、されていると上のようなことがありますよ、というお話。

ユーザーがダウンロードする際に、連絡先データにアクセスする許可を取ってるとはいえ、
デフォルト設定で「友だちへの追加を許可」「友だち自動追加」はオフにしてくれた方が良いんじゃない?と思う今日この頃。

permission

security

セキュリティホールをなくそう!!Webアプリのクロスサイトスクリプティング対策はしっかりと。


SQLインジェクションよりかは、話題になることが少ないクロスサイトスクリプティング。通称XSS。
とはいえ、狙われて被害が発生すると、大きな損害になることもあるので、対策はしっかりしましょうという話。

■そもそも何が起こるか?

cookieの内容がパクられちゃう。
→セッションIDやら、ログインIDやら、パスワードなど、cookieに保存されているものが盗まれる。

ページの内容を書き換えられちゃう。
→偽のログイン画面を作られてしまい、結果、ログインIDやパスワードなど、個人情報が盗まれる。
※ドメインは正常(以下の例だと、ohsexybaby.com)だから、気づき難い。

■具体例

(1)ユーザーが、不審なメールなどから、悪意のあるサイトを閲覧する
(2)悪意のあるスクリプトが、そのサイトから、ohsexybaby.comに転送される
※この時点では効果は発揮しない
(3)ohsexybaby.comを介して、ユーザーのブラウザに送られる
※ここで悪意のあるスクリプトの効果が発揮される
(4)cookieが盗まれたり、ページの内容を書き換えられたりする

■対処の仕方

サニタイジングをし、スクリプトを無効にする。
つまり、入力データから危険な文字を検出して、置換・除去をする。
危険な文字とは具体的に、
&とか、<とか、>とか、”とか、’とか。

アプリケーションの規模によりけりですが、そこまで対応コストがかかるわけではないので、
きっちり対策をしておきましょう。

GoogleMapとiOS6のMap

続・Google Mapの有料化とその後。そしてAppleのiOS6の新しい地図がスゴそうな件。


AppleのWWDCにて、iOS6からGoogle Mapではなく、
Apple独自の新地図アプリが搭載されることが発表されました。

既にiOS6のβ版が公開されていて、そのβ版を入れて地図アプリを見ると、
↓な感じですっきりスカスカな地図になっている。(まーあくまで開発用β版ですが。)
GoogleMapとiOS6のMap

Appleのこの発表を境に、また動きが活発になってきて、

・AppleがiOS6から自前の地図アプリの搭載を発表

・Googleから、iOS用の新しいGoogle Mapがリリースされる噂が流れる

・Googleが、Google Maps APIの大幅値下げを発表 ←イマココ

※25,000/日超過時の課金が、1,000アクセス4ドルから、なんと50セントに大幅値下げ

って感じでしょうか。

そもそも、iOS6にApple独自の新地図アプリが搭載されるとどうなるかというと、
地図機能を呼び出しているiPhoneアプリが、Google Mapから新地図アプリに
強制的に切り替わっちゃいます。

具体的には、開発時のプロジェクトのフレームワークに、MapKit.frameworkが追加してあって、
MKMapViewクラスを使って地図を表示しているアプリです。

一方で、ネイティブアプリではなく、Webアプリ(Safari)でGoogle Mapを表示する場合は、
JavaScriptで直接Google Maps APIを呼び出していると思うので、iOS6のβ版でもそのままGoogle Mapが出ます。

正式なiOS6はどんな地図アプリになるのか、Google Mapはどう進化するのか、注目でございます。

Apple

Google Mapの有料化とその後。そしてAppleのiOS6の新しい地図がスゴそうな件。


2011年に発表され、2012年から一部有料になったGoogle Map。
一部というのは、Google Maps APIへのアクセスが、25,000/日を超える場合、
1,000アクセスにつき、4ドルが課金されるというもの。

それ以降、地図関連の話題が頻繁に出るようになってきた。

・Google Maps API有料化

・SNSサービスのFoursquareが、Google Mapから、フリーのOpenStreetMapMapBoxをベースにした、新しい地図サービスに切り替え。

・AppleもGoogle Mapに代わる、新しい地図サービスを出すんじゃないかと噂される

・実際、Google Mapを使わない、iPhotoアプリをリリース

・Googleが、3D版Google Earth、Google Mapのスマホ向けオフライン機能を発表
※日本のGoogle Mapはゼンリンの地図データを使っているので、オフライン機能は対象外らしい

・AppleがiOS6から導入するっぽい、新しいMapアプリの画像が流出 ←イマココ

で、新しいMapアプリの画像を見ると、3D化されててスゴイ。

Apple

スマートフォンやタブレットとすこぶる相性が良くて、外せない重要な機能になっている地図情報。
やっぱGoogle Mapが無双なのか、Appleの新しい地図サービスが台頭してくるのか、注目でございます。