読者です 読者をやめる 読者になる 読者になる

隙あらば寝る

うぇぶのかいしゃではたらくえんじにあがかいています

リンクを作る時の target="_blank" の危険性

html で リンクを新しいタブ(やウィンドウ)で開かせたい場合、target="_blank" を指定するが、

この使い方には落とし穴があるらしい。

www.jitbit.com

リンクを開いた先の javascript から、開いたのページを操作できてしまうとのこと。

気になったので確認してみた。

悪用のパターン

f:id:yoru9zine:20170317225519p:plain

insecure.html が最初に開くページで、ここに target="_blank" なリンクがある。

このリンクを押すと new_window.html を新しいタブで開く。

この new_window.html に javascript が仕込まれており、元ページを操作されるという話。

具体的には window.opener.location="./evil.html" と実行すると、元タブは evil.html に遷移する。

実際試してみたのが ここ

リンクを開くとたしかに元タブで遷移が発生した。

なるほどこんな事ができたのか。。。

予防

予防するには target="_blank" なリンクに対して rel="noopener noreferrer" を設定すれば良いとのこと。

f:id:yoru9zine:20170317230021p:plain

実際ためしたのが ここ

問題の javascript は以下のエラーで停止した。(Chrome 56.0.2924.87 で確認)

Uncaught TypeError: Cannot set property 'location' of null
    at new_window.html:4

まとめ

自分の管理下にあるサイトであればリスクはかなり低いと思われる。

一方で外部へのリンクをtarget="_blank" で作成している場合は対策を行っておいたほうが良い。

リスクとしては参考URLで解説されているように、元サイトそっくりに作られたフィッシングサイトにパスワード等を入力してしまう恐れがあるというのが最も想像し易い。

また、管理下にあるリンク先だとしても、利用者が任意のコンテンツを置ける場合や乗っ取られる場合もあるので一律で対策するのが良さそうだ。

もくじでジャンプ

TV SideView のお知らせで「もくじでジャンプ」機能の終了予告が来ていた。

info.tvsideview.sony.net

番組の特定のコーナー等に直接飛べるので重宝していた。

とはいえ再生さえ初めてしまえばチャプタージャンプで十分なのでそんなには困らない。

ちょっと残念だけどしょうがない。

iOS の Video & TV Sideview 4.7 で課金プレイヤーが使えなくなった話

先に結論。

復元時に App Store に接続できません と言われて復元できない人は

iOS の設定から iTunes & App Store で一度サインアウト、その後もう一度サインインする。その後復元すればOK

nasne の番組を iPhone から見るために、iOS の Video & TV Sideview をインストールして使っている。

プレイヤーは有料なのでアプリ内課金していた。

最近 4.7 に上がったが、どうもそれ以来再生時に課金したプレイヤーが使えなくなっている。

当然こないだまでは再生できたいたわけで、どうせ復元すれば治るだろうと思って復元を押しても

App Store に接続できません

と言われて無限にエラー。

おやおやとアプリのレビューを見てみると案の定同じような状況で文句を言っている人がいる。

(レビューの場所に書いても相手からは返事もらえないから問い合わせしたほうがいいよと思いつつ。。。)

で、最終的には

info.tvsideview.sony.net

に解決方法が載っていた。

iOS の設定から iTunes & App Store で一度サインアウト、その後もう一度サインインして試すとOKだった。

これ困ってる人多いんじゃないのかなぁ、バージョンアップの案内とは別に、事象から辿れるようにアナウンス出したほうが親切だと思う。

とりあえず使えるようになったので良かった。

Google Cloud Spanner

cloudplatform.googleblog.com

最近発表されたGoogle Cloudの新サービスSpanner。

SQLが使えるデータベースで、どうもCAP定理を打ち破ったらしい。

CAP定理自体は昔からよく言われるもので、すごくざっくり言うとDBのクラスタ

一貫性©/可用性(A)/分断耐性(P)

どれかを犠牲にしないといけないという話。

CAP定理 - Wikipedia

で、カタログスペックで見るとSpannerはすべてを満たしているようだ。

詳細の説明は

https://reearch.google.com/pubs/pub45855.html

のpdfで解説されているようだが、どうもGoogle Cloudで作り込まれたネットワークを利用することで

分断に対するリスクを減らしているということだと理解した。

たしかに分断を経験することはあまりないし、SDN(死語?)で見事なネットワーク冗長化をしていればなおさらだろう。

ただ簡単に真似できるものではない。予算が許すのであればぜひ使いたいと思う。

実際使ってみればいろいろと不満もあるのかもしれないが、このカタログスペックはもはや別次元。

なんとなく感じていたが、インフラは積極的にクラウドに載せたほうがいいかもしれない。

gaierror

pythonコードでgaierrorというのが出て、どうもエラー詳細から見ると名前解決のエラーのようだった。

 

gaiってなんぞ?と調べたところ、どうも getaddrinfo の頭をとってgaiらしい。

 

わかれば納得だが、非省略だとダメだったのかな。。。長いからダメということかな。

TODO管理を実装するとしたら

TODO管理については様々なツールが既にある。

ただ、こういう自己管理系のツールは結局好みになるので、満足いくものというのはなかなか見つけにくい。

個人的には

あたりが理想なのでちょっと作ってみると仮定して考えてみた。

管理はそれほど難しくないが、一番難しそうなのは入力。

特に日付の入力が面倒。

たぶんnext mondayとかゆるい感じで入力できるのが良いと思うが、細かい時間の入力はやはり面倒になると思う。

コマンドラインから使うのを条件としているので、curses的なCUIで選択できるのが良いだろうか。

このあたりの発想は最近流行ってたwuzz

github.com

を見て、CUIの可能性がまだまだあるなと感じていたというのが大きい。

で、wuzzはどうやって実装しているんだろうかと見ていると

gocuiというライブラリを使っているようだった。

github.com

似たようなものにgo-termbox等が昔からあるが、gocuiはテキスト編集のコンポーネントもあって使いやすそうだった。

ただ、軽く使ってみた感じでは今は非ASCII文字の扱いが上手くできないようだ(時期バージョンでサポートするような宣言のあるissueは見かけた)

このあたりを使いこなして好みのUIが作れると面白いなと思う。

他にも、昨日紹介したようなshellのような発想もあるので、todo編集に特化したreplのようなものも面白いかもしれない。

この場合python-prompt-toolkitのようなライブラリを使うと良さそうだ。

github.com

と、まだ何もしていないがライブラリを眺めて色々妄想していた。

こういう時間もなかなか楽しい。

ergonomica

GitHub - ergonomica/ergonomica: A Bash alternative written in Python.

 

pythonで実装されたshell。

 

デモがすごい、最初の補完で度肝を抜かれるので是非リンク先の動画を見た方が良い。

 

こういう方向に進化したshellを使ってみたい。

 

tmuxとかの機能もshellに統合されてたりすると嬉しい。

 

shellはいつか手を出してみたいな。