#生存戦略 、それは

Rack のセキュリティフィックスと Timing Attack の話し

14:17 |

さきほど Rack にセキュリティフィックスバージョンが出たんだけど、セキュリティ的に何故に問題があるのかわからなった(Timing Attack をよく解ってなかった) のでメモ。

• https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07
• このコミットで直った。HMAC で生成するハッシュ値の比較チェックを == から別のメソッドで行うようになった。
• https://github.com/rack/rack/blob/master/lib/rack/utils.rb#L399-L408
• え、これ戻り値の bool は Ruby の String#== と同一じゃん、なにが問題なんだろう？
• 攻撃者が指定した digest により、== の比較速度が異なり、HMAC が推測可能になるのが問題
  • これが Timing Attack か！
  • Response Header で X-Runtime を出してると usec 単位で処理時間がばれる
• secure_compare だとバイト列の比較で最後まで舐めるため、処理速度にばらつきが無くなる

ﾅﾙﾎﾃﾞｨｳｽﾃﾞｽｿﾞ~。mrkn / miyagawa さんに教えて貰った。

なお Rails は

use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore

な別の middleware で処理をしてるため、Rack の影響は受けない、と。

GitHub Enterprise TechTalk に見る、各社の運用法

09:34 |

弊社もバリバリ GHE を使ってるので落ちると開発が回らなくなる(pull request できないのは、master に merge できないのとほぼ等価)ので、他社どうやってるのかーと大変気になってたのでしれて良かった。

間違ってたら教えてくだしぃ

• クックパッド
  • 開発者は GHE へ push, webhook でメインの git サーバに同期
  • GHE の git レポジトリは本番からは利用しない
  • GHE が死んだ場合はメインの git サーバを向けることで継続開発・デプロイ可能
• はてな社
  • 開発者は GHE に push したり場合により別のサーバに push したり
  • GHE から webhook でミラーリング
  • GHE / 別 git を開発者がうまく使いこなす必要がある。混乱するので git-hatena コマンドを用意してよしなにラップしてる
  • GHE のサーバは Active Standby 構成らしいけどどうやってるのか聞きそびれた！
• DeNA 社
  • 開発者は GHE へ push
  • GHE から各種 ghe- ツールを使いバックアップ
  • repos は巨大すぎるので ghe- ツールで無くて rsync
    • 某権限でｺﾞﾆｮｺﾞﾆｮ…仮想マシン上のｳﾌﾞﾝﾂですし…
  • 構成は Cold Standby 構成
• - VMWare の仮想冗長化はお値段が…
• GREE 社
  • 大場さんがんばって(´；ω；｀)

というわけで

• GHE が死んで pull request できなくなると死ぬ
  • DeNA でやってる Cold Standby 構成で
• 本番に deploy やレポジトリ参照できなくて死ぬ
  • 参照するのは GHE レポジトリで無く別のメインのレポジトリで

が良さそうだナーと思いました。へーしゃも DeNA 社的なアプローチとりたいなぁ。あと GHE も日々進化してるので、そのうちきっと低コストな手法で SPOF が排除される機能がつく…はず…といいなぁ…

あと感想で GHE 使うの苦行だけじゃ、って話しを何件か見たけど、実際 github.com の運用だけで問題ない会社なら

• github.com を使ったときのセキュリティリスクをとれる
• github.com が死んでてもなかない

なら、github.com を使うべきですよ。GHE に github.com で実装された機能が入ってくるのにも時差あるし、github .com を使わない理由は無いです。安易に GHE を使うと運用をしっかりしないと死ぬので。

github で git diff from..to を表示する

16:46 |

いつも忘れるのでメモ。compare だ！(なんで diff じゃないの…)

• https://github.com/:user/:repos/compare/from...to

で表示。

• https://github.com/your/repo/compare/from...to.diff

で text/plain な diff が表示される。.. じゃなくて ... 。

(thanks @sora_h, @kakutani)

Capybara の using_session でセッションを切り替えつつインテグレーションテストをする

18:50 |

ユーザAとユーザBが順番にアクセスしに来て云々という spec を書きたい、ので ググったら Capybara に using_session なんつー便利メソッドがあった！のでみなさん使うと良いです。

• http://rubydoc.info/github/jnicklas/capybara/master/Capybara/DSL#using_session-instance_method

ドキュメント素っ気ない…。便利なのに…。

以下は wiki のページ衝突の example。片方が更新したのに、それを知らずにページ更新しようとするとコンフリクト画面が出る、みたいな。

using_session(:bob) {
  login(bob)
  visit page_edit_path(target_page)
}
using_session(:tom) {
  login(tom)
  visit page_edit_path(target_page)
}
using_session(:bob) {
  fill_in 'page_content', with: "# bob's page"
  click_button 'Save'
  page.should have_selector 'h3', text: "bob's page"
}
using_session(:tom) {
  fill_in 'page_content', with: "# tom's page"
  click_button 'Save'
  page.should_not have_selector 'h3', text: "tom's page"
  page.should have_selector '#page_content', text: "# tom's page"

  page.should have_selector('#confrict')
...

Rails でアプリ内部から発行してる http をトレースする

16:17 |

• Ruby で HTTP の内容をトレースする - #生存戦略 、それは - subtech

の続き。デバッグ用にセットしたら便利だったのでメモ。

Gemfile

group :test, :development do
  gem 'webmock', require: false
end

しておいて

config/environments/development.rb

if ENV['WEBMOCK_ENABLE']
  require 'webmock'

  WebMock.allow_net_connect!
  WebMock.after_request do |request_signature, response|
    res = ["=== HTTP Request ===",  "#{request_signature}", "", response.status.join(' ')]
    res << response.headers.map {|key, val| "#{key}: #{val}" }.join("\n")
    unless response.body.empty?
      res << ""
      res << response.body
    end
    res << "=" * res.first.size
    Rails.logger.debug res.join("\n")
  end
end
```

しておいて

WEBMOCK_ENABLE=1 rails s

すると、http 叩いてるところが以下みたいに出て便利。

=== HTTP Request ===
GET http://example.com/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=0.3', 'User-Agent'=>'Ruby'}

302 Found
Location: http://www.iana.org/domains/example/
Server: BigIP
Connection: Keep-Alive
Content-Length: 0
====================
=== HTTP Request ===
GET http://www.iana.org/domains/example/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=0.3', 'User-Agent'=>'Ruby'}

200 OK
Date: Thu, 20 Dec 2012 07:16:22 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Thu, 06 Dec 2012 19:40:14 GMT
Content-Length: 606
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
....

git-new-workdir が便利

13:21 |

作業中、別のベクトルの作業するからブランチ切り替えじゃ無くてもういっこワーキングディレクトリを作って作業したい！って思った経験ありませんか？みなさん n 回ぐらいあるんじゃないでしょか。

そんなときいちいち clone して…などしなくても git-new-workdir コマンドを使えば一発！git-core の contrib に入ってます。

ln -s /usr/local/share/git-core/contrib/workdir/git-new-workdir ~/bin/ 

とか適当に symlink 等張って

git-new-workdir . ../foobar

するだけ！便利！べんり！もちろん .git/config 等の内容もちゃんと同じのがつかえます。あと cp するより速度がめちゃくちゃ速いので、大きいレポジトリで作業してるほど効果を実感できるます。(追記: .git 以下を symlink 張るから速いって得さんが書いてた)

[1]>_<X time git-new-workdir . /tmp/foobar
Checking out files: 100% (16546/16546), done.
git-new-workdir . /tmp/foobar  1.03s user 2.60s system 56% cpu 6.401 total
[1]>_<X rm -rf /tmp/foobar
[1]>_<X time cp -rpf . /tmp/foobar/
cp -i -rpf . /tmp/foobar/  2.12s user 35.67s system 31% cpu 2:00.27 total

git-new-workdir でググってもあんまり引っかからないのでエントリー化。なお同僚のレオ氏に教えて貰いました。どうりょうべんり。

なお、contrib が入ってないディストリの方々は以下から落として使うと良いと思います

• https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir