2014-11-09 警察からの問い合わせ電話にこたえるにあたって51社会 警察からの照会電話がたびたびかかってくる職場で働いていたことがある。 警察からの照会だからこたえることが許される、あるいはこたえなければならない照会が多かったのだが、必ず守らなければならないルールがあった。 それは、その電話ではこたえず、一旦、電話を切ることだった。その後、ネットなりで警察本部や警察署の代表番号を調べて、回答の電話をかけるのだ。それはもちろん、警察をかたる電話を警戒してのことだが、この警察からの問
2014-11-09 警察からの問い合わせ電話にこたえるにあたって51社会 警察からの照会電話がたびたびかかってくる職場で働いていたことがある。 警察からの照会だからこたえることが許される、あるいはこたえなければならない照会が多かったのだが、必ず守らなければならないルールがあった。 それは、その電話ではこたえず、一旦、電話を切ることだった。その後、ネットなりで警察本部や警察署の代表番号を調べて、回答の電話をかけるのだ。それはもちろん、警察をかたる電話を警戒してのことだが、この警察からの問い合わせへの回答ルールには続きがあった。 問い合わせ電話の担当を把握していても、その人物を電話口に呼び出さず、「こういう照会があったのですが、担当者を失念しました。問い合わせされたのはどなたですか」というのだ。これは、照会者が真正な警察官であっても、公務でない照会をしていることを恐れるためだ。乱暴な要約をす
パスワードの定期的変更に関する徳丸の意見まとめ
パスワードを定期的変更するべきか否かについては、ほぼ「定期的に」意見を書いています。最近は、twitter上のつぶやき等を見ていても、「パスワードを定期的に変更する必要はない」とか、「パスワードを定期的に変更すべき状況は限られている」などの意見を見ることが多いようです。しかし、さまざまなガイドライン類は、依然としてパスワードの定期的変更を要求しているため、私としては継続的に（定期的にw）この問題を取り上げたいと考えています。 最近、パスワードの定期的変更問題に関する優れたコラムを読みました。 多くの組織がユーザーにパスワードの変更を強制しています。長い間、それがセキュリティーの「ベストプラクティス」だと考えられてきたからです。しかし、実際には賛否両論のテーマなのです。以下にパスワードの変更が「有効であるケース」と「有効でないケース」について解説します。 実際、パスワードはどれくらいの頻度で
データベースのデータを信用してはいけないか?
ネットを見ていたら「問題集 ： PHP技術者認定・初級」というのを見つけました。 【セキュリティ対策】 セキュリティ対策について、正しいものを1つ次の記述の中から選択せよ。 入力のフィルタリングのみ行う。出力のエスケープのみ行う。少なくとも、入力のフィルタリングと出力のエスケープを行う。データベースのデータは信頼してよい。ITトレメ PHP技術者認定・初級 － ＠IT自分戦略研究所より引用 過去問なのか練習用の想定問題なのかわかりませんが、「問題提供： PHP技術者認定機構」とあります。 PHPアプリケーションの問題ですから、Webアプリケーションセキュリティの問題ですね。茫漠とした問題文ですが、実は正答を得るのは難しくありません。選択肢から技術的な中味を抜いてみると下記になります。 ○○のみ行う。○○のみ行う。少なくとも、□□を行う。○○は信頼してよい。このように並べてみると、○○の選択
「ノーガードのPCをネット接続すると4分でボットに感染」を懐かしむ
ネットの記事を読んでいたら、セキュリティ対策していないPCをインターネットに接続すると平均4分で不正プログラムに感染すると書いてありました。どこかで読んだ記憶があるなと、古い記事を調べましたので、皆様の参考のために共有します。 当該の記事には、以下の記述がありました。 ノーガードなら平均4分……国内の複数のセキュリティ機関が合同実験をしたところ、何も対策をしなければ、平均して4分で不正プログラムに感染することが分かった。必ずウイルス対策ソフトをインストールし、パターンファイルを最新にしてからネットサーフィンしていただきたい。 “迷探偵”ハギーのテクノロジー裏話：ウイルス対策ソフトの未来を占う (3/3) - ITmedia エンタープライズから引用 「ノーガードなら平均4分」というのは、どこかで読んだ記憶があるなーとfacebookでつぶやいておりましたら、歌代さんとはせがわさんが教えて下
セッションアダプションに対する私の見解
先にエントリ「セッションアダプションがなくてもセッションフィクセイション攻撃は可能」に対して、大垣(@yohgaki)さんから、「セッションフィクセイションはアダプション脆弱性修正で防御可能」というブログエントリで反論をいただきました。 大垣さんのエントリは長いのですが、反論のポイントは、以下の2点だと思いました。 徳丸のPoC（概念実証コード）では、セッションDBが分かれていないが、現実のレンタルサーバー等はセッションDBが分かれているので、攻撃はできないセッションには有効期間があり、セッションアダプションがない場合は、有効期間の過ぎたセッションIDが送信されても、セッションIDは再生成される。だから攻撃はできない以下、上記に反論します。 セッションDBは元々関係ないセッションフィクセイション攻撃において、セッションを扱うのは、攻撃対象のサーバーだけです。大垣さんは、セッションフィクセイ
セッションアダプションがなくてもセッションフィクセイション攻撃は可能
大垣（@yohgaki）さんと、セッションアダプション脆弱性が「重大な脅威」か否かで論争を続けています。 大垣さん:第25回 PHPのアキレス腱 ── セッション管理徳丸:PHPのSession Adoptionは重大な脅威ではない大垣さん:PHPのセッションアダプション脆弱性は修正して当然の脆弱性議論がかみ合わないので、twitterで「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい」とツイートしたところ、大垣さんがブログで返信下さいました。 大垣さん: セッションアダプション脆弱性がないセッション管理が必要な理由これを読んでかみ合わない理由が分かりました。大垣さん、ありがとうございます。以下大垣さんのブログの末尾を引用します。 脱線しましたが、何が改善されるのか？結論は ログイン時に
書式文字列によるSQLインジェクション攻撃例
以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは？ と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ？と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ
PHP5.3.2以降ではfcloseで自動的にアンロックされない
PHPの本家サイトでflockの説明を読んでいたら、以下の変更履歴に気がつきました。 5.3.2 ファイルのリソースハンドルを閉じたときにロックを自動的に解放する機能が削除されました。 ロックの解放は、常に手動で行わなければなりません。 http://php.net/manual/ja/function.flock.php ところがネットの解説を見ると、ロック開放はflock($fp, LOCK_UN); ではなく、fcloseでやれとしている解説が結構あります。 (4)fcloseの前にflock解除するな … fcloseの前にflock(ファイルポインタ, LOCK_UN) する人は実に多いのですが、これははっきりと間違いだと断言します @ITのPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http
「ブラインドSQLインジェクションとは何ですか？」への回答
以下は、Yahoo!知恵袋での下記質問に対する回答です。 ブラインドSQLインジェクションとは何ですか？ できるだけ詳細に教えて下さい 回答した後に、質問が取り消されてしまいました。Yahoo!知恵袋の仕様として、取り消しされた質問は2週間で削除されるため、備忘のため転載します。 ブラインドSQLインジェクションというのは、SQLインジェクション攻撃の一種です。 通常のSQLインジェクション攻撃では、検索結果の文字列が表示されたり、SQLのエラーメッセージが表示される箇所があり、それら表示の一部に、本来とは別のSQL文の検索結果を表示させることで、隠れた情報を表示します。 しかし、SQLインジェクション脆弱性はあるが、表示として検索結果の表示もなく、エラーメッセージにもSQLのエラーが表示されない場合があります。例えば、以下に紹介する例では、指定したメールアドレスが登録済みかどうかのみを返
hostsにループバックアドレスを指定することでリスクが増大するケース
前のエントリhostsファイルにループバックアドレスを指定することは危険か?で、hostsにループバックアドレス（127.0.01）を記述することは危険とは言えないと書いたのですが、その後malaさんとkazuhoさんから、レアケースではあるがリスクの増加はあるよという指摘を受けました。 議論の想定は、Android端末のローカル上にWebアプリケーションが動いており、それに対する攻撃が可能か否かを検討するものです。この状態で、利用者が広告よけを目的としてhostsファイルを修正して、example.comを127.0.0.1に指定しようとしていると仮定します。 まず、malaさんの指摘ですが、Google+に読者限定で投稿されています。このエントリは読めない方が大半なので以下に転載します（転載の許諾はいただいています）。…と思ったらmalaさん自身が見える場所に転載いただいたいました。こ
hostsファイルにループバックアドレスを指定することは危険か?
Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ（ルート化必要）が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostのIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
