タグ

Securityと脆弱性に関するforce8のブックマーク (11)

  • SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog

    以前このブログでも取り上げたことのある神戸デジタル・ラボの近藤伸明氏がThink IT上で「SQLインジェクション大全」という連載を執筆しておられる。その第三回「SQLインジェクションの対策」を読んで以下の部分が引っかかった。 バインド機構とは、あらかじめSQL文のひな型を用意し、後から変動個所(プレースホルダ)に実際の値(バインド値)を割り当ててSQL文を生成するデータベースの機能だ。バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる(図1-2)。 http://thinkit.jp/article/847/1/ たしかにエスケープ処理を使ってバインド機構を実装する場合もある。JavaMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 | 徳丸浩の日記から派生して、MyS

    SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog
  • 高木浩光@自宅の日記 - 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認

    楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認 楽天は比較的早い時期からコンピュータセキュリティに真剣に取り組んできた希有な存在だと認識している。昨年には、企業内CSIRTを正式に組織し、組織名を「Rakuten-CERT」とした。*1 楽天、社内に「CSIRT」を設置, ITmediaエグゼクティブ, 2007年12月6日 「楽天ad4U」の「脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手」の問題(前回の日記参照)は、その手法自体が直接人々のプライバシーを侵害するか否かという問題ではない。実際、「楽天ad4U」について言えば、閲覧履歴の有無は参照するけれども履歴自体の送信はしないように作られており、開発元はこれを「プライバシー保護にも優れています」と宣伝している。 しかし、この問題の根は、10月の日経の記事にも書いたように、この手法が広く使われるようになって、こ

  • JPCERT/CCとの「脆弱性情報ハンドリング」の記録 : DSAS開発者の部屋

    ■ はじめに 「△△製のソフトウェア××に脆弱性が発見された」というニュースが連日のようにネットの上を行き交っています。 このブログの読者にはプログラム開発者の方も多いと思いますが、 自分の携わるソフトウェアの脆弱性を第三者から指摘された経験のある方はどのくらいおられるでしょう? 先日、筆者は「HttpLogger」というフリーソフトウェアのセキュリティホールを修正しました。 そのきっかけとなったのはJPCERT/CC(有限責任中間法人 JPCERT コーディネーションセンター)様から届いた 一通のメールでした。 それから私は同センターと連携し、10日余りの準備期間を経て修正ずみのモジュールの公開と 旧バージョンにおける脆弱性情報の開示を行いました。 この「脆弱性情報ハンドリング」と呼ばれるプロセスに関わったことは、一般的な知名度とは裏腹に 普段あまり身近な存在ではない「JPCERT/CC

    JPCERT/CCとの「脆弱性情報ハンドリング」の記録 : DSAS開発者の部屋
  • SQL Injectionツール - teracc’s blog

    ここのところ、いくつかのSQL Injectionツールについて調べていました。今日はその結果を日記に書いてみようと思います。 はじめに SQL Injectionツールとは SQL Injection脆弱性の発見と、発見した脆弱性を突いてのDB内情報の取得を行なうためのツールです。 ただし、多くのツールでは「脆弱性の発見」はおまけで、後者のDB内情報の取得に主眼を置いています。一般的には、汎用のWeb脆弱性スキャナなどで脆弱性を見つけて、その脆弱性に対してこの日記に書いているようなツールを使って情報を取得するという使い方をすることが多いでしょう。 SQL Injectionツールは、いわゆるHackingツールです。脆弱性検査を行なう者か、さもなければCrackingを行なう犯罪者が使うくらいで、一般のWeb開発者やユーザの人が使う必要に迫られることは無いでしょう。 ツールの使用に際して

    SQL Injectionツール - teracc’s blog
  • クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記

    昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS

    クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
  • リクエストをいじれば脆弱性の仕組みが見えるのだ!

    telnetでリクエストを打つのは面倒…… クウ 「うーん。めんどくさい……」 ジュンさんにWebアプリエンジニアとして重要な基礎、HTTPのしくみを教えてもらったクウは、引き続きHTTPと格闘中だ。 クウはジュンさんに教わったとおりtelnetを使ってHTTPを勉強していた。しかし、telnetで静的ファイルの閲覧などは比較的簡単にできるのだが、肝心のWebアプリケーションの閲覧を行うには非常に面倒であった。 ユウヤ 「どうしたの?」 クウ 「HTTPの勉強しようと思ったんだけど、コマンドをいちいち打ち込むの大変なんだよね……」 ユウヤ 「なんかそういうの、簡単にできるツールあるんじゃないの?」 クウ 「ああ、そうか。よく考えたらそういうのありそうだね。ちょっと探してみよっと」 ユウヤ 「まあ、それはいいとしてだ。昨日頼んでおいた資料ってどうなった?」 クウ 「ああっ。ごめん! 共有サー

    リクエストをいじれば脆弱性の仕組みが見えるのだ!
  • メモリを解析して脆弱性を自動的に検出、攻撃コードを作成するツール

    (Last Updated On: 2007年8月10日)オープンソースのセキュリティツールで有名(?)なImmunityのDebuggerが結構話題になっている。他にもいろいろ紹介されているようですがeWeekの記事が分かりやすい。 http://www.eweek.com/article2/0,1895,2166829,00.asp Debuggerはヒープやスタックメモリを自動的に解析して脆弱性を検出し、ほぼ自動的に攻撃コードを作成することもできるようです。攻撃コードの作成時間を50%削減できるとしています。 http://www.immunitysec.com/products-immdbg.shtml 一時的には0day攻撃が増える事が予想されますが脆弱性検査が容易になる、特に機械的検出できるような脆弱性検査が容易になる、のは良い事だと思います。

    メモリを解析して脆弱性を自動的に検出、攻撃コードを作成するツール
  • Perlを使って脆弱性を検証する:CodeZine

    はじめに 今回はXSSの脆弱性をチェックするPerlスクリプトを作成したいと思います。すべてのXSSによる脆弱性が回避できるわけではありませんが、テストコード作成のヒントになれば幸いです。 対象読者 Webアプリケーション開発者で、XSSのテストケースを作成したい方。 必要な環境 Perl 5.8以上が動作する環境。基動作の確認はMac OS Xを利用しました。次のPerlモジュールを利用するので、あらかじめインストールしておいてください。 Template::Toolkit Web::Scraper Test::Base またCGIを使用するので、ApacheなどのCGIが実行できるWebサーバを用意してください。 解説内容 ソースコード解説 まず最初にソースコードの解説をします。 xss.pl

  • ウノウラボ Unoh Labs: 5分でできるウェブサーバのセキュリティ向上施策

    こんにちは、naoya です。 先日、ウノウが公開しているサービスの中にいくつかの脆弱性が見つかったため、社内で「脆弱性発見大会」を開催しました。この大会は、二人一チームに分かれてウノウが公開している各サービスの脆弱性を見つけることを目的とした大会です。結果は、いくつか各サービスに脆弱性が見つかり、すぐに修正することができました。 僕のチームは、ウノウのホームページやラボブログなど細かいサービスを担当しました。その中で、いくつかのウェブサーバにセキュリティ上あまい設定がありました。 今日は、ウェブサーバのセキュリティ向上のための設定方法についてエントリします。なお、ウェブサーバはApache 2.2系を前提としています。 サーバ情報の表示しない ウェブサーバ(Apache)で、404などのエラーページを表示したとき、ヘッダやページの下にApacheやOSのバージョンが表示されます。こういっ

  • [セキュリティ]画像へのPHPコマンド挿入 ― T.Teradaの日記

    だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ

  • Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT

    Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP(Open Web Application Security Project)は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ

    Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT
  • 1