この記事は以下へ移動しました。 →Macを見たら、[F9]キーとか[F12]キーを押してみろ!(https://ima.hatenablog.jp/entry/20070224/maccm)
Click 'MORE' Please n Read... This is Xgl/Compiz(now known as Beryl Project) running on my secondary comp which is an old (2002) dell with 2.4 ghz P4 proc, Nvidia 6600 GT gfx card, and only 512 megs of RAM. The music is Sidology Ep 2: Trinity, By Machinae Supremacy. This Linux install was SuSE 10.1 and I now use Sabayon Linux. Which you can get here: http://www.sabayonlinux.org Three ver
報告したものは基本的に、脆弱性がありそうだな…と思い、怪しい場所をチェックをしてやっぱり見つかったりするので報告するという感じ。 でも、その理由をそのままIPAに報告すると「脆弱性を探すのはやめなさい」といった旨の返事がくる。 へぇ、そんなことがあるものなのですね。 まあ、情報セキュリティ早期警戒パートナーシップは、基本的には「うっかり見つけちゃった」ものを報告するところであって、発見することを推奨してはいないと思います。もし積極的に探しに行くことが推奨されて、インセンティブが与えられたりすると、届出件数は爆発的に増えるでしょう。その気になれば、「ググっても仕方ない~」とか歌いながら毎日2桁ペースで発見できそうな気がしますので。
巡回サイトの一つである高木浩光@自宅の日記で以下のようなエントリーがあった。 高木浩光@自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか ここではいつもの高木氏の口調で、「携帯向けWEBアプリ開発では未だにGETパラメータでセッションIDを渡しており、それはこれまでも何度もいかんことだと言っている。」というような内容が語られている。 確かにWEB+DBの記事に対して高木氏が注釈で言っているように「IPアドレスによる制限に関して書いていない」という点に関してはWEB+DB側の落ち度だと思う。実際これを行わない限り端末IDやユーザID*1による認証が意味をなさなくなってしまうからだ。*2 但し、キャリア毎にIPアドレス制限をする限りにおいては端末IDやユーザIDは偽装不可能*3なので、むしろ他人でも入力可能なパスワード認証よりも強力な認証かもしれません。逆にいえばその認
高木先生のご指摘はもっともな面があるものの、一部でヒステリックな反応があるので、言及をする。 NTT DoCoMoの端末はCookieを利用できない。そこで、セッションを引き継ぐために、セッションIDをURLに含める必要がある。ただし、端末はHTTP_REFERERを送信しないので、セッションIDが端末の参照元情報から漏れる心配はない。 一方、AU・SoftbankはCookieを利用できるので、セッションIDをURLに含める必要はない。 全キャリア対応のためと称して、セッションIDをURLに含めると、セッションハイジャックの危険性がうまれる。ただし、フレームワークでそのセッションIDをURLへ埋め込むかどうかを切り替えれば済む話なので、対応が難しいというわけではない。 さらに、携帯電話向けのサービスでは、キャリアの指定するIPアドレスの範囲以外からのアクセスを制限することが一般的になって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く