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

はちゅにっき

こっちのブログはまったり更新

Shibuya.pm #14 にいってきました

今回のテーマは「IPAJPAは違う団体です」ということで、IPAJPA の両者が参加。
ということで、いつも通りてきとうなまとめ。

Perl 6 Language Update (dankogai さん)

  • 大まかには Perl6 も Perl5 もあんまり変わらないよ
    • 構文とかだいぶ違うようにみえるけど。。。
  • "Rakudo Star" がリリースされたけど、今はまだだいぶ遅い
    • 単純なスクリプトでも 5 と 6 では大きな差がある
    • それでも昔よりはだいぶ早くなった
  • sub の中に sub (Private Function) がかけるようになった。
sub fizzbuzz {
    sub fizz { };
    sub baz { };
}
  • try - catch が使えるようになる
    • まぁ、前から eval { }; if ($@) { } があったけどね
    • "try" の中に "CATCH" があるんだけど
      • どうしてこうなった
      • 変数のスコープ考えるとこっちのが便利じゃない?(会場内の Twitter から)
try {
    die;

    CATCH {
        say $@;
    }
}
  • そのた Perl6 の機能などのご紹介
    • 無限リスト
    • スマートマッチ
    • 後付ではない Object 指向
      • Moose で見慣れた記法
      • アロー(->)じゃなくてドット(.)
    • 正規表現の強化

ぼくのかんがえたさいきょうのYAPC::Asia (941 さん)

  • チケットかってね!

JPA活動報告 (lestrrat さん)

  • 今年も YAPC の運営やります
  • 地道にいろいろ活動してます
  • 地方 Mongers との交流はこれからも続けていきたい
  • Tシャツかってね!

memcached injection (佐名木 さん)

  • 最近某 SNS の memcached に障害が発生して話題になった
    • 今回はその件とは別
  • memcached は非常に簡単なテキストベースのプロトコル
    • 基本的には、Key と Value をテキストで送信して Store しているだけ
  • キー名のエスケープは memcache 側ではやっていない
    • Server / Client 側でサニタイズ処理をしてあげる必要がある
  • 各言語のライブラリによって、サニタイズ処理をしている場合と、していない場合がある
    • 処理していないライブラリを使う場合は、必ず自前で処理してね
    • Perl の Cache::Memcached はサニタイズしてないよ!
  • とはいえ、キーの値がユーザが指定した任意の値になるようなアプリは少ないはず
  • キーに対する Injection といえば SQL Injection
    • Colum に Injection できるというものが過去にあった。が非常に稀なケース
SELECT * FROM table WHERE column = 'hoge';
--                 ↑ ここが、ユーザが任意で指定できちゃうようなアプリ
  • memcached を使った攻撃方法があるって書いたら中国から大きな反響があった
    • どうやら攻撃が好きみたい
    • 攻撃されないようにね!

memcached の運用監視ノウハウ (kazeburo さん)

  • mixi で memcached 周りの障害が発生したことを Twitter で報告した
    • 大きな反響があり、多くの方に原因究明をしていただいた
    • それはそれでいいことだと思った
  • 障害から分かったことは memcached を安定稼動させることの重要性
  • 安定稼動とは PDCA サイクルである
  • 監視とは継続的なテストである
    • 継続的にテストするためには
      • 自動化しようね
      • 可視化しようね
  • どうやって監視していく?
    • 直近に実行したコマンドの終了ステータスを監視する
$ COMMAND
$ echo $?
0  <- COMMAND の終了ステータス
    • cronlog 使うと非0の場合のみに STDOUT / STDERR を出力してくれるので便利
      • cronlog は github の kazuho さんのとこで!
    • netcat (nc コマンド) も便利だよ
    • crontab に仕掛けるコマンドを以下のようにする
cronlog -- nc -w 1 -z localhost 11211 # nc の終了ステータスが 0 以外のときにメールがくる
    • コマンドに対する応答が返ってくるかを監視する
      • Nagios の Plugin 化してしまう
    • status を使ってコネクション数を監視する
    • daemontools とか使ってると障害を検出できないかもしれないよね
      • supervisor によって再起動されるため、監視と監視の間に障害が発生すると補足できない
      • uptime を使ってみてはどうか

身につけておきたい、今そこにあるシステムの救命措置 (IPA 園田 さん)

  • 脆弱性の報告は順調に増えている (良いことなのか、悪いことなのか)
    • DNS特需とかあって、急激なグラフの部分もあるけどね
  • 90日以上の長期化案件がけっこうある
    • 1年放置とかザラ
    • 1000日以上脆弱性が放置されているパターンもある
  • どうすんのこれ?を今考えてたりする
    • 稼働中のシステムの脆弱性の大半はエスケープのミス忘れたとかそんなもん。なのになんで直らない?
    • いっそのこと「脆弱なサイトはこちらでーす」と公開してしまいたいくらい
    • 現場的にはどんなプロセスなら現実的なの?
      • ネックなのは予算?技術?体制?顧客の理解?
  • 以下パネルディスカッション
    • 941 さんのすばらしいまとめ -> http://togetter.com/li/55216
    • Twitter の脆弱性もどんどん悪質化した
      • 公開してしまうと本気で攻撃しちゃう
    • IPA から報告をいれたくても報告先にたどり着くのにえらい時間がかかる場合がある

Perl 1,2,3,4 の歴史 (前田 さん)

  • Perl1 〜 Perl5 までの歴史
  • Tokyo.pm の大きな功績は miyagawa さんに Shibuya.pm を作らせたこと

Perl + Android (naoya さん)

  • SL4A
  • Perl だと Android.pm
    • 実際は localhost に JSON-RPC をしている
  • 結構簡単に echo サーバ / echo クライアントがかけたよ
    • 突き詰めると面白そう

Data::MessagePack (tokuhirom さん)

  • バイナリデータを永続化する
  • いろんな言語に対応している
  • Perlシリアライズする手法はいくつか
    • Storable
      • Perl 標準でついてくる
      • bless した Object とか Store できちゃう
      • データサイズすごく大きい
      • おそい
    • JSON(::XS)
      • はやい
      • PurePerl でも動くし XS でも動き、環境によって切り替わる
      • データサイズ大きい
    • Data::MessagePack
      • すごくはやい (gfx さんのチューニング)
      • データサイズが小さい
      • PurePerl もサポートした (makamaka さん)
      • bless したデータとかは Store できないよ

String::Filter 構造化テキストの正しいエスケープについて (kazuho さん)

  • XSS がおきにくい設計をするのは大切だよ
    • バグがあってもいいから、セキュアなコードを書きましょう
  • Parse してから Encode するが原則
    • Parser にどんな問題があっても Encode さえしっかりすれば XSS はおこらない
  • Encode 処理は最後にまとめて行ないましょう
  • Xslate などの適切にエスケープ処理をしてくれる Template Engine を使いましょう

Perl Parser Hacks vol.2 (gfx さん)

  • 3倍高速化の gfx さんが、まさかの 3倍トラブル
  • 構文木をごにょごにょしてしまうお話
    • 5.12.0 での実装 (pluggable keyword) は再コンパイルが必要 (?) で使いづらい
    • 5.13.5 での実装はそれが不要で面白いことができるんじゃないか
      • をデモを交えるはずが。。。
  • YAPC ではお待ちかねの Xslate について話しますよ

さいごに

今回も「偶然」出張だったので参加してきました!
うん、偶然。
というわけで、懇親会とかには参加できなかったのですが楽しかったです。
脆弱性あたりの話は難しそうですね。脆弱性の指摘があったときに、すぐに立ち回れる企業と、そうでない企業とありそうですし。
# Twitter にもでてたけれど、外部業者にお願いしていた場合とか
そう考えると、自分のとこもすばやく立ち回れるんだろうか。。。といった疑問も。
そういった意味でも kazuho さんのバグがあってもいいから、セキュアなコードを書くというのは、本当に意識していかなければいけないなぁと思います。
それでも見つかってしまう脆弱性については、すばやく対応することが大切ですよね!
Template Engine がその辺はよしなにしてくれるから!と知っていても、脆弱性についてきちんと理解しておくことも大切ですね。