タグ

ブックマーク / tumblr.tokumaru.org (13)

  • 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) する人は実に多いのですが、これははっきりと間違いだと断言します @ITPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http

    PHP5.3.2以降ではfcloseで自動的にアンロックされない
  • データベースのデータを信用してはいけないか?

    ネットを見ていたら「問題集 : PHP技術者認定・初級」というのを見つけました。 【セキュリティ対策】 セキュリティ対策について、正しいものを1つ次の記述の中から選択せよ。 入力のフィルタリングのみ行う。出力のエスケープのみ行う。少なくとも、入力のフィルタリングと出力のエスケープを行う。データベースのデータは信頼してよい。ITトレメ PHP技術者認定・初級 - @IT自分戦略研究所より引用 過去問なのか練習用の想定問題なのかわかりませんが、「問題提供: PHP技術者認定機構」とあります。 PHPアプリケーションの問題ですから、Webアプリケーションセキュリティの問題ですね。茫漠とした問題文ですが、実は正答を得るのは難しくありません。選択肢から技術的な中味を抜いてみると下記になります。 ○○のみ行う。○○のみ行う。少なくとも、□□を行う。○○は信頼してよい。このように並べてみると、○○の選択

    データベースのデータを信用してはいけないか?
  • 勝手に査読:Webアプリにおける11の脆弱性の常識と対策

    「Webアプリにおける11の脆弱性の常識と対策」という記事を久しぶりに読みました。出た当事も思いましたが、基的な誤りが多く、読者が誤解しそうです。このため、編集部から頼まれたわけではありませんが、「勝手に査読」してみようと思います。 細かい点に突っ込んでいくとキリがないので、大きな問題のみ指摘したいと思います。 ※2013年2月25日追記 このエントリに対して、編集部が元記事を修正くださいました。徳丸も修正に協力いたしましたが、十分正確な内容ではないことをお含みおきください。 ※追記終わり 同記事の想定読者は誰か査読にあたり、この記事の想定読者を明確にしておいた方がよいですね。記事の冒頭には、連載の説明があります。 連載は、JSP/サーブレット+StrutsのWebアプリケーション開発を通じて、Java言語以外(PHPASP.NETRuby on Railsなど)の開発にも通用する

    勝手に査読:Webアプリにおける11の脆弱性の常識と対策
  • CookieにログインIDを保存してはいけない

    phpproのQ&A掲示板で下記の質問を読みました。 ログインの際に、クッキーにログイン情報を保存し、ログアウトの際には、フォームタグの中でPOSTでログアウトの為の値を飛ばし、値を受け取ったらクッキーの有効期限をマイナスにしてクッキー情報を消すというログアウト処理を作っています。 同一ページでのCookieでのログアウト処理より引用 クッキーにそのままログイン情報を保持するのはよくありませんね。質問を更に読むと、以下のソースがあります。 setcookie("logid",$row["f_customer_logid"],time()+60*60*24); setcookie("point",$row["f_customer_point"],time()+60*60*24);どうも、SQL呼び出しの結果からログインIDを取り出し、それをそのままCookieにセットすることで、ログイン状態

    CookieにログインIDを保存してはいけない
  • Webアプリの脆弱性を検出するツールはありますか?

    MSDNフォーラムで表記の質問を見かけました。同フォーラムの活動実績がないせいか、回答にリンクを貼ると拒否されましたので、こちらに回答します。 ここからが質問なのですが、プログラムの実装が完了したあと、脆弱性が潜んでいないかをチェックする必要があるのですが、脆弱性を検出するツールなどがありましたら教えてください。できれば、無償で使える物で、環境にあまり依存しないもの(Windows Serverのバージョンや、DBMSの種類に依存しないもの)がよいです。 Webアプリの脆弱性を検出するツールはありますか? 以下、回答です。 ご要望の条件をすべて満たすツールは、おそらくないと思います。 少し古いエントリになりますが、以下のブログにWebアプリケーションの脆弱性を調べるツールがまとめられています。 サーバ/Webアプリケーション脆弱性チェックツールの個人的まとめ(フリー/有償) 良い物は高価、

    Webアプリの脆弱性を検出するツールはありますか?
  • パスワードの定期的変更に関する徳丸の意見まとめ

    パスワードを定期的変更するべきか否かについては、ほぼ「定期的に」意見を書いています。最近は、twitter上のつぶやき等を見ていても、「パスワードを定期的に変更する必要はない」とか、「パスワードを定期的に変更すべき状況は限られている」などの意見を見ることが多いようです。しかし、さまざまなガイドライン類は、依然としてパスワードの定期的変更を要求しているため、私としては継続的に(定期的にw)この問題を取り上げたいと考えています。 最近、パスワードの定期的変更問題に関する優れたコラムを読みました。 多くの組織がユーザーにパスワードの変更を強制しています。長い間、それがセキュリティーの「ベストプラクティス」だと考えられてきたからです。しかし、実際には賛否両論のテーマなのです。以下にパスワードの変更が「有効であるケース」と「有効でないケース」について解説します。 実際、パスワードはどれくらいの頻度で

    パスワードの定期的変更に関する徳丸の意見まとめ
  • セッションアダプションに対する私の見解

    先にエントリ「セッションアダプションがなくてもセッションフィクセイション攻撃は可能」に対して、大垣(@yohgaki)さんから、「セッションフィクセイションはアダプション脆弱性修正で防御可能」というブログエントリで反論をいただきました。 大垣さんのエントリは長いのですが、反論のポイントは、以下の2点だと思いました。 徳丸のPoC(概念実証コード)では、セッションDBが分かれていないが、現実のレンタルサーバー等はセッションDBが分かれているので、攻撃はできないセッションには有効期間があり、セッションアダプションがない場合は、有効期間の過ぎたセッションIDが送信されても、セッションIDは再生成される。だから攻撃はできない以下、上記に反論します。 セッションDBは元々関係ないセッションフィクセイション攻撃において、セッションを扱うのは、攻撃対象のサーバーだけです。大垣さんは、セッションフィクセイ

    セッションアダプションに対する私の見解
  • PHPのセッションアダプションは今でもある

    今年もアドベントカレンダーの季節となりました。既に楽しい記事が多数紹介されています。僕も、今年は初めてアドベントカレンダーに参加しようと思い、PHP Advent Calendar 2012にエントリしています。 去年のPHP Advent Calendar jp 2011にはどんなネタが上がっていたかと思いタイトル一覧を見ておりましたら、見覚えのあるエントリがありました。 PHPのセッションアダプション脆弱性克服への道のり セッションアダプション対策はまだリリースされているPHPには取り込まれていませんが、もうすぐsubversionレポジトリにコミットする事ができます。 ・・・ 2011年秋 PHP 5.4.0のリリースに合わせ厳格なセッション管理を行わない事はセキュリティ問題だとPHP開発者のMLに送信する。遂にセッションアダプションの致命性が理解されたのか、今までと違い必要ない、無

    PHPのセッションアダプションは今でもある
  • 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) する人は実に多いのですが、これははっきりと間違いだと断言します @ITPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http

    PHP5.3.2以降ではfcloseで自動的にアンロックされない
  • Gmailの成りすまし事件、傾向と対策

    池田信夫氏のGmailアカウントがハックされて、寸借詐欺メールが送信されたようです。 Gmailの振り込め詐欺にご注意池田信夫、自らのメールアカウントを乗っ取られ今日も見事な醜態を晒す私の周囲でも、知人が同種の被害にあっていますので、他人事ではない気がします。池田氏が被害にあった原因は不明のようですが、このエントリではその原因を予想(妄想)し、対策について検討します。 池田氏の主張:twitter連携アプリからの漏洩池田氏は自らのブログエントリで以下のように主張しています。 Gmailのパスワードを知らせたことはないのですが、ツイッターと共通にしていたため、「連携アプリ」を認証するときパスワードを入力します。これはシステム側に通知されないことになっていますが、悪意をもって偽装することは容易です。かなりあやしげなアプリも含めて20ぐらい使っていたので、そこから推測してGmailにログインされ

    Gmailの成りすまし事件、傾向と対策
  • hostsファイルにループバックアドレスを指定することは危険か?

    Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ(ルート化必要)が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事

    hostsファイルにループバックアドレスを指定することは危険か?
  • TポイントツールバーのWEB閲覧履歴を開示請求した

    Tポイントツールバーが収集したWEB閲覧履歴の開示請求ができることを8月19日(日)知りました。届出書は以下からダウンロードできます。 (A)『個人情報保護法に基づく請求』に用いる届出書 Ⅳ(開示請求:TポイントツールバーWEB閲覧履歴専用) これに記入(Tカード番号、住所、氏名などの個人情報)して、人確認書類のコピーを添えて簡易書留で郵送すれば、開示されると理解しました。料金は不要です。一方、削除請求というのもありますが、8月31日(金)付けで削除されたということなので、現時点でこれを使う機会はなさそうです。 私は、Tポイントツールバーを導入してWEB閲覧をしていましたので、開示請求をして、どのような形で閲覧履歴が開示されるかを見てみたいと思いました。幸い、以下のように試すのは容易なようでした。 必要事項を書くだけで事務的に開示されるようで請求側の心理的負担が少ない例えば、開示理由を書

    TポイントツールバーのWEB閲覧履歴を開示請求した
  • 武雄市では市職員が現職市長の当選を後押ししているらしい

    以下は、武雄市長 樋渡啓祐氏のツイート(引用) デタラメ。そんな組織はあり得ない。まさにこの人はいつもの机上の空論。そして、もしそうだとしたら、三回も選挙通らんよ。こういう田舎だと職員はかなり力を持つからね。 RT @ockeghem うがった見方をすると(cont) tl.gd/itre1a 8月 19, 2012これを素直に読むと、武雄市長は市職員と良好な関係を保っており、市職員の協力によって三回選挙に当選した、と言いたいらしい。 だが、地方公務員法では、地方公共団体職員の選挙運動を禁止している。 第三十六条  【略】 2  職員は、特定の政党その他の政治的団体又は特定の内閣若しくは地方公共団体の執行機関を支持し、又はこれに反対する目的をもつて、あるいは公の選挙又は投票において特定の人又は事件を支持し、又はこれに反対する目的をもつて、次に掲げる政治的行為をしてはならない。【略】 一  

    武雄市では市職員が現職市長の当選を後押ししているらしい
  • 1