高木浩光＠自宅の日記 - 無線LANのMACアドレス制限の無意味さがあまり理解されていない
■ 無線LANのMACアドレス制限の無意味さがあまり理解されていない 職業マスメディアに代わって、ブログスタイルのニュースサイトが人気を博す時代になってきた。海外の話題を写真の転載で紹介する安直なニュースも人気だ。 このことろなぜか、無線LANのセキュリティ設定について書かれた記事を何度か見た。おそらく、ニンテンドーDSがWEPしかサポートしていないことが不安をもたらしている（そして実際に危険をもたらしている）ためだろうと思われる。 セキュリティの解説が増えてきたのはよいことなのだが、内容に誤りのあるものが少なくない。 実は危険な無線LAN, らばQ, 2007年10月21日 この記事には次の記述があるが、「接続されなければMACアドレスは盗まれない」という誤解があるようだ。 MACアドレスというのは、機器固有のIDのようなものです。たいていの無線LANアクセスポイントにはMACアドレスフ
堅牢なパスワードを強制するテクニック - 日向夏特殊応援部隊
やっぱりサービス側で堅牢なパスワードをユーザーに強制する仕組みが無いと問題があるサービスと言うのはたくさんあるって事で、Perlで出来る限り簡単にそういう仕組みを作れないかなと。 幾つかピックアップしてみました。 Data::Passwordモジュールを使う 真っ先にこれ。UNIX系OSでのパスワードの強度チェックと似たモジュールのようです。 use Data::Password qw(:all); print IsBadPassword("hogehoge"); 文字列が表示されちゃう場合はNGなパスワード。 このモジュールは辞書設定も出来るようです。 @Data::Password::DICTIONARIESに辞書ファイルを指定しておくとそこの内容も見てくれるみたい。 ありがちなパスワード集はftp://ftp.ox.ac.uk/pub/wordlists/に言語別にあります。 またU
Tips：なぜLimeWireで情報漏洩してしまうのか | P2Pとかその辺のお話
P2Pとかその辺のお話 WinMXとかWinnyとか、日本ではろくな扱いを受けていないP2Pですが、海外ではけっこう真面目に議論されてるんですよというブログ。 取り立ててネットエージェントに恨みがあるわけでもないのだけれど、やはり対策サービスを出してくるたびに引っかかるところがあるので、今回もまた突っ込むよというお話。ITmediaによると、今月17日、ネットエージェントは、「LimeWire/Cabos」における情報漏洩に対応した対策サービスの開始を発表したとのこと。ネットワーク全体をクロールし、漏洩した当該のファイルを「いつ、だれが、どの情報を」入手したのかが判断できると。まぁ、LimeWireやCabosというよりは、Gnutellaネットワークにおけるクロールによってそれを可能にするようだ。 海外では、LimeWireによる情報漏洩は国家安全保障上の脅威だ、といわれるくらいに問題に
高木浩光＠自宅の日記 - ユビキタス社会の歩き方(3) 無線LANのSSIDを不用意に明かさない
■ デイリーポータルZ 記者の家を探しに行く 5月27日の日記「PlaceEngineのプライバシー懸念を考える」では次のように書いた。 つまり、家庭の無線LANアクセスポイントのMACアドレスを誰かに知られることは、住所を知られることに等しい。そのような事態をPlaceEngineサービス（および類似のサービス）が新たに作り出したことになる。 「MACアドレスは個人を特定するものではない」と言えるだろうか？もし、別のネットサービスで、何らかの目的で家庭の無線LANのMACアドレスを登録して使うサービスが始まったとする。そのサービスもまた、「MACアドレスから個人が特定されることはありません」と主張するだろう。このとき、PlaceEngineとこのサービスの両者が存在することによって、わからないはずの住所が特定されてしまう事態が起きてくる。 PlaceEngineなどのサービスが存在する現
高木浩光＠自宅の日記 - ユビキタス社会の歩き方(2) ストーカーから逃れて転居したら無線LANを買い換える
■ ユビキタス社会の歩き方(2) ストーカーから逃れて転居したら無線LANを買い換える 5月27日の日記「PlaceEngineのプライバシー懸念を考える」では、「無線LANアクセスポイントのMACアドレスを知られると、住所を知られることになる」という状況が生じ始めていることついて書いたが、そのリンク元に、それがもたらす被害の具体例としてストーカー被害を挙げている方がいらした。同じことについて私なりに書いてみる。 ストーカーに自宅を特定されて付き纏いなどの被害に遭っている被害者が、ストーカーから逃れるために転居することがしばしばあるようだ。勤務先を特定されていない場合や、転居先がそこそこ遠方であれば、その対処が有効なのだろう。 しかし、無線LANが普及した現在、平均的な家庭には無線LANアクセスポイントの1台や2台は設置されているであろう。自宅を特定したストーカーは、自宅前で無線LANパケ
高木浩光＠自宅の日記 - 対策にならないフィッシング対策がまたもや無批判に宣伝されている, 追記（26日）
■ 対策にならないフィッシング対策がまたもや無批判に宣伝されている 「PCからオンライン取引、ケータイで認証」−ソフトバンクBBの新発想・認証サービス, Enterprise Watch, 2007年9月20日 「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。本当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。（略） 「PCを標的にしたハッキングやDoS攻撃を受ける可能性がゼロになる」（中島氏）。また、偽サイトとはシンクロしないため、フィッシング詐欺を100％防止することも可能だ。 ソフトバンクBB、携帯活用認証システムでWebサイトログイン対応に, ケータイWatch, 2007年9月20日 今回の新機能は、安全・簡便・低コストで、そう
Whillet | Fintech Solutions for embedded finance | BaaS | Open banking
Whillet is embedded finance fintech solutions Our solutions allow consumer companies to provide embedded financial services for your customers in your mobile app or website Open customer wallets seamlessly and immediatelyTop up wallets via bank cards or bank accountsWithdraw money to bank cards and bank accountsImplement or merge your loyalty program with money walletsKYC and all legal procedures
ぼくはまちちゃん！ こんにちはこんにちは!!
君は“はまちちゃん事件”を知っているか？ mixiのホームページ。mixiユーザーの中には、赤で囲んだ“マイミクシィ最新日記”欄に、“ぼくはまちちゃん！”の文字がいくつも並んだ人がいた 古くからのmixiユーザーであれば、“はまちちゃん事件”を覚えている人も多いだろう。2005年4月、mixiで大勢のユーザーが“ぼくはまちちゃん！”というタイトルを付けた、謎の日記を次々に公開するという怪現象が起こった。 きっかけとなったのは、あるユーザーが投稿した日記。その日記の本文には「こんにちはこんにちは!!」という言葉とともに“あるURL”が貼り付けてあった。 このURLが罠で、不思議に思って押すと、クリックしたユーザーのページに“ぼくはまちちゃん！”というタイトルで同じ文面/URLの日記が勝手にアップされてしまうのだ。 投稿は“ねずみ算”的に増え、一時は混乱状態に…… さらに、勝手にアップロードさ
ぼくはまちちゃん！(Hatena) - Port801 (初心者向け)セキュリティ勉強会 Hamachiya2編
こんにちはこんにちは！！ 先日、Twitterで声をかけてもらって、 第一回 Port801 セキュリティ勉強会っていうのに参加してきたよ！！ (↑pw: security) そこで、すこし喋った時のビデオを頂いたので、もったいないので公開しちゃいますね！ プレゼンだとかそういうの慣れてなくて、ぐだぐだな感じだけど、 よかったら何かの参考にしたり、晩ご飯のおかずにしてください＞＜ Port801 セキュリティ勉強会 - Hamachiya2 その1 (http編) Port801 セキュリティ勉強会 - Hamachiya2 その2 (CSRF編1) Port801 セキュリティ勉強会 - Hamachiya2 その3 (CSRF編2) Port801 セキュリティ勉強会 - Hamachiya2 その4 (XSS編1) Port801 セキュリティ勉強会 - Hamachiya2 その5
Port801勉強会に参加してきた！ - onkはギリギリ霊長類
Port801 セキュリティ勉強会 に参加してきました！ パスは security．writeboard はパスワード必須なのです（・ω・｀） しかし何スかねぇ，この豪華過ぎる面子． Twitter で声をかけると凄い人ばっかり集まってきますｗ 以下，勉強会中にとったメモ． @youchan 「気を遣うシステムはやりたくない」 「セキュリティに銀の弾丸はない」 「結局一つ一つのことを丁寧に見なければいけない」 「Security はメタプログラミング」 JServ 時代ってホント全然知らないなぁ，と思ったプログラマ3年目の夏． Java3D も触ったことないし，自分の引き出しをもっといっぱい増やしたいなぁ． 出来れば業務で色々やりたい． @Hamachiya2 写真1個しか撮ってなかた……． 「しーさーふ」 「Request を貰ったらなんでもやる」←試験に
Yoshioriの日記: Port801 勉強会で LT しました資料
うまいことただしから流れそうだったので そのまま流れでやりました。 結論から言うとやっぱり生体認証イマイチかな？
Port801セキュリティ勉強会の資料 - nothing but trouble
箇条書きテキストしか用意していなかった。超適当 Webアプリケーションセキュリティ初歩の初歩 〜はまちやの傾向と対策〜 はじめに どうセキュリティに取り組むべきか 脆弱性の殆どは、境界で起きる 基本はバリデーションとエスケープ バリデーション そのシステムで予期しているデータのみ受け入れる エスケープ 出力先に応じて適切な出力を送る 出力先での特殊文字に注意する でも、IEとか バッドノウハウ的に対応せざるを得ないものがある CSSXSS的なのとかContent-Type判別を利用した攻撃とか 当然、自システム内での脆弱性の作り込みには注意する Cなんかでは、Buffer Overflowとか作り込みやすいよね バッドノウハウ/グッドラッパー 金床さんの文章 http://www.jumperz.net/texts/bkgw.htm 脅威のカテゴリ Spoofing(なりすまし/偽装) T
ウェブアプリケーションセキュリティとバッドノウハウ、そしてグッドラッパーの関係
ウェブアプリケーションセキュリティとバッドノウハウ、そしてグッドラッパーの関係 by 金床 ---------------------------------- はじめに ---------------------------------- 筆者はウェブアプリケーション開発者であると同時にセキュリティ技術にも興味がある。自身がSeaSurfers MLというウェブアプリケーションセキュリティをテーマとしたメーリングリストを主催しており、またセキュリティコミュニティに多くの知人、友人がいる。しかし彼らとウェブアプリケーションなどのセキュリティ対策について意見を交換すると、違和感をおぼえることが多い。 彼らは脆弱性の原理についてとても詳しいのだが、以下のような会話が頻繁に発生するのである。 「…つまり原理的に考えて、このようにすればXSSは発生しないんだよ」 「な
Port801セキュリティ勉強会行ってきた。 - 動物と暮らそう
すごく楽しかった！ メモ取るとかそういう次元じゃなかった！ なんでかって、僕には難しかったり、簡単だったり、メモする時間なかったり、楽しすぎてメモするのを忘れてたり(←これが大半)してたから。 みなさんすごいなぁ、すごいなぁ、すごいなぁ。 メモるんじゃない、感じるんだ！ といいつつ、メモったったーことを見ながらだらだら書いてくよ。 youchanさんの問題提起はおもしろかったよ！ hamachiyaさんのmixiとustream使ったCSRF*1の実演だったり、yahoo使ったXSSの実演はしびれました。 改めて実演されると、アプリケーション作る側としては恐怖だね。 ゲームは特定アプリケーションに依存しないで作れる*2ので、バッドノウハウ的に修正とかは無いので、既定ブラウザ依存な現場というのも大変そうでした。 sendさんのフォローもあって、どんな脆弱性があるのか大体掴めた気がします。 j
crossdomain.xml と CSRF 脆弱性について - 2nd life (移転しました)
crossdomain.xml を安易に設置すると CSRF 脆弱性を引き起こす可能性があります。というのも、ここ数が月、それなりの数の crossdomain.xml による CSRF 脆弱性を発見し(現在、それらのサイトでは対策がなされています)、まだまだ Web プログラマに脆弱性を引き起こす可能性がある、という考え方が浸透してないんじゃないか、と思ったので。 先月、Life is beautiful: ウェブサービスAPIにおける『成りすまし問題』に関する一考察にも crossdomain.xml について書かれてたのですが、その後もいくつかのサービスで crossdomain.xml を許可ドメインすべてにしているサービスがあったので、注意喚起としてエントリーに書き起こします。 自分も一年半ぐらい前は、crossdomain.xml を許可ドメインすべて ('*') にして設置し
sawatの日記 - evalの第二引数とGreasemonkeyのunsafeWindowについて
「http://d.hatena.ne.jp/brazil/20070420/1177060289」でFirefox専用の第二引数に環境の指定をとるevalの使い方について説明されています。その元はこちら「http://www.tom.sfc.keio.ac.jp/~sakai/d/?date=20070414#p02」で、僕もこれを見たときに初めてしりました。そのころ僕はグリモンのスクリプトをいじっていたので、ちょっと気になっていくつか試してみて、ネタ元のページに以下のようなブクマコメントをしました。 evalの第2引数しらなかった。これを応用すると、GreasemonkeyでusafeWindow.xxx() とする場合、xxx内部からeval("GM_xmlhttpRequest", arguments.callee.caller)でGM_xmlhttpRequestが取得されてして
Greasemonkey スクリプトは安全ではありません
■ Greasemonkey スクリプトは安全ではありません Webアプリケーションセキュリティフォーラム の奥さんと高木先生のバトルより。 高木先生 ええと、「クッキーが漏洩する程度なので問題ない」と聞こえたような気がしたんですが。 Greasemonkey には超絶便利な GM_xmlhttpRequest があるので、どのウェブサイト上でスクリプトを動かそうが、あらゆるサイトにアクセスする事が可能です。この観点から考えると、クッキーが漏洩するどころの騒ぎではありませんし、スクリプトを有効にするドメインが限られていた所で大した意味はありません。例えば Google Search を便利にするようなスクリプトに、mixi のパスワードを任意の値に変更させるようなトロイを仕込む事も難しくないでしょう(実際に作って試しました*1)。もちろん対象サイト上に、XSS や CSRF の脆弱性がなく
「ファイルの拡張子表示」、実施者は3分の1足らず――IPA調査 － ＠IT
2007/07/10 インターネット利用者の間では「不審な添付ファイルは開かない」「怪しいWebサイトにはアクセスしない」といったセキュリティ対策が浸透してきた一方で、設定変更にひと手間かかる「ファイルの拡張子を表示させる」といった方策はまだ広く実施されていないことが、情報処理推進機構（IPA）の意識調査によって明らかになった。 IPAは7月10日、「情報セキュリティに関する新たな脅威に対する意識調査（2006年度第2回）」の結果を公開した。この調査は3月30日から31日にかけて、15歳以上のインターネット利用者を対象にWeb上で実施したもので、有効回答数は5316件だった。 IPAセキュリティセンター ウイルス・不正アクセス対策グループリーダーの小門寿明氏によると、インターネット上の脅威は「愉快犯で姿を現すものから、金銭を目的とし、陰に潜んで姿を見せないものへと変化してきた。最近PCを利
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Port801 セキュリティ勉強会 - Hamachiya2 その1 (http編)
ライブドアブログ｜無料で豊富な機能が充実
