タグ

2009年12月19日のブックマーク (7件)

  • アメリカでうまい食事をする3つの方法 - 新井俊一のソフトウェアビジネスブログ

    多くの日人はアメリカの飯はまずいと言っていますが、少なくともこの数年は大都市ではうまい飯にありつくことができます。 但し、そのためには十分な下調べが必要です。日で売っているガイドブックに載っている店なども、それほど悪くはないと思いますが、それだけでは選択肢が限られてしまいます。

  • 小学校襲撃事件について - 猿虎日記

    12月4日、京都のある小学校の校門の前に大勢の男たちがおしかけ、「門をあけろ」と騒ぎたてました。彼らは、拡声器を学校に向けて罵声をあびせかけ、この学校の設置していたスピーカーのコードを切り、それを、朝礼台とともに、門に向かって投げつけたということです。学校の中にいた子どもたちはおびえ、中には泣き出す子もいたということです。 ところが、その場にいた警察は、この犯罪行為を静観するだけでした。また、この事件はマスコミではほとんど(まったく?)報道されませんでした*1。 以下は、事件の一部始終を撮影した映像です。 http://corea-k.net/date/000.wmv 映像をご覧になればわかるでしょうが、この学校は、朝鮮学校(京都朝鮮第一初級学校)*2でした。これが、「普通の」小学校だったら、どうだったでしょうか。襲撃した在特会(在日特権を許さない市民の会)という団体の行為そのものもひどい

    小学校襲撃事件について - 猿虎日記
  • デザインパターンを読み解く

    ポリモーフィズム(サブクラスによる切り替え、抽象化) ここに分類されるのは、オブジェクト指向の第3原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。<参照> 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }

  • @IT:クロスサイトスクリプティング対策の基本

    最近Webアプリケーションに存在するセキュリティホールが注目を浴びている。その中でも「クロスサイトスクリプティング」と呼ばれる脆弱性が有名であるが、クロスサイトスクリプティング脆弱性について正確に理解している人が依然として少ないと感じる。 稿では、クロスサイトスクリプティングとはどのような脆弱性であるのか、この脆弱性を持ったサイトが攻撃されるとどのような被害が起き得るのか、なぜそのようなセキュリティホールが作り込まれてしまうのか、どのように対策をすればよいのかを解説していく。 ※以下文中では、クロスサイトスクリプティング脆弱性のことを「XSS」と表記する。「Cross Site Scripting」の略であるから「CSS」と表記している記事もあるが、「Cascading Style Sheets」の略も「CSS」となり紛らわしいため、「XSS」と表記する場合が多くなってきている。稿で

    @IT:クロスサイトスクリプティング対策の基本
  • CSRF対策は基本? | 水無月ばけらのえび日記

    コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや

  • 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法

    ■ クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃(掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為)はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追

  • クロスサイトリクエストフォージェリ - Wikipedia

    クロスサイトリクエストフォージェリ (cross-site request forgery) は、Webアプリケーションの脆弱性の一つ[1]もしくはそれを利用した攻撃。略称はCSRF(シーサーフ (sea-surf) と読まれる事もある[2][3])、またはXSRF。リクエスト強要[4]、セッションライディング (session riding[3]) とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていた[要出典]。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証 (CWE-345) による脆弱性のひとつとして分類している (CWE-352)[5]。 なおCSRFの正式名称はクロスサイトスクリプティング (XSS) と似ているが、XSSは不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類されており[5]、全く異なる種類の