iPhone(iOS)のWi-Fi機能無効化バグ
(Last Updated On: 2021年6月29日) Gigagineで比較的珍しいバグが見つかったことを記事にしています。 「％p％s％s％s％s％n」というSSIDのネットワークに接続すると、iPhoneのすべてのWi-Fi関連機能が無効になってしまう https://gigazine.net/news/20210620-specific-network-name-disable-wi-fi-iphone/ 「セキュリティって難しいんだな」と感じるニュースではなく「大手でも基本が出来てないんだな」と思えれば、似たような問題で困ることが無くなります。 問題の原因 問題の原因は引用記事の予想通りだと思います。フォーマット文字列を使ったデータ出力関数の出力処理が問題のはずです。 上記のようなフォーマット文字列を使ったAPIを使用する箇所で「エスケープ無し文字列」、記事の問題の場合はSS
遅すぎるサニタイズではダメな例 – yohgaki's blog
(Last Updated On: 2018年11月5日) PostgreSQL 11がリリースされました。このリリースでto_number()、to_char()、to_date()、to_timestamp()関数の仕様が変更されました。これらは名前の通り入力を変換する関数です。その際に サニタイズ – ダメな形式のデータを使える／安全なデータ形式に変換する を行います。保存されるデータ形式は、保存可能な形に変換されます。しかし、これは十分ではないです。遅すぎるサニタイズがダメな例として紹介します。 ※ エスケープやプリペアードクエリもサニタイズ（無害化）の一種です。 PostgreSQLのto_number()仕様 to_number()関数は高機能で色々な変換が可能です。全てを紹介しきれないのでカンマで千桁を区切るケースだけ紹介します。 to_number()の仕様： 1番目の引数
ドイツ人と入力バリデーションについて議論した話
(Last Updated On: 2019年2月7日)メールアドレスから恐らくドイツ人だと思われる開発者とWebアプリ（サーバー側）の入力バリデーションについて議論した内容を簡単に紹介します。 どこかでした議論と同じでデジャブー感ですが、これから書くような感じの内容でした。議論相手のドイツ人の言葉がくだけた感じに書いていますが、「自分の考え方は完璧、私の考え方はとんでもない非常識」と思っていたらしく、お世辞にも丁寧な書き方のメールではありませんでした。この為、くだけた感じで書いています。 とんでもない勘違いをしているのに自信満々の人は手に負えない、と感じる人が多いと思います。私の場合、こういう人でもどういう論理とポイントで議論すれば良いのか？参考になるので楽しんで議論しています。 議論の概要 私「入力バリデーションはアプリケーションの一番外側の信頼境界でするべきモノですよ」 彼「そんなア
PHPの危い関数リスト
(Last Updated On: 2019年2月2日)一応、PHPの危い関数リスト、は存在します。例えば、以下のような物があります。 StackOverflow DangerousPHPFunction 後者は主にホスティング環境（？）でリスクがある関数の一覧を作るプログラムのようです。 ファイルを操作する関数、コマンドやスクリプトを実行する関数などのリスクは自明だと思います。少し趣向を変え、間違えて使うと危い関数の一覧を独断と偏見で作ってみました。 【重要】こういった「危険な物」を定義するのはブラックリストです。ブラックリストは仕組的に危険です。ブラックリストに頼るのは脆弱性を作るような物です。ブラックリスト”だけ”で安心しないでください。最後にどうすれば良いのか？を書きます。 hash_hkdf() hash_hkdf()は秘密鍵から実際に利用する鍵を導出する関数です。鍵を作る関数な
覚えるパスワードの作り方
(Last Updated On: 2018年10月1日)覚えなくて構わないパスワード（ブラウザなどのパスワードマネージャーに記憶させる最強のパスワード）の作り方は、 覚えないパスワードは生成する物 〜 余計な文字数制限などは有害 〜 で紹介しました。最強のパスワードを自分で作るのが面倒な方はこのページのランダム文字列から90文字くらいをコピー＆ペーストして使ってください。 今回は覚えられる最強のパスワードの作り方です。 備考：あるニュース記事で”ブラウザのパスワード機能は使わない”とする記事がありました。その理由は、離席した場合などにパスワードが表示できる物もあるから、でした。しかし、PCをログインしたままロックもせずに離席すると、ログイン済みならアクセス仕放題、サードパーティー製のパスワードマネージャーを使っていても利用するサービスにはログイン仕放題、です。デバイスの物理セキュリティは
本当にプリペアードクエリだけを使っていますか？
(Last Updated On: 2019年2月18日)'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col']) SQLクエリにはプリペアードクエリを使いましょう！と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。 多くの場合、速い SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい 特に初心者は「ついうっかり」が多い しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか？コードを見れば分かります。 何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけ
正規表現でのメールアドレスチェックは見直すべき – ReDoS
(Last Updated On: 2018年8月13日)前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。 結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー） 追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイト
正規表現を使ったDoS – ReDoS
(Last Updated On: 2018年8月8日)いつかは忘れるくらい前に正規表現のアルゴリズム自体を利用してDoS攻撃を行うReDoSが発表されていました。今まであまり気にしていなかったのですが、検索しても日本語のページが出てこないようでした。詳しく知るためのリンクなどを紹介します。 少し検索して出て来た日本語ページはHPのページでしたが、たまたまインデックスされていたページがヒットしたようでした。また記載されている情報は不十分でした。（ページ下のコピーライトからFortifyの情報のようです） 日本語のページで良いものは無いようなので、ReDoSの英語ページ／PDFを紹介します。 Wikipedia OWASP CHECKMARX 2015 (PDF) CHECKMARX 2009 (PDF) 3つ目のCHECKMARXのPDFは解りやすいと思います。OWASPのページはCHE
yohgaki's blog - 画像ファイルにJavaScriptを隠す
(Last Updated On: 2014年12月5日)前回のエントリでイメージファイルにスクリプトを埋め込んで攻撃する方法について記載しましたが、最近イメージファイルにスクリプトを埋め込む事例が話題になったためか ha.ckersにJavaScriptをイメージファイルに隠す方法が紹介されています。 http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/ <script src="http://cracked.example.com/cracked.gif"> などとXSS攻撃を拡張する手段に利用可能です。サンプルとしてFlickerにJavaScriptを埋め込んだイメージファイルがアップされています。 このイメージファイルは上手く細工しているので画像としても表示され、JavaScriptも実行できます。 Flicke
2要素認証のTOTPとHOTP、どちらがより安全か？
(Last Updated On: 2018年8月18日)今すぐできる、Webサイトへの2要素認証導入では簡単に2要素認証が導入できること、2要素認証には 時間ベースのOTP（TOTP：Time-based One Time Password RFC 6238) カウンターベースのOTP（HOTP：HMAC-based One-Time Password RFC 4226） があることを紹介しました。Google認証は両方をサポートしています。※ ※ 今すぐできる、Webサイトへの2要素認証導入で紹介したライブラリはTOTPのみサポートしています。 TOTP、HOTPのどちらを導入してもユーザー名とパスワードのみによる認証に比べ、より高いアカウント（認証）の安全性を維持することができます。しかし、TOTPはHOTPに比べ以下の理由で脆弱です。 TOTPは特定の時間内なら何度でも利用できる（
OTP（ワンタイムパスワード、2要素認証）とタイミング攻撃
(Last Updated On: 2018年8月18日)今すぐできる、Webサイトへの2要素認証導入と2要素認証のTOTPとHOTP、どちらがより安全か？で紹介したGoogleAuthenticatorですが、ソースコードを確認ところタイミング攻撃に脆弱でした。Pull Requestを後で送る予定ですが、利用される場合は脆弱性を修正してから使ってください。 タイミング攻撃とは？ タイミング攻撃とは、発熱、ノイズ、時間差、データサイズ（特に圧縮）などの副作用を用いたサイドサイチャネル攻撃の一種です。アルゴリズムなどの脆弱性を直接攻撃するのではなく、時間差などを統計的に処理することにより目的を達成（攻撃）することができます。 タイミング攻撃ではレスポンス時間の微妙な長さの違いを統計的に処理し、目的の秘密情報を盗み取ります。OTPでは数字しか使っておらず、桁数も6桁しかありません。脆弱な場合
PHP7の現状
(Last Updated On: 2018年8月13日)PHP7が今年の秋リリースされる予定です。まだまだ多くの変更が行われる予定ですが、現状を簡単にまとめてみたいと思います。代表的な物のみ取り上げています。 ご存知ない方の為に書いておきます。現在リリースされているPHPはPHP5です。次のPHPはPHP7になり、PHP6はリリースされません。PHP6をUnicodeをネイティブ文字列としてサポートするバージョンとして開発されましたが、文字エンコーディングチェックを内部で自動的に行おうとするなど、無駄が多く遅いため破棄されました。（文字エンコーディングのバリデーションは本来アプリでするものです）このため、PHP6はスキップされ次のPHPはPHP7になります。 追記：PHP7.0は既にリリースされています。概要はPHP 7.0の概要・新機能・互換性、詳しくはマイグレーションドキュメントをご
PHPer向け、Ruby/Railsの落とし穴
(Last Updated On: 2018年8月13日)Railsアプリケーションを作る機会も多くなったと思います。今までPHPのみを使ってきた方の為に、開発者がよく落ちてしまうRails/Rubyの落とし穴を少しだけ紹介します。RailsからWebアプリをはじめる方にも役立つと思います。 to_iやto_fは型変換ではない 私のブログ読者はPHP開発者の方が多いと思うので基本的なところから紹介します。RubyはPHPよりデータ型に厳格です。例えば、””（空文字列）や0は偽（false）と評価されません。 2.0.0p247 :001 > true == true => true 2.0.0p247 :002 > true == false => false 2.0.0p247 :003 > "" == true => false 2.0.0p247 :004 > "" == false
攻撃者が”嫌う”セキュリティ対策とは何か？
(Last Updated On: 2018年8月8日)「攻撃者が”嫌う”セキュリティ対策＝効果的なセキュリティ対策」です。これに異論は無いと思います。 攻撃者が最も困るセキュリティ対策とは何でしょうか？それは境界防御です。なぜ境界防御が攻撃者が最も困るセキュリティ対策なのでしょうか？それはCWEやCVEを見ればわかります。CWEやCVEに登録されている脆弱性の多くが、境界防御で守れるからです。 境界防御とは？ 境界防御はWebアプリケーション開発者に最も誤解されているセキュリティの基本概念だと思います。これについては先日既に書いています。まだ読まれていない方はぜひ標準と基本概念から学ぶ正しいセキュリティの基礎知識を参照してください！ 攻撃者が最も困る対策は入力バリデーション 入力バリデーションは様々な脆弱性を防止または緩和してくれます。自分が書いた出力コードに脆弱性がある場合でも、利用し
間違いだらけのHTTPセッション管理とその対策
(Last Updated On: 2018年10月12日)HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。 まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。 参考： 知らないと勘違いする「合成の誤謬」の罠 開発者は必修、SANS TOP 25の怪物的なセキュリ
PHPのOpenSSL関数を利用して暗号化する例
(Last Updated On: 2021年2月15日) 色々やることがあってブログを更新できていませんでした。久々のブログはPHPのOpenSSL関数を使ってAES-256-CBCを使って暗号化する例です。今時のハードウェアとソフトウェアならハードウェアAESが利用できるので普通はAES-256-CBCで構わないでしょう。 ”パスワード”だけで暗号化する例 暗号を利用する場合のポイントは以下の通りです。 IV（Initialization Vector ソースでは$iv）にはランダムな「バイト」を利用する。IVに16進数のハッシュ「テキスト」を使うと折角のIVの空間を半分にしてしまいます。IVには毎回ランダムバイトを設定する。鍵（$key）には「バイト」を利用する。IVと同様にハッシュ「テキスト」などを使うと鍵空間が半分になってしまう。人に256ビットの鍵を要求するのは非現実的なので、
IPAの「安全なSQLの呼び出し方」が安全になっていた
(Last Updated On: 2018年8月4日)IPAは「安全なSQLの呼び出し方」（PDF）を以下のURLから公開しています。 http://www.ipa.go.jp/security/vuln/websecurity.html 「安全なSQLの呼び出し方」は危険である、とするエントリを書こうかと思い、内容を確認するとそうでもありませんでした。 訂正：ツイッターで徳丸氏に確認したところ、徳丸氏もエスケープを含めたSQLインジェクション対策が必要であると考えられていた、ことを確認しました。徳丸氏にはセキュリティ専門家として大変不名誉な記述であった事を訂正し、深くお詫びいたします。内容についての修正は、識別子エスケープについてブログに書くとの事でしたのでブログの内容を確認してから修正します。 別冊の「安全なSQLの呼び出し方」は基本中の基本である「正確なテキストの組み立て」によるセ
SSLでの圧縮の利用は禁止
(Last Updated On: 2018年8月8日)他人のブログのコメントに書いて、自分のブログに書かないのも良くないので一応ここにも書いておきます。 「SSLでの圧縮の利用は禁止した方が安全」です。 なんだか禁止シリーズのようになっていますが、「SSLでの圧縮の利用は禁止」です。 SSLによる暗号化を無効にするBEASTやCRIMEという攻撃手法を聞いたことがある方も多いと思います。BEASTもCRIMEも、その手法が開発される以前に発表された圧縮を利用したサイドチャネル攻撃の実装例だと言えます。新しいツールも開発されています。 この種の攻撃を防御するには圧縮を無効にします。SSL圧縮、HTTP圧縮、圧縮すべてを無効にします。（最近のクライアントはSSL圧縮を無効にしています） RSAのブログでも以下のように「BREACHツールは1分以内に解読する」と警告しています。 Secure
JavaScript文字列のエスケープを回避する方法
(Last Updated On: 2018年8月13日)JavaScriptの文字列をエスケープのエントリでJavaScript文字列をエスケープ後に直接出力するより、DOMから取得してはどうか？という提案があったのでエントリを作成しました。 まずJavaScript文字列をJavaScript文字列のエスケープで作成したescape_javascript_string関数を利用した場合の例です。 <span onmouseover="alert('<?php echo escape_javascript_string('Hello From <php>')?>');">マウスをのせてね！</span> JavaScriptでDOMの要素から取得する場合、以下のようになります。要素の取得にはjQueryを利用しています。 <script src="//ajax.googleapis.co
セッションID管理は結局どうすれば良いのか？
(Last Updated On: 2018年8月18日)脆弱性やセキュリティ対策について技術的な話ばかりしていたので「それで結局PHPのセッション管理どうすれば良いの？」と思われた方も多いと思います。簡単にまとめます。漏れや追記した方が良い事などがあったらご指摘ください。 session_regenerate_id()の使い方（セッションID再生成） ログイン処理時・ログアウト処理には最初にsession_regenerate_idを呼ぶ。 定期的にsession_regenerate_idを呼ぶ。間隔が短いほど低リスク。 session_regenerate_idはtrueオプション（古いセッションデータ削除）を付ける。 session_regenerate_idでtrueオプションは付けない。その代わりに再生成した時点のタイムスタンプを古いセッションデータに記録し、数分後からそのセッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
