天方です。

今日からモテるアルゴリズム講座を始めたいと思います。

それでは、第1回グラフでモテたいの講義を始めようと思います。
なんといってもアルゴリズムができるとかいうと、いろいろモテます。
この講座を通じて、皆さんもアルゴリズムをマスターしてモテてください。

本日は、モテるアルゴリズムを考える上で重要な
グラフのデータ構造について話をしたいと思います。

グラフというと、普通思い浮かべるのは棒グラフとか円グラフとかかもしれませんが、今回は違います。そんな反応をしていると婚期を逃します。

グラフというのは、点と枝かつながってできるものをグラフと言います。

グラフの例

グラフはいろいろな分野で使われていると思いますが、
あのGoogleも検索エンジンのページの順位付けのためにグラフの概念を利用していたいりします。

さて、グラフをコンピュータ上で扱おうとすると、そのデータ構造の持たせ方に悩みます。
グラフ用のライブラリを使えばそれほど大変でもないのですが、やはり自分で書いた方がモテます。

グラフをデータとして表現するにはいくつか方法があります。
では、上記の図で示したグラフをさまざまなデータ構造で表現してみようと思います。

まず、上の図の点と枝を数学的な表現を使って次のように表現することにします。

点の集合

枝の集合

その場合、点と枝の接続関係は次のようになります。

枝, 始点, 終点

ちなみに、向きがある枝でできたグラフを有向グラフと呼びます。
向きがない枝でできたグラフを無向グラフと呼びます。

こういったグラフを表現するデータ構造としては、枝の始点と終点の番号の組を持たせることでグラフを表現する方法があります。

それではこのグラフのデータ構造をRubyをつかって表現してみましょう。

例えば、上記の視点と終点をRubyの配列で表現すると下記のようになります。

start_vertex = [1,2,3,4,5,6,1,5,3,1]
end_vertex = [2,4,4,5,6,1,3,2,6,1]

これは、さきほど示した数学的な表現だと下記のような表現になります。
… ①

配列の添え字が、枝の添え字 – 1になります。

頂点間に枝があるかどうかを調べるには
頂点数をnとするとの計算量(時間的)がかかります。
また、計算量(空間的)は枝数をとするとです。

そこで、各頂点毎に、出入りする枝を持つという手があります。

たとえば、下記の様な図のように一つの頂点に出入りする枝に注目します。

頂点v1に入る枝と出る枝の例

これはRubyで表現すると下記のようになります。

start_edge = [[1, 7, 10], [2], [3, 9], [4], [5, 8], [6]]
end_edge = [[6, 10], [1, 8], [7], [2, 3], [4], [5, 9]]

数学的な表現では下記のようになります。
… ②

これで、頂点と枝の両方から検索ができるデータ構造ができました。ここモテます。
でも、もうすこしハイクラスのモテを期待したい場合は、クラスを利用したほうがいいと思います。

さて、配列でグラフを表現できるとからモテモテだと思っていい気になってはいけません。
やはりグラフを表現する場合にもTPOがあります。
例えば、他のラフの表現方法としては、接続行列を使う方法もあります。

接続行列 … ③

縦の座標が頂点の添え字、横の座標が枝の添え字に対応し、
要素が1であれば、その頂点を始点、要素が-1であれば、その頂点を終点とすることを表現しています。
この場合、計算量(空間的)はです。頂点間に枝があるかを調べる計算量(時間的)はです。
ちなみに、接続行列だと、自己ループしている枝を表すことができません。
そういえば、さきほどの配列を用いた、枝の始点と終点の番号の組のデータ構造だと、枝がない頂点を表現できません。
そこらへんについて、「ちょっときみ、そのデータ構造だと、自己ループが表現できないので、今回の案件には使わない方がいいと思うよ」と
それとなく耳打ちできるとそれとなくモテます。

他に隣接行列で表現する方法もあります。

隣接行列 … ④

これは、縦の座標を始点の頂点の添え字に対応させ、横の座標を終点の頂点の添え字に対応させて表現したもので、1なら接続している、0なら接続していないという表現です。この場合、計算量(空間的)はです。頂点間に枝があるかを調べる計算量(時間的)はです。
みなさん、もうお気づきとは思いますが、隣接行列では、同じ始点、終点をもつ複数の枝を表すことができなくなります。

さて、４種類ほど表現方法を扱いましたが、それぞれの表現では、表現できるパターンの制約や、グラフを参照、更新する場合の計算量（時間的、空間的）などが違います。
シチュエーションや、相手の好みによって、表現方法を変えるとモテまくります。

みなさんもグラフでモテてみませんか？

久末です。

先日(2月22日)、プログラマーズカフェナイト@原宿というイベントを弊社で行いました。

今回はLTをメインに行いました。

プログラマーズカフェナイトの様子 Photo by 三鷹PGカフェ

さて、今回のLT発表者は以下の方々です。

プログラマーズカフェナイト – 紅茶屋くいっぱのあれこれ日記

webプログラマが楽にiPhoneアプリを開発する方法
@jishiha

3分でできるGoogle App Engine
@bluerabbit777jp

ExtJS & HTML5
@Tommy1969

お手軽 GoogleAppEngine / Java + slim3
404 shin1のつぶやき ないわー Not Found: 第１回プログラマーズカフェナイト＠原宿に参加した #pgcafe
@shin1ogawa

ギークハウスの話
@youchan

月曜日にもかかわらず40名募集のところに47名ほどの応募があり、最終的には30名程度、Ustreamの試聴が30名を超えるイベントになりました。

LT発表者のみなさん、参加者のみなさん、お手伝いのみなさん、ありがとうございます。

三鷹プログラマーズカフェとは？

プログラマーズカフェナイトは三鷹プログラマーズカフェの派生イベントと述べましたが、
三鷹プログラマーズカフェをご存じない方のために簡単にご紹介を。

三鷹プログラマーズカフェは、毎週木曜日、15〜18時に、三鷹産業プラザ地下1階で開催しているイベントです。
プログラマ(とは限らないのですが)が集まって話ができる「場」を提供しています。

プログラマーズカフェは会話が主体で、勉強会やセミナーと違って特定の目的がありません。
ですから、

• 自分で作ったプログラムやサービス
• 最近近話題になっている技術やサービス
• 仕事のこと
• 三鷹のこと
• プログラマーズカフェ自体のこと
• 世間話

といった話だけでなく、ちょっと公開できないようなこぼれ話や、プログラムなどとは全く関係のない話など、話題はあらぬ方向へ散らばっていきます。
それが面白いかどうか、役に立つかどうかはその人次第ですが、よくわからないものに積極的に興味を持てる人ならおもしろさを感じられるかもしれません。

三鷹プログラマーズカフェの主催は以下の三方です。

• @kuippa
• @kclab
• @ysakaki

時間があったらこちらにも是非参加してください。

三鷹プログラマーズカフェと私

私(久末)は、昨年まで弊社が三鷹駅付近にあった関係で、三鷹プログラマーズカフェの最初のイベントから参加することができました。
以来、できるだけ毎回参加しています。何が参ｌ

なぜプログラマーズカフェナイト＠原宿なのか

三鷹プログラマーズカフェは公式には15時〜18時なのですが、実際は、18時以降も
三鷹産業プラザ内のCafe Hi Famigliaさんで、話が盛り上がったりしています。

とはいえ、公式には、平日の午後に開催ということで一般の会社務めの方には現実的に難しいのも事実。
そこで、たまたま弊社が三鷹から原宿に引っ越し、イベントができるスペースがあるということで、
夜のカフェをやろうという話をプログラマーズカフェの方々に持ちかけました。
すると主催のkuippaさんをはじめ、プログラマーズカフェに参加している数名に賛同していただき開催に至りました。
以下が今回の実行委員会的なメンバー。

• @2celeb
• @jishiha
• @kohyama
• @kuippa
• @naoranger
• @THashidate
• @hisasue

次回

さて、実は、次回については、既に話を始めています。
興味のある方は是非参加してください。
告知は

三鷹プログラマーズカフェ (pgcafe) on Twitter
http://twitter.com/pgcafe

で行いますので、気になる方はフォローしてください。

最後に、弊社で開催と言っていますが、ここのオフィスはそもそも株式会社シナップさんのオフィスで弊社がオフィスシェアをさせていただいている場所です。
この素敵なオフィス空間を無償でイベントに使わせてくださったシナップさんにも感謝します。

久末です。

Google Buzz(以下、Buzz)は今のところカオスです。
そしてBuzzの中ではBuzzについての話が多く、何かに利用しようと思っている人には全く使えないかも知れません。

一方、Buzzの中ではBuzzに対して良好なコメントが見受けられます。
中にはTwitterやFacebookをやめてBuzzに移ったという発言もあるほどで、何らかの中毒的な要素はあるようです。
例えば、多くのユーザをフォローすれば多くのユーザからフォローされ、投稿すると、早ければ1分〜数分で複数のコメントが付きます。
反応しやすいBuzzには数百のコメントが付くこともあります。

他方、Buzzの外ではBuzzに対して批判的な意見も少なくありません。
リリースされたばかりのサービスではありがちなので、無視しましょう。
Twitterだってはじめはそんなもんでした。

さて、ここで私が投下したものをご紹介します。

http://www.google.com/buzz/hisasue/NL4j1MqWKMx/フォローの数のわりに新しい

フォローの数のわりに新しい投稿があんまりないのかな？
代わりにスレッドにコメントする投稿が多いとかなのかな？

とBuzzった内容には38のコメントがつきました。
ここでは、Buzzは(Twitter)より会話的だというコメントが多く見られました。
会話の連続性を妨げるようなTwitter雪崩(Twitterと連携しているユーザのつぶやきが
Buzzの画面に一気に流れる現象)のようなものは敬遠され、
コメントしやすいネタを提供といったものには好反応を得られるということでしょうか。

次。

http://www.google.com/buzz/hisasue/g9t46SShA9a/Buzzるほどでもないスレですが

Buzzるほどでもないスレですが？
テキトーな会話とか独り言とか歓迎

という私の投稿では現在のところ70のコメントが付いています。
これは数日間にわたって、ゆるい雰囲気のなか、コメントが続いている状態で、
2ちゃんねるのまったりとしたスレッドのようです。

また、Buzzは現在フォロー数の制限がありませんので、
数十〜数百のフォローは当たり前で、数千から数万人をフォローしている強者もいます。
そのフォロー数を可能にしているのは様々な言語圏のユーザです。
翻訳サイトの力を借りるなどして、積極的に異言語ユーザのBuzzにもコメントするユーザも珍しくありません。

私も中国語のBuzzに「日本人」という発言を見てコメントしてみました。

http://www.google.com/buzz/113897357861978367159/1yTZ95D8niZ/好多日本人FOLLOW-我-怎么回事

Edward Huang       　好多日本人FOLLOW 我，怎么回事？
(日本人はなぜ私をフォローするんだ？)
Takahiro HISASUE   It’s not problem for them that following person is Japanese or not
(日本人とか関係ないんだよ)
Edward Huang       　Yes,indeed,I am just curious. What a pity,I don’t speak Japanese
(まったく。不思議だよ。残念ながら私は日本語分からないしね)
Takahiro HISASUE   Im a Japanese. But talking with you in English. It’s so fun.
(私は日本人だよ。でも英語で話せるから結構面白い)
jan zx             　　　　　ますます面白くなったね！
(※中国語圏と思われる人が日本語でコメントしたもの)

(()は私が翻訳したもの)

こんな感じです。

もちろん、まじめな議論もあったりします。
以下のBuzzはBuzzにFacebookにあるようなゲームは必要だろうか？という話です。
200以上のコメントが付いているようです。

http://www.google.com/buzz/BuzzUsers/VoXtjjD9xrw/Social-Games-like-Farmville-on-Google-Buzz

Social Games like Farmville on Google Buzz?

Social Games Like Farmville and Google Buzz?
This is one of the biggest issues I have been hearing discussed about the future of Google Buzz. There are two ends of the argument for whether Google should allow social games like Farmville, and Mafia Wars to be allowed on Buzz. One thing is almost certain. We will see apps being developed specifically for Google Buzz in the near future. Just like you can use apps in Google Wave, I fully expect to have the same features in Buzz. Social gaming would surely make buzz even more attractive

というわけで、

「で？」「だから？」「なんなの？」「Googleがマイクロソフト化するの？」

と感じる方も多いと思います。

「○○でいいじゃん」

と思えるサービスもあるでしょう。
私もこんなにフォローして意味あるのかなと思いながらが、
ちょっと多めにフォローを繰り返し、Buzzの画面をPCや携帯から覗いています。

しかし、積極的にやってみるとBuzzにはBuzzの味わいがあります。
デジタルなものに味わいがあるのかかどうか分かりませんが、何となくそういう感じなので、しかたがありません。
というわけで、Buzzを上手く説明できる気がしなかったので、今回は私が実際に使ってみたことを、かいつまんでご紹介してみました。
まとめるべきところをまとめず、適当に何となく終わってみるのもBuzz的かなぁ、なーんて。

お粗末様でした。

P.S.
よかったら、フォローしてください。
http://www.google.com/profiles/hisasue#buzz

谷口です。

Zen Cartで商品を登録して、商品ページが表示されるようになったのは良いけど、「この情報は商品ページに出したくないな」とか、「この商品はカートに入れられないようにしたいなぁ」とか、商品ページの情報を調整したいものです。
当然、テンプレートをカスタマイズすればできるのですが、テンプレートのカスタマイズは専門の知識も必要となり、運営者自身で編集するには敷居が高いこともあるかと思います。

でも、実はZen Cartでは商品ページに表示する内容をある程度調整ができます。
テンプレートをカスタマイズすることなく、管理画面から調整できる項目であれば、専門知識を必要としないので、誰でも簡単にできます。

では、具体的にどんな設定ができるのか、簡単に紹介しようと思います。

まずは、とても分かりやすいメニューとして、商品情報の設定のメニューは[一般設定] → [商品情報の設定]で基本的な設定ができます。
ここでは以下のような設定ができます。

若干分かりにくいのですが、実はもう一つ商品ページに関する設定ができる画面があります。
それは･･･[商品の管理] → [商品タイプの管理]の[表示設定]です。
なんとこの画面で設定できる項目は、商品タイプ毎に変えることが可能です。
「商品タイプGeneralなら重量表示する」、「商品タイプDocumentなら重量表示しない」とかです。
こちらの画面で設定できる項目には、商品登録時の設定もありますので、商品ページの表示に関わる項目のみ簡単に紹介します。

ただ、これらの表示設定はテンプレートによっては、設定しても効果のないものもあります･･･。
そんなときは、テンプレート作成した人を恨みつつ、カスタマイズすることになってしまいます。
業者にテンプレート作成を依頼する場合は、業者に設定が効かなくなる項目があるかないかを確認をすると良いと思います。

さて、ここで紹介した商品ページの設定だけでなく、Zen Cartでは一覧ページの設定、画像の大きさ、カート画面の表示設定などなど、表示に関してだけでもいろんな設定ができます。
（おかげで管理画面が複雑になりすぎてるわけですが･･･。）
ページの内容を変えたいと思ったときは、カスタマイズをする前に一度管理画面でできないか確認してみると面白い発見があるかもしれませんね。

こんにちは。木村です。

今回は3.1 CSRF Countermeasuresです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

——————————————————

3.1 CSRF Countermeasures

3.1 CSRFの対策方法

- First, as is required by the W3C, use GET and POST appropriately. Secondly, a security token in non-GET requests will protect your application from CSRF.

- まず最初にW3Cが求めるようにGETとPOSTを適切に使用する。2番目に、GETではないリクエストにセキュリティトークンを付加することでCSRFからあなたのアプリケーションを守ります。

The HTTP protocol basically provides two main types of requests – GET and POST (and more, but they are not supported by most browsers). The World Wide Web Consortium (W3C) provides a checklist for choosing HTTP GET or POST:

HTTPプロトコルは基本的に主に2つのタイプのリクエストを提供します。GETとPOSTです(他にもありますが、ほとんどのブラウザでサポートされていません)。 The World Wide Web Consortium(W3C)はHTTP GETまたはPOSTの仕様を選択する時のチェックリストを提供しています。

Use GET if:

GETを使う場合：

• The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

• インタラクションな操作が問い合わせである(すなわち、検索や読み込みや参照のような安全な操作のことです)

Use POST if:

POSTを使う場合：

• The interaction is more like an order, or
• The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
• The user is held accountable for the results of the interaction.

• インタラクションな操作が命令である、または
• 操作の影響でリソースの状態を変更することがユーザにわかりやすい(例えば、サービスへの登録です)、または
• ユーザが操作結果の責任を負わせられる。

If your web application is RESTful, you might be used to additional HTTP verbs, such as PUT or DELETE. Most of today‘s web browsers, however do not support them – only GET and POST. Rails uses a hidden _method field to handle this barrier.

もしあなたのWebアプリケーションがRESTfulならば、あなたはPUTやDELETEのような追加のHTTPメソッドに慣れていることでしょう。
しかしながら、今日のWebブラウザのほとんどは、GETとPOSTだけをサポートしてPUTやDELETEをサポートしていません。
Railsはこの障壁に対処するために、hiddenの_methodフィールドを使用します。

The verify method in a controller can make sure that specific actions may not be used over GET. Here is an example to verify the use of the transfer action over POST. If the action comes in using any other verb, it redirects to the list action.

コントローラのverifyメソッドはGETで特定のアクションが使用できないように確認することができます。POST上でtransferアクションの使用を検証する例は次の通りです。もし何か別のメソッドを使用したアクションが来た場合、listアクションにリダイレクトしています。


verify :method => :post, :only => [:transfer], :redirect_to => {:action => :list}


With this precaution, the attack from above will not work, because the browser sends a GET request for images, which will not be accepted by the web application.

この予防策によって、ブラウザが送るイメージへのGETリクエストがWebアプリケーションに受理されないため、上記の攻撃(3. Cross-Site Request Forgery (CSRF)で例に挙げられている攻撃)は動作しません。

But this was only the first step, because POST requests can be sent automatically, too. Here is an example for a link which displays www.harmless.com as destination in the browser’s status bar. In fact it dynamically creates a new form that sends a POST request.

しかし、これは最初のステップに過ぎません。なぜなら、POSTリクエストも自動的に送ることができるからです。ブラウザのステータスバーに目的地としてwww.harmless.comと表示しているリンクの例が次の通りです。実際にはそのリンクはPOSTリクエストを送る新しいフォームを動的に生成します。


<a href="http://www.harmless.com/" onclick="
var f = document.createElement('form');
f.style.display = 'none';
this.parentNode.appendChild(f);
f.method = 'POST';
f.action = 'http://www.example.com/account/destroy';
f.submit();
return false;">To the harmless survey</a>


Or the attacker places the code into the onmouseover event handler of an image:

つまり、攻撃者はイメージのonmouseoverイベントハンドラにコードを設置しています。


<img src="http://www.harmless.com/img" width="400" height="400" onmouseover="..." />


There are many other possibilities, including Ajax to attack the victim in the background. The solution to this is including a security token in non-GET requests which check on the server-side. In Rails 2 or higher, this is a one-liner in the application controller:

バックグラウンドで攻撃するためにAjaxを含んでいると、他に多くの可能性があります。この問題の解決方法はGETではないリクエストにサーバ側でチェックするセキュリティトークンを付加することです。Rails2またはそれ以上のバージョンでは、application controllerでワンライナーで書かれています。


protect_from_forgery :secret => "123456789012345678901234567890..."


This will automatically include a security token, calculated from the current session and the server-side secret, in all forms and Ajax requests generated by Rails. You won’t need the secret, if you use CookieStorage as session storage. It will raise an ActionController::InvalidAuthenticityToken error, if the security token doesn’t match what was expected.

これはRailsによって生成される全てのフォームとAjaxリクエストに、現在のセッションとサーバ側の秘密の文字列から作られるセキュリティトークンを自動的に付加します。セッションストレージとしてCookieStorageを使用しているならば、秘密の文字列は必要ありません。セキュリティトークンが期待されるものとマッチしなければ、ActionController::InvalidAuthenticityTokenエラーが発生するでしょう。

Note that cross-site scripting (XSS) vulnerabilities bypass all CSRF protections. XSS gives the attacker access to all elements on a page, so he can read the CSRF security token from a form or directly submit the form. Read more about XSS later.

cross-site scripting(XSS)は全てのCSRF対策を回避することに注意してください。
XSSは攻撃者にページ上の全ての要素へのアクセスを許します。そのため、攻撃者はフォームからCSRFセキュリティトークンを読み込むか、直接フォームを投稿することができます。
XSSについての詳細は後述します。

——————————————————

次回は4 Redirection and Filesです。

こんにちは。木村です。

今回は3 Cross-Site Request Forgery (CSRF)です。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

3 Cross-Site Request Forgery (CSRF)

3 クロスサイトリクエストフォージェリ (CSRF)

- This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands.

- この攻撃方法は、悪意のあるコードやリンクを含んだページが、ユーザが認証済みのWebアプリケーションにアクセスするによって動作します。もし、Webアプリケーションのセッションがタイムアウトになることがなければ、攻撃者は不正なコマンドを実行する可能性があります。

In the session chapter you have learned that most Rails applications use cookie-based sessions. Either they store the session id in the cookie and have a server-side session hash, or the entire session hash is on the client-side. In either case the browser will automatically send along the cookie on every request to a domain, if it can find a cookie for that domain. The controversial point is, that it will also send the cookie, if the request comes from a site of a different domain.
Let’s start with an example:

sessionの章で、ほとんどのRailsアプリケーションはクッキーベースのセッションを使用していることを学びました。クッキーにセッションIDを保存して、サーバサイドにセッション情報をもつか、または全てのセッション情報をクライアントサイドに置く方法です。どちらにせよ、ブラウザはあるドメインのクッキーを見つければ、リクエスト毎にそのドメインにクッキーを送ります。問題となる点は、もしリクエストが違うドメインのサイトから来たとしても、ブラウザがクッキーを送ってしまうことです。ある例から始めましょう。

• Bob browses a message board and views a post from a hacker where there is a crafted HTML image element.
  The element references a command in Bob’s project management application, rather than an image file.
• 
• Bob’s session at www.webapp.com is still alive, because he didn’t log out a few minutes ago.
• By viewing the post, the browser finds an image tag.
  It tries to load the suspected image from www.webapp.com. As explained before, it will also send along the cookie with the valid session id.
• The web application at www.webapp.com verifies the user information in the corresponding session hash and destroys the project with the ID 1.
  
  It then returns a result page which is an unexpected result for the browser, so it will not display the image.
• Bob doesn’t notice the attack – but a few days later he finds out that project number one is gone.

• ボブは掲示板を開いて、巧妙に作られたHTMLイメージ要素が置かれたハッカーの投稿を見ます。
  
  その要素はイメージファイルではなく、ボブのプロジェクトマネジメントアプリケーションのコマンドを参照しています。
• 
• ボブは数分前にログアウトしなかったため、www.webapp.comのセッションはまだ有効です。
• ハッカーのポストを見ることによって、ブラウザはイメージタグを見つけます。
  
  ブラウザはwww.webapp.comから疑わしいイメージを読み込もうとします。
  
  前述の通り、その前にブラウザは有効なセッションIDを持ったクッキーを送ります。
• www.webapp.comのWebアプリケーションはセッションハッシュと一致するユーザ情報を確認し、ID 1のプロジェクトを削除します。
  
  それからWebアプリケーションはブラウザにとって予期しない結果のページを返します。なぜなら、それは画像が表示されないからです。
• ボブは攻撃に気づきません。しかし数日後に彼はプロジェクトナンバー1がなくなっていることに気づくでしょう。

It is important to notice that the actual crafted image or link doesn’t necessarily have to be situated in the web application’s domain, it can be anywhere – in a forum, blog post or email.

実際の巧妙に作られたイメージやリンクに配慮することは重要です。それらは必ずしもWebアプリケーションのドメインに置かれているとは限りません。フォーラムやブログ記事、またはメールなどのどこにでも存在するのです。

CSRF appears very rarely in CVE (Common Vulnerabilities and Exposures) – less than 0.1% in 2006 – but it really is a ‘sleeping giant’ [Grossman]. This is in stark contrast to the results in my (and others) security contract work – CSRF is an important security issue.

CSRFは脆弱性情報データベース(Common Vulnerabilities and Exposures)に現れることはめったにありません。2006年では0.1%未満です。しかし実際には’眠れる巨人’なのです[Grossman]。この結果は、私が(また他の人が)請け負っているセキュリティの仕事での結果とは全く対照的です。CSRFは重要なセキュリティ問題なのです。

次回は3.1 CSRF Countermeasuresです。

谷口です。

とても今更なタイトルですが、初めてZen Cartに触れた人に新しいページの作成方法を説明するのは、意外と伝えることが多くて面倒だったりします。
最低限必要な操作だけでも出しておけば何かと便利かなと思いまとめてみました。

1. 新規ページ用のmain_pageパラメータを決め、定数を定義する
2. ページ表示用のモジュールディレクトリを作成する
3. モジュールファイル、テンプレートファイル、言語ファイルを作成する

最も単純なページ作成方法は以上です。（定番ページの追加はまさにこれだけ）

1. 新規ページ用のmain_pageパラメータを決め、定数を定義する

例えばhogeというページを作成することに決めたとします。
定数の定義は、includes/filenames.php に追記してもできるのですが、より良い方法があります。
includes/extra_datafilesディレクトリに設定ファイルを追加する方法です。

= includes/extra_datafiles/hoge.php

  define('FILENAME_HOGE', 'hoge');

2. ページ用のモジュールディレクトリを作成する

includes/modules/pages/にhogeディレクトリを作成します。

 $ mkdir includes/modules/pages/hoge

上記ディレクトリを作成したら、とりあえずheader_php.phpというファイルを作成し、テンプレートファイルを作成します。

 $ touch includes/modules/pages/hoge/header_php.php

 $ touch includes/templates/TEMPLATE_DIR/templates/tpl_hoge_default.php

※TEMPALTE_DIRは使用しているテンプレートのディレクトリに置き換えてください。

これでindex.php?main_page=hogeにアクセスすればメインコンテンツが何もないページが表示されます。

3. モジュールファイル、テンプレートファイル、言語ファイルを作成する

先ほど作成した2ファイルを作っていけばページが作成できるのですが、せっかくの多言語化されているのでその流儀にのっとって、言語ファイルで固定の文言を作成します。
日本語の場合、hogeで使う言語ファイルを以下のパスに作成します。

includes/languages/japanese/hoge.php

次にincludes/modules/pages/hoge/header_php.phpで言語ファイルを読み込みます。

= includes/modules/pages/hoge/header_php.php

　require(DIR_WS_MODULES . zen_get_module_directory('require_languages.php'));

あとは、テンプレートで使う固定の文言（見出しなど）をincludes/languages/japanese/hoge.phpに定数定義していけば、
新しいページの作成準備完了です。

あとは、ページにアクセスしたときの動作をモジュールファイルに書いたり、好きなようにテンプレートファイルにデザインすれば完成です。
ちなみに、テンプレートファイルで使用する変数（商品名など）はモジュールディレクトリにmain_template_vars.phpを作成してそこでセットしていく感じです。
（header_php.phpで書いても良いですけどね･･･）

最後に

まとめてみて思ったのですが、これスクリプトにできますね･･･。作ったら公開しようかと思います。

谷口です。

10月にオープンソースカンファレンスに行った記事を書いたのですが、早いものでもうすぐまた開催されますね。

オープンソースカンファレンス2010 Tokyo/Spring

日程：2010年2月26日(金)・27日(土) 10:00-17:00

会場：明星大学 日野キャンパス 26号館（多摩モノレール 「中央大学・明星大学駅」から大学まで直結。会場まで徒歩5分）
　　　[アクセスマップ] [キャンパス案内]
　　　（ご来場の際は公共交通機関をご利用下さい）

費用：無料

内容：オープンソースに関する最新情報の提供
・展示 – オープンソースコミュニティ、企業・団体による展示
・セミナー – オープンソースの最新情報を提供

主催：オープンソースカンファレンス実行委員会

協賛：明星大学
　　　明星大学　情報学部

おそらく今回もZenCart.JPで参加することになると思いますので、みなさま是非是非お越しください！
ZenCart.JPは参加しないことになりました･･･。
Kobeの方は出展するので、関西の方はよろしくお願いします。私は参加できませんが･･･
でも、近いので個人的に行こうと思います！

今回はセミナーにも出たい･･･

那須です。

最近、その時々で調べたtipsをtwitterでつぶやいたりしてます。主に自分の備忘メモとして使っています。後日検索することがあるかといえば。。。今のところは特にないのですが、とはいえ埋もれてしまっていざというときに使えないのは残念なので、こちらにまとめておこうと思います。

私の全てのつぶやきはこちら

Excel

=COUNT(INDEX(1/(MATCH(A1:A39,A1:A39)=ROW(A1:A39)),0))　a1からa39の中でユニークな値の数を算出。理解できないけど、ひとまず動く #Excel

1/MATCH() が未だによくわからないなぁ

perl

$SIG{INT}=”IGNORE”;$p=fork;if($p){wait;}else{$SIG{INT}=sub{$a=1};sleep 30;sleep 5;if($a){die}} SIGINTすると子プロセスの最初のsleepがリセットされる #perl
perl -n -l -e ‘print +(split(/\t/))[2]‘ filename cut使えって話 #unix
perl -n -l -e ‘print +(split(/\t/))[2]‘ filename タブ区切りの3列目だけ抽出 -n の使い道 #perl
[perl] \b 単語境界　$& マッチ変数　正規表現構文
[perl] perl -i.bak -wnl -e ’s/A/B/g; print’ file 上書き編集
[perl] -l 改行 -n 暗黙ループ -p 読み込みループ perl -wpl -e ” file1 file2 イミフ

UNIX

PAGER JLESSCHARSET=japanese /usr/bin/less -isr 日本語文字化けの時man.confにこれ書く。書けなければ man -C ~/man.conf とかする #unix
1:06 PM Dec 25th, 2009 from web
[bash] command 2> /dev/null STDERRの出力を捨てる。
[unix]grep -L 文字列が含まれないファイル一覧を返す GNU grep
[unix]find . -type f -print | xargs ls -lrdt | tail -l xargsの処理できる引数の数を越えると期待通りにいかない

MySQL

[MySQL] INSERT INTO table () VALUES () ON DUPLICATE KEY UPDATE を使ったときに、UPDATE側が作動すると affected rows が 2になる。これにはめられました。
[MySQL] order by で DESCとASCが混在するとインデックス利きません
[mysql]auto_incrementの解除にはalter table changeを使う

affected rowsの件は本当にハメられたましたよ。というかこれMySQLのバグじゃないのかな…replace into が affected rows = 2 になるのは、実質 delete & insert かけるので正しいと思うけど、insert on duplicate はinsert失敗してupdateかかるわけだし、affected rows = 1 が正しい気がする

PHP

[PHP]foreach内ではbreakが効かないらしい。初めて知った

よく考えたら、知っていた気もする。

SVN

[svn] function svnvimdiff() { tmp=[file]; vimdiff $1 `svn cat $1 > $tmp ;ls $tmp;` && rm -f $tmp; } vimdiffで名前付パイプがうまく機能しないとき用
[svn] vimdiff [file] < (svn cat [file]) svnの差分をvimdiffで見る
[svn] svn diff --diff-cmd /usr/bin/diff -x "-b -E" svnでのdiffコマンドの変更とかに

svnvimdiff 重宝してます。

vim

[vim] :s/./&\r/g　行を一文字区切りで改行する。「あ\nい\nう\nえ\nお\n…」のような列を作るのに便利
[vim]:set noro リードオンリモードの解除。sambaとかにある共有ファイル開くときとかデフォルトで-Rしといて必要なときにこれ使うようにしようかなぁ
[vim]:compiler perl “-I”が指定できないのかな…
[vim]:set list 制御文字表示。常時はうざいから確認のときに使う

こんにちは。木村です。

今回は2.9 Session Expiryです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

2.9 Session Expiry
2.9 セッションの有効期限

- Sessions that never expire extend the time-frame for attacks such as cross-site reference forgery (CSRF), session hijacking and session fixation.

- 有効期限がないセッションはCSRFやセッションハイジャック、session fixationのような攻撃にかけられる時間を拡大します。

One possibility is to set the expiry time-stamp of the cookie with the session id.
However the client can edit cookies that are stored in the web browser so expiring sessions on the server is safer.
Here is an example of how to expire sessions in a database table.
Call Session.sweep(“20m”) to expire sessions that were used longer than 20 minutes ago.

セッションIDと一緒にクッキーの有効期限のタイムスタンプをセッションにセットしておいてもいいと思います。
しかしながら、クライアントはブラウザに保存されたクッキーを編集できるため、サーバ上で有効期限付きセッションを扱う方がより安全です。
データベースのテーブルで有効期限付きのセッションを扱う方法の例は次の通りです。
Call Session.sweep(“20m”)で20分以上前から使用されているセッションの有効期限が切れます。

class Session < ActiveRecord::Base

  def self.sweep(time_ago = nil)

    time = case time_ago

    when /^(\d+)m$/ then Time.now - $1.to_i.minute

    when /^(\d+)h$/ then Time.now - $1.to_i.hour

    when /^(\d+)d$/ then Time.now - $1.to_i.day

    else Time.now - 1.hour

    end

    self.delete_all "updated_at < '#{time.to_s(:db)}'"

  end

end 

The section about session fixation introduced the problem of maintained sessions.
An attacker maintaining a session every five minutes can keep the session alive forever, although you are expiring sessions.
A simple solution for this would be to add a created_at column to the sessions table.
Now you can delete sessions that were created a long time ago.
Use this line in the sweep method above:

session fixationの項でセッションが保持され続ける問題を紹介しました。
有効期限付きのセッションにしていても、攻撃者は5分毎にセッションを保持し続けることで、セッションを長い時間有効なままにすることができます。
この問題に対するシンプルな解決方法はセッションのテーブルにcreated_atカラムを追加することでしょう。
これで、ずいぶん前に作られたセッションを削除できるようになります。
次の行をsweepメソッドの上に追加してください。

self.delete_all "updated_at < '#{time.to_s(:db)}' OR

  created_at < '#{2.days.ago.to_s(:db)}'" 

次回は3 Cross-Site Request Forgery (CSRF)です。