2015年03月11日 ニュースリリース 『HASHコンサルティング株式会社』の全発行株式を取得 サイバーセキュリティ分野へも本格的参入 X Facebook 印刷 イー・ガーディアン株式会社（http://www.e-guardian.co.jp/、所在地：東京都港区、代表取締役社長：高谷 康久　以下イー・ガーディアン）はサイバーセキュリティを専門とするHASHコンサルティング株式会社（https://www.hash-c.co.jp/、所在地：東京都品川区、代表取締役社長：徳丸　浩　以下HASHコンサルティング）の全発行株式を取得し、完全子会社化することを決議いたしましたのでお知らせいたします。 本株式の取得により、HASHコンサルティング株式会社が提供する「脆弱性診断サービス」に加え当社の監視センター運営ノウハウや人材を活かしたセキュリティ監視やソフトウェアの販売をセットで提供するこ

8年前の今日、2005年4月19日に有名な「ぼくはまちちゃん！ こんにちはこんにちは!!」がおきました。これを記念して毎年4月19日が『CSRFの日』と定められました（ソースは俺）。8年も経っているのですから知らないなど許されません。みなさま、CSRFについてよく勉強しましょう

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

リンク はてなダイアリー とくまるひろしのSession Fixation攻撃入門 - ockeghem(徳丸浩)の日記 やぁ、みんな，元気？とくまるひろしです。今日はSession Fixation攻撃の方法をこっそり教えちゃうよ。 .. 6

大垣（@yohgaki）さんと、セッションアダプション脆弱性が「重大な脅威」か否かで論争を続けています。 大垣さん:第25回　PHPのアキレス腱 ── セッション管理徳丸:PHPのSession Adoptionは重大な脅威ではない大垣さん:PHPのセッションアダプション脆弱性は修正して当然の脆弱性議論がかみ合わないので、twitterで「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい」とツイートしたところ、大垣さんがブログで返信下さいました。 大垣さん: セッションアダプション脆弱性がないセッション管理が必要な理由これを読んでかみ合わない理由が分かりました。大垣さん、ありがとうございます。以下大垣さんのブログの末尾を引用します。 脱線しましたが、何が改善されるのか？結論は ログイン時に

2. 本日お話しする内容 • 鉄則1: PHP自体の脆弱性対処をしよう • 鉄則2: Ajaxの脆弱性対処をしよう • 鉄則3: 競合条件の脆弱性対処をしよう • 鉄則4: htmlspecialcharsの使い方2012 • 鉄則5: escapashellcmdは使わないこと • 鉄則6: SQLインジェクションの対処 • 鉄則7: クロスサイト･スクリプティングの対処 • 鉄則8: クロスサイト・リクエスト・フォージェリの対処 • 鉄則9: パスワードの保存はソルトつきハッシュ、できればスト レッチングも • 鉄則10: 他にもたくさんある脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍

2022.03.09 Azure AD導入環境に対するペネトレーションテストの資格「Certified Az Red Te...

大垣さんの寄稿記事「第44回 セキュリティ対策が確実に実施されない2つの理由：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社」のまとめにて、『最後に「何が正しいのか？」常に考えるようにしてください』と書かれています。この部分は、私への反論のようですので、このエントリで返答したいと思います。 大垣さんの主張 先にも述べたように、大垣さんはこのエントリの「まとめ」として以下のように書かれています。 最後に「何が正しいのか？」常に考えるようにしてください。 http://gihyo.jp/dev/serial/01/php-security/0044?page=2 この主張自体には私も大賛成です。大垣さんの記事は以下のように続きます。 例えば，SQL文を作成する場合にリテラル（パラメータ）を文字列としてエスケープすると浮動小数点型のデータが正しく処理されないデ

補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年03月29日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり DNSリバインディング攻撃により、無線LANアクセスポイント(AP)に設定したWPAのパスフレーズ(PSK)を読み出す実験に成功したので報告する。 先のエントリではDNSリバインディング攻撃によるルータ設定変更の実験を報告したが、エントリでも触れたように設定変更についてはCSRF脆弱性を悪用することによっても可能だ*1。両手法の違いとして、CSRFは攻撃先の情報を読み出すことはできないのに対して、DNSリバインディングでは読み出しも可能だ。DNSリバインディングによるセッションCookieの読み出し例につい

補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年03月25日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、DNSリバインディング攻撃によりブロードバンドルーターの設定を外部からの侵入を許すように変更してみたので報告する。 DNSリバインディングに対する関心が高まってきている。本年1月12日には、読売新聞夕刊一面トップで、iモードブラウザ2.0のDNSリバインディングによる不正アクセスが報じられた。3月17日のcomputerworld.jpでは、『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』という翻訳記事が紹介された。実は「最も警戒すべきセキュリティ脅威」というタイ

Webサイトから個人情報が盗まれたり，Webページを改竄（かいざん）される事件が後を絶たない。2008年には，サウンドハウスやナチュラムなどのECサイトから個人情報が漏れたり，ゴルフダイジェスト・オンラインのWebサイトが改竄されたりした。いずれもWebアプリケーションの脆弱（ぜいじゃく）性を突く「SQLインジェクション」という攻撃が使われた。 これだけ事件が続くのは，Webアプリケーションの脆弱性を根絶することが極めて困難だからだ。常に機能を拡張したり，改良したりしているWebサイトでは，どうしても対応漏れが発生しやすい。そうしたWebアプリケーションの脆弱性を外側からふさいでくれるのが，WAF（Web Application Firewall）である。 今回，そのWAFが実際のSQLインジェクションの攻撃をどれだけ防げるのか，主要な5製品を使って徹底検証した。WAFが防いでくれる脆弱性

一般に、セキュアコーディングの基本として入力値の検証（Validation）をせよということになっていますが、これが変な方向に行くといわゆる「サニタイズ」のような手法になってしまいます。以前も指摘したように、アプリケーションとしてのValidationは仕様に従って行うべきものです。 ですが、概ねどの場合でも行うべき検証として以下があると思います。 文字エンコーディングの妥当姓 制御文字(\x00〜\x1f, \x7f)のチェック 文字列長のチェック このうち後ろ二つを正規表現として書くにはどうすればいいかを考えていました。つまり、「制御文字以外の文字でm文字以上n文字以下」というようなチェックです。m文字以上、n文字以下は、{m,n}で書けるので、問題は「制御文字以外の文字」です。これはtextタイプのinput要素で、かつアプリケーション仕様としては文字種の制限をしない場合を想定してい

文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー

前回のエントリSQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem(徳丸浩)の日記に対応して、mi1kmanさんのブクマ経由で、訂正が出ていることを知った。 訂正内容 1ページ目を下記のように変更いたしました（2個所）。 バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 ↓ SQL文のひな型とバインド値は個別にデータベースに送られ、構文解析されるので、バインド値に悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 http://www.impressit.co.jp/inside/?p=791 なんとなく私のエントリの断片が散りばめられているのを別にしても、『悪意あるSQL文…の実行を阻止することができる』というあたりに、サニタイズ的発想が依

文字集合自体は抽象的な「文字の集まり」に過ぎないので単独で問題になることはないが，異なる文字集合に変換する際には問題が発生する場合がある。文字集合が異なるということは，対応する文字が1対1対応していないので，変換先の文字集合で対応する文字がないケースや，多対1の対応が発生する可能性がある。 図1に，Unicodeからマイクロソフト標準キャラクタセットに変換する場合を例示した。マイクロソフト標準キャラクタセットには「骶」（尾てい骨の“てい”）や，ハングルなどはない。また，バックスラッシュ「\」（U+005C）と円記号「\」（U+00A5）がともにJIS X 0201の「\」（0x5C）に変換される場合について示している。 「漢」のように1対1対応している文字は問題ない。ハングルや「骶」のように対応するコードポイントがない場合はエラーになるか文字化けする。インターネットで「尾 骨 びていこつ」