タグ

ブックマーク / blog.ohgaki.net (5)

  • SSL Hell

    (Last Updated On: 2007年2月14日)10月30日作成のページですが今みました。 Dan Kaminsky’s SSL Hell 結構笑えます。(英語のプレゼンテーションビデオです) これではどのサイトも信用できないです。 追記: ビデオの見なくても良いように一番重要な点だけ書きます。 SSLの公開鍵・秘密鍵がデフォルトのまま使っているサイトが多くある、というくだりです。銀行などのサイトでも「ありえない」と思える割合のサイトがデフォルトのキーペアを使っていて暗号化の意味がなくなっている!!!のだそうです。(詳しくはビデオを参照) キーはサイト毎に生成するになぜこんな事が起きる?と思われる方もいるかもしれません。ハードウェア系のSSLソリューションには静的に生成されたデフォルトのキーペアが設定されている場合があるのですが、なんとそのキーを使っているサイトが多数存在する、と

    SSL Hell
    akahigeg
    akahigeg 2007/02/15
    これはいくらなんでもひどいな
  • yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須

    (Last Updated On: 2016年3月3日)最近PostgreSQLMySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考:セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQLMySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト~6バイト必要なのか

    yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須
  • まちがった自動ログイン処理

    (Last Updated On: 2018年8月20日)問題:まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考:自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保

    まちがった自動ログイン処理
  • yohgaki's blog - addslashesによるエスケープ処理は止めましょう

    (Last Updated On: 2018年8月13日)追記:PHPエスケープ関連の検索でこのエントリを参照されたと思います。PHPでのエスケープ全般については以下のエントリを参照してください。 PHP文字列のエスケープ セキュリティmemoにaddslashesよるエスケープ処理でSQLインジェクションが可能なるという記事を見つけました。 私のセミナーを聞いたことがある方は「addslashesによるエスケープ処理は止めましょう」と言っていた事を覚えているでしょうか? mysql_real_escape_string()やpg_escape_string()等のデータベース専用のエスケープ関数を使いましょう、とも話しています。 ちなみにSQLiteを使っている場合はaddslashesでエスケープ処理はNGです。もっと根的に間違っています。SQLiteではMS SQL Server,

    yohgaki's blog - addslashesによるエスケープ処理は止めましょう
  • PHPのSession Fixation問題

    (Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化(Session Fixation)に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です

    PHPのSession Fixation問題
  • 1