知らなかったらNGなWEBアプリケーション脆弱性一覧 : mwSoft blog
先日、AmebaなうがCSRFという非常にポピュラーな脆弱性を披露したかと思ったら、ここ数日はセブンネットショッピングでXSSの脆弱性と、ID推測による他ユーザの個人情報閲覧の問題が発生しているという噂が流れています。 ユーザの情報を預かっておきながら、基本的なセキュリティの対策もできていないというのは、銀行に例えるなら、お金を預けようとした時に「お金は預かります。ちゃんと保管します。でも警備はあまりしないので盗まれたらスイマセン」と言われるようなものだと思う。 警備に穴があったというのではなく、まともに警備してませんでした、というのはさすがにありえないことです。 そこで、野良WEBプログラマである私が知っている脆弱性を列挙してみた。 私はプログラマであってセキュリティの専門家ではないです。しかも今年の春辺りからずっと外向けのWEBプログラムは組んでません。 その人間が知っているものを並べ
“セキュアなWebアプリ”に立ちはだかる課題
“セキュアなWebアプリ”に立ちはだかる課題：セキュリティ、そろそろ本音で語らないか（4）（1/3 ページ） SQLインジェクションによる情報漏えい事件がクローズアップされています。対策は簡単なこと……と言われ続けているのですが、なぜWebアプリケーションの脆弱性は無くならないのでしょうか。第4回ではその理由に迫ります（編集部） 私は前職で、Webアプリケーションの脆弱（ぜいじゃく）性による個人情報の漏えいの脅威を広く知ってもらうために実在のサイトの脆弱性を公開する、ということをしていました。最初のレポートが2001年10月で、恐らく日本で最初ではないかと記憶しています。 それから何年もたちましたが、相変わらずWebアプリケーションの脆弱性はなくならず、いまもさまざまな対策ソリューションが発表されています。 Webアプリケーションの脆弱性対策は、おおむね以下のように分類できます。 開発時に
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
高木浩光＠自宅の日記 - Googleドキュメントの「招待メール」の危険
■ Googleドキュメントの「招待メール」の危険 ことの始まり 先々週の話。1月23日に次の記事が出ていた。 『Google Docs』の設定にご用心：知らないうちに書き換えも？, WIRED VISION, 2009年1月23日 この記事の趣旨は、「Googleスプレッドシート」の共有設定の画面の説明文「Let people edit without signing in」が誤解を招くために、誤って、誰にでも閲覧や編集を許す設定にしてしまいかねないという話である。この画面は、日本語表示では図1の表記となっている。 WIRED VISIONの記事の言い分では、「people」が上の招待メール送信先の人々のことを指すように読めて、下の「プライバシー」設定も変更しないといけないように誤解してしまうという。 そもそも、この機能の意図されている動作はどういうものか。私も試しているうちに一時混乱し
楽天のメルマガ個人情報流出問題の犯人を推理する (ラボブログ)
ラボ神部です。 今日、楽天市場のメルマガ登録確認画面から個人情報が流出しているらしいという話が話題になっていますが、流出経路が何とも不可解。そこで、可能性をいくつか挙げてみて、下手な推理をしてみようかと思います。 そもそもの原因は そもそもの原因は、Google のロボットのように、メルマガの本来のセッション所有者以外が、メルマガ登録の画面遷移の跡をたどっているところにあります。 URL で言うと https://emagazine.rakuten.co.jp/ns?act=chg_rmail_delete_conf&k= の act= のあとがコマンド、k= のあとの部分がセッション ID になっているのは明らかです。楽天がどのようなプラットフォームの上で動いているのかわかりませんが、PHP なら php.ini で session.use_trans_sid オプションを ON にする
koress.jp: OpenIDの襲来に備えよ！
追記: OpenID対応サービスまとめを作りました。 たぶん、2008年のインターネット（Webサービス)業界はOpenIDによるWebサービスのID体系の統一の荒波に揉まれることになると思う。日本のサービスプロバイダは、OpenIDの襲来に備えるべき。 海の向こうではすでにDigg, Wikipedia, Yahoo, Microsoftなどが導入や支持を発表しているほか、多くの小さなネットサービスはOpenIDに頼ったアーリーアダプタの取り込みに積極的になってる。日本国内ではどうかと言えば、niftyのaboutmeなどを除いて大手のWebサービスは未だ様子を見ている状態。リサーチレベルでは重要性が把握されつつある一方、経営レベルでは「なにそれ」的な状態が多そう。いかん、いかんよ。 2008年、YahooかAmazonかGoogleかわからないけれど、ほぼ間違いなくどこかの日本の大手の
『携帯電話の「簡単ログイン」は個体識別番号を使ってこんなふうに作れます』
たいていのWEBアプリはユーザ名とパスワードを聞かれて認証を行います。これはちょうど家に鍵をかけるようなもの。それほど重要でない情報のみのサイトならこれで十分ですが、貴重な情報があるとなるとそうはいきません。 この物騒な世の中、鍵ひとつじゃ安心できないわという声も聞こえてきます。最近セキュリティの高いところでは、やれ指紋やら静脈やら虹彩やらで個人を識別して鍵が開くようになってきていますね。WEBアプリにもユーザ名とパスワードの鍵以外に、端末の識別番号を使って認証する方法があります。 さて今日は携帯電話に焦点を当てて、ユーザ名とパスワード＋自分の携帯からしかアクセスできないというように変える方法をご紹介。 携帯端末には一台一台に電話番号とは別の個体識別番号があります。この番号を、ユーザがサイトにアクセスしてきたときにプログラムで取得することができます。個体識別番号をサーバ側に保存しておき、認
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなフォトライフAtomAPI