ROUTE 3390
最近Rubyを勉強していて、今日yield文というのに出会った。 忘れないようにメモ yield文はこんな感じで書く def foo ( name ) yield('おはよう' + name) yield('おやすみ' + name) end foo( 'sasakure' ) do | message | puts message end 結果はこのように表示される おはようsasakure おやすみsasakurefooというメソッドの中でyieldが実行されるたびに、 呼び出し元の後ろに書かれたdoブロックが実行される。 最初にこれ見た時は、 yieldが呼ばれる度に、doブロックを実行する処理が溜まっていって、 fooメソッドが終わった後で順番に実行されるのか、、、とか思ってたけど違った。 fooメソッドの中から、doブロックに飛び出してきて、 またfooメソッドの中に戻って、また
セキュリティに関するいくつかの考察 - qmail 1.0 から10年(Some thoughts on security after ten years of qmail 1.0)
[This is a Japanese translation of Some thoughts on security after ten years of qmail 1.0] Daniel J. Bernstein Department of Mathematics, Statistics, and Computer Science (M/C 249) University of Illinois at Chicago, Chicago, IL 606077 045, USA djb@cr.yp.to CSAW’07, November 2, 2007, Fairfax, Virginia, USA. Public domain. 目次 概要 1. はじめに 1.1 - 「今月のバグ」倶楽部 1.2 - qmail のリリース 1.3 - qmailのセキュリティ保証 1.4 - 本
pg_sleepをSQLインジェクション検査に応用する - ockeghem's blog
SQLインジェクションの進化形として、ブラインドSQLインジェクションという手法があります。通常のSQLインジェクションは、検索結果表示やエラー表示のところに、アプリケーションの想定とは別のテーブル・列の値を表示するものですが、ブラインドSQLインジェクションは、SQLの結果がエラーになる・ならないを1ビットの情報として悪用し、これを積み重ねることで、データベース内の任意情報を得ることができるというものです。 1ビットの情報が得る手段としては、SQLのエラー表示に限らないわけで、現実問題として、SQLのエラーが外部からは判別しにくい場合もあります。そのような場合の究極形として、時間差を利用するという手法があります。 MS SQL Serverには、waitfor delayという命令があって、時・分・秒指定でスリープさせることができます。金床本には、MySQLやPostgreSQLの場合の
サンシャイン牧場・決済代行会社のサポートからの情報 | 水無月ばけらのえび日記
公開: 2009年11月5日10時11分頃 サンシャイン牧場の件ですが、決済代行会社であるゼロのサポートから回答を得たという方が、公式コミュニティにその内容を書き込まれています。 以前のアナウンスに追記されたとおり、今回の話はRekoo側の問題です。が、ゼロ側でもかなり詳細な情報を把握されていて、問い合わせに対してはかなり細かいところまで回答されているようですね。興味深い内容が含まれていますので、一部引用しておきます。 ---流れ--- 1回目の購入 Kコインチャージページ ↓ クレジット決済会社ページ(メールアドレス、電話番号、クレジット情報入力) アプリ会社にメールアドレスと電話番号を渡す(クレジット情報は渡さない) 2回目以降の購入 Kコインチャージページ(前回入力したメールアドレス・電話番号の情報をページに持たせる) ↓ ここで専門知識を持った人だったらページに持たせている情報を見
高木浩光＠自宅の日記 - ドワンゴ勉強会でお話ししたこと
■ ドワンゴ勉強会でお話ししたこと 8月28日の夕刻、ドワンゴ主催の「技術勉強会」にお招き頂き、少しお話をしてきた。テーマは「P2Pネットワーク」。もしもニコニコ動画をP2P方式で配信する（回線コスト軽減のため）としたらというテーマが暗に想定されているようだったので、それに沿ってお話しした。講演者は他に、金子勇氏と、NTTの亀井聡氏、P2P型掲示板「新月」の開発者でドワンゴ社研究開発部の福冨諭氏ほか。 私からお話ししたのは主に以下の2点。 そもそもなぜP2Pにするのか。手段が目的になってしまってはいけない。 利用者のプライバシーを確保する設計の必要性と可能性。 1点目は、以前からあちこちで話してきたことで、そもそも「P2P」とは何かというときに、peer-to-peer方式のネットワークという元来の意味に立ち返れば、decentralizedな構成にできて、ad hocに構成できるといった
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
#perl - utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 : 404 Blog Not Found
2009年09月13日13:00 カテゴリLightweight Languages #perl - utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 駄目です。 [を] Perl の utf8 まわりのおまじない 最近良く使うおまじない、というかイディオム。 utf8::decode($text) unless utf8::is_utf8($text); こういう場合は、Encode::decode_utf8()でないと。 以下をごらんください。 #!/usr/bin/perl use strict; use warnings; use Encode; use Devel::Peek; for my $bytes ( "\x2F", "\xC0\xAF", "\xE0\x80\xAF", "\xF0\x80\x80\xAF" ) { my $u
Inside Yahoo!メール 第1話「迷惑メールとBotnet」
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ソーシャルネット開発部の島貫和也です。Yahoo!メールの配送システムおよび迷惑メール対策を担当しています。 Yahoo!メールはプロバイダ(Yahoo! BB)のメールサービスでもありますが、フリーメールとしての側面もあるため、非常にさまざまな方に多様な形態で利用されています。このようなサービスでは、迷惑メールなどの不正利用を前提とした対策が必要不可欠といえます。 本連載では、今まであまり触れられてこなかったYahoo!メールの迷惑メール対策と、電子メールに関連する情報を数回に分けてご紹介したいと思います。 ご注意 出典元の説明のため、いくつか外部リンクがあります。リンク先については保証しておりませんのでご了承くださ
免許証を悪用されケータイ契約！「お客様は被害者ではない。被害者は我社です」 - ガジェット通信
インターネット掲示板『2ちゃんねる』で、『免許証が詐欺に使われた』というスレッド（掲示板）が注目を集めている。このスレッドを作った人物N氏（仮名）は免許証をなくし、知らないうちにケータイ電話会社3社と契約を結ばれて悪用されたのだとか。さらにインターネットオークションでも悪用されていたという。このことは『ニコニコVIP2ch』にも掲載され、話題を呼んでいる。 「マジでちょっと助けてくれよ。携帯3社中、2社は事態を聞いてくれて調査に入ってくれるっていったのに1社は “正当な手続きなので支払い義務はお客様にあります” って言われた。警察すら俺が犯人じゃないって認めてくれたのにどうしろと」（N氏） このことに対してスレッドには多くの意見が書き込まれており、「なんのために顔写真貼ってあるんだよw その時対応した店員適当すぎるだろ」と、免許証でケータイの契約をするにしても顔写真でチェックするはずだとい
［セキュリティのずさんな実態］現場が結束してポリシー破り
長沢氏は，あるソフトウエア・ベンダーでシステム・エンジニアをしている。長沢氏の会社では情報漏洩対策を強化する施策の一環として，リモート・アクセスを制限するセキュリティ・ポリシーを定めていた。しかし，長沢氏をはじめとする社員の間では，「とても現場の業務を理解しているとは思えない」と不満が募っていた。 その原因は，リモート・アクセスが課長以上の役職者にのみ許可され，長沢氏ら一般社員には一切認められなかったことにある。 役職者はオフィスにいる時間が長く，リモート・アクセスは必要ない。その一方，現場の一般社員は客先から客先へと飛び回るのが日常で，オフィスには夜遅くにしか戻って来られないのだ。しかも，オフィスは最寄り駅から遠い場所にあり，不便だった。 特に，長沢氏の同僚である営業担当者たちは苦労していた。営業活動に必要な「ソフトウエア製品カタログ」や「仕入れ値データ・ファイル」などは，すべて社内のグ
泥棒が教えてくれない13のこと : らばQ
泥棒が教えてくれない13のこと 盗難にあったことはありますか。 日本でも犯罪が増え、盗難に遭ったという被害の声もよく聞くようになってきました。 欧米では家宅への不法侵入が多いですが、「泥棒たちが教えてくれない13の項目」と言うものが話題となっていたのでご紹介します。 1. もちろんどこかで見たことがあるさ。先週、掃除夫をしていたかもしれないし、冷蔵庫の配達をしたかもしれない。 2. 君の家の庭で仕事をしているときにトイレを使わせてくれてありがとう。トイレにいるときにトイレの窓の鍵は開けておいたよ。 3. その花はいいな。住人の趣味がわかるよ。趣味と言うくらいだから、いいものが家にあるってことだ。外にある子供のおもちゃを見て、家の中にはどんなゲーム機があるのかなと想像するんだ。 4. 新聞紙の山を探したり、デリバリーピザを玄関前に置いたりして、それらが住人を動かすのにどれくらい時間が掛かるか
アリコの顧客情報流出収拾策
アリコの顧客情報流出。専門家を呼んできて対策本部を作り調査しているが原因は特定できないらしい。多分専門家など呼ぶ必要はない。原因を特定するに２秒あれば十分だ。問題は関係者がそれを口に出せないところにある。 02年8月から08年5月までの期間にアリコジャパンに直接申し込み、クレジットカードで決済した顧客のうち、証券番号下一桁が２または３の場合、顧客情報が流出したんだそうだ。これだけで分かる。証券番号下一桁が２か３となると、これらのデータ群は人為的にセレクトしたものでなくてはならない。普通はこんな選択行なわれない。考えられるのは本番データを使ってテストを行った場合である。本番データ全件を使うと量が多くて大変なので、なんかの条件でセレクトして使たんだろう。この場合は証券番号下一桁で１／５に減らしたということ。僕も昔は似たようなことをよくやった。 本番データをテストに使うメリットは大きい。システム
ついにきた、HFT - 債券・株・為替 中年金融マン ぐっちーさんの金持ちまっしぐら
（文章が不完全なので後ほど修正いたします） 有料配信7月20日号にて、ゴールドマンの決算を特集したときにゴールドマンが採用したと思われるHigh Frequency Tranding System が広く関与したためにトレーディングの高収益が出たと思う、と書きました。 その後ＦＢＩにゴールドマンのプログラマーが逮捕され、どうやらＮＹＳＥのシステムに不正侵入するためのコードを開発していた、などと伝えられるにつけ、やはり、という確信が我々の間にはひろがって行く訳です。24日にはニューヨークタイムズの記事も出ております。 未確認の情報もたくさんあるので、あまり決定的なことは言わずに来ましたが、間違った情報が随分流れるのており、一部ブロガーの方も必死でフォローされている様子ですので、また、ＣＤＳのときのように一度間違った認識が広まってしまうと大変なので、ここで不完全ながら一度整理をさせて頂きます。
Selfkleptomaniac — iPhoneのカメラでプライバシー情報ダダ漏れだった
Blogging is a disease: selfkleptomania, your normal condition. About GPG Public Key iPhoneで撮影した画像（おもに赤ん坊）をここにたくさん掲載していたが、同僚がExif ViewerというFirefoxのプラグインを見つけて画像情報を見たら、撮影場所の位置情報が見れたというので驚いた。スクリーンショットを保存したつもりができていなかったようで見せられないが、GoogleMapにリンクまで作成してくれるので見事に自宅の場所までわかる。 iPhoneの仕様ではメールでの送信などではGPS情報を削除しているようだが、iPhotoで同期した画像からは消えないので、そのままブログに掲載すると予期していない情報を公開してしまう可能性がある。 というわけで、jheadを使ってデータを修正した。 #!/bin/sh F
UTF-8の動的コンテンツをShift_JISと誤認させることで成立するXSS - masa141421356’s blog
文字コード指定の無いUTF-8のコンテンツでは、ブラウザ側の文字コード自動認識でシフトJISと誤認させることで、HTMLの特殊文字を一切使わずにXSSが成立する場合があります。 原理 UTF-8 では１文字が３バイトマッピングされる場合があります。 そこで、これをShift_JISと誤認させると、３バイト目と次の１バイトをセットで１文字と誤認させることができます。これにより、HTMLの区切り文字の効力を失わせてスクリプトを注入することが可能です。 例："あ" = E3 81 82 なので、シフトJISと誤認すると "縺" (E381) +余分な先行バイトの 0x82 具体例 例えば、動的なコンテンツ（UTF-8で応答を生成） <html> <head> <title>abcde</title> </head> <body> <form> <input type=text value="ユー
jCryptionが危険な理由。 - うっくつさん本を読む。
http://www.moongift.jp/2009/08/jcryption/の話。http://takagi-hiromitsu.jp/diary/を検索すれば幾らでも情報は見つかるとは思うけれど、自分のためにも書いておく。 前振り。 このjCryptionはMan-In-the-Middle攻撃に弱いはずだ。どのように攻撃されるかを具体的に書いてみる。登場人物は クライアント Alice サーバ Bob クラッカー Charlie の三名。 通常の通信。 通常手順での通信は クライアント 通信 内容 サーバ Alice ---接続--> リクエスト Bob Alice <--応答--- Bob公開鍵(平文) Bob Alice ---ポスト--> 暗号文 by Bob公開鍵 Bob というようになっている。 Man-In-the-Middle攻撃。 Man-In-the-Middl
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オール・ザッツ・PCI DSS 連載インデックス - ＠IT
教科書に載らないWebアプリケーションセキュリティ － ＠IT