スマートフォンアプリケーションでSSLを使わないのは脆弱性か
このエントリでは、スマートフォンアプリケーションの通信暗号化の必要性について議論します。 はじめに 先日、スマートフォンアプリケーションのセキュリティに関するセミナーを聴講しました（2月8日追記。講演者からの依頼によりセミナーのサイトへのリンクをもうけました）。この際に、スマートフォンアプリケーションの脅威に対する共通認識がまだないという課題を改めて感じました。その課題を痛感できたという点で、セミナーは私にとっては有益でした。 このため、当ブログではスマートフォンアプリケーションの話題をあまり取り上げていませんでしたが、今後は、とりあげようと思います。まずは、スマートフォンアプリケーションでは暗号化を必須とするべきかという話題です。この話題は、前記セミナーでもとりあげられていました。 暗号化の目的は何か まず、暗号化の必要性を論じるためには、暗号化の目的を明確にする必要があります。前記セミ
KDDIの新GWで「かんたんログイン」なりすましの危険性あり直ちに対策された
au/KDDIの2011年秋冬モデル（現時点ではF001のみ）にてEZwebとPCサイトビューア（以下PCSV）のゲートウェイが統合されたことに伴い、かんたんログインを実装しているサイトに対して、F001のPCSVからJavaScriptを用いた「なりすまし」攻撃ができる状態でした。この問題をKDDIに通報したところ、直ちに対策が取られ、現在は安全な状態です。以下、詳しく報告します。 目次概要 経緯 何が問題か 経緯説明(1)基本的なチェックは対処済みだった 経緯説明(2)ハイフンをアンダースコアに変えるトリックは対策済み 経緯説明(3)海老原氏が発見したトリックとは 経緯説明(4)KDDIに連絡→翌日に対処 実証例 外部からJavaScriptを実行できる条件 影響を受けるサイトの条件 影響 対策 今回の問題は、端末あるいはau設備の脆弱性なのか まとめ 概要以前、「EZwebの2011
htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月30日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の第三パラメータ（文字エンコーディング指定）により、どこまで文字エンコーディングの妥当性チェックをしているかを報告します。 2007年4月に、寺田氏(id:teracc)の素晴らしいエントリ「htmlspecialcharsと不正な文字の話」により、htmlspecialcharsは、第三パラメータの文字コードを実質的に無視しており、不正な文字エンコーディングが指定された場合、その文字はチェックされずにすり抜けてしまうという結果が報告されています。
ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
