タグ

ブックマーク / blog.ohgaki.net (33)

  • セキュリティ対策を行うべき部分 – 自分が作っている部分

    (Last Updated On: 2018年8月8日)アプリケーション開発者がセキュリティ対策を行うべき部分とはどこか?当たり前ですがアプリケーションです。アプリケーションとは広い意味でのアプリケーションです。Webアプリの場合もあれば、ライブラリやモジュールであったり、フレームワークであったり、言語やサーバの場合もあります。 すべてのアプリケーション開発者が同じような意識を持ち、アプリケーションが安全に動作するようの作る責任はアプリケーションにあると責任感を持って開発すべき、と言いたいところですが実際には難しいです。 例えば、開発を始めたばかりの初心者であれば無理があります。どう作れば安全か、危険か、判断する基準がないからです。経験を積んだ開発者でも自分が作った事もない様なプラットフォーム上でどのように作れば安全か判断できません。 何故、セキュリティが分かり辛いのか?その一つ理由が「セ

    セキュリティ対策を行うべき部分 – 自分が作っている部分
    no_ri
    no_ri 2009/09/20
    フレームワークや環境ごとにプログラマの関与できる範囲が違うので、「自分が作っている部分」を把握するのも楽じゃない(というか、そこを意識しなくても良いようにするためのフレームワークだと思うんだが…)
  • パスワードハッシュはsaltと一緒にハッシュ化する

    (Last Updated On: 2013年11月6日)このタイトルにするとsaltとは、という議論をもう一回する事になるのかもしれませんが、最も近い用語はsaltだと思うので、saltを用語として使います。 随分前からパスワードハッシュはユーザが提供したパスワードと、システムが保持している秘密のランダム文字列と一緒にハッシュ化する方がより安全である、と言っていました。異論がある方もいらしたのですが、どうしてより安全となるのか、場合によっては比べ物にならないくらい安全になるのか、良く分かるビデオを見つけたので紹介します。 (音が大きいので注意!) このビデオを見ると、SQLインジェクションでWebフォーラムのハッシュ化ユーザパスワードを盗み取り、レインボーテーブルを提供しているサイトを利用して「ランダム文字列のパスワード」を解析し、SQLインジェクション情報を提供していたセキュリティ関連

    パスワードハッシュはsaltと一緒にハッシュ化する
  • JavaScript無しでフォームをコントロール

    (Last Updated On: 2008年9月3日)言われてみれば、そう言えばそんな機能があったね、と思うような機能はよくあります。 JavaScript無しでフォームを制御する方法はHTML4が策定されている時に追加された機能です。 http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1 以下のLABELタグのサンプルは http://www.0x000000.com/?i=635 より拝借しています。 <label for="action"> <body> Etymology of "Foo" 1 April 2001 When used in connection with `bar' it is generally traced to the WW II era Army slang acronym FUBAR (`F

    JavaScript無しでフォームをコントロール
  • mod rewriteを使用した簡易WAF

    (Last Updated On: 2018年8月8日)http://www.0x000000.com/?i=567 にmod rewriteを利用した簡易WAF(Web Application Firewall)の定義例が掲載されています。同じようなアイデアをお持ちの方、既に似たような設定を使われている方も多いとは思います。 簡単なWAFですが、実用性も高いです。例えば、ヌル文字やHTML特殊文字のインジェクションは様々な攻撃で利用されます。アプリケーションで対処が忘れられがちなCOOOKIEやREFER、USER_AGENT等に特殊文字が入っていた場合にアクセスを拒否する部分だけもで導入する価値は十分にあると思います。 元ネタのサイトは英語ですが、解説付きです。 これを入れると問題となる場合もあるので、内容を理解してから利用しなければなりません。 RewriteEngine On Op

    mod rewriteを使用した簡易WAF
  • スクリプトインジェクション対策の特集 – gihyo.jp

    (Last Updated On: 2008年4月10日)技術評論社でブログっぽい記事を書かせて頂いています。4月3日からスクリプトインジェクション対策で注意すべき項目が掲載されます。一般的なスクリプトインジェクション対策「バリデーションしエスケープする」ではなく、万が一スクリプトインジェクションに脆弱であった場合でも被害を最小限に留める対策、見落とされがちな対策を中心に解説しています。 # 一度に書いた記事なのでどう分割されるか私も分かりません。 # 物によっては2回に分割するかもしれないので20弱くらい # だと思います。 http://gihyo.jp/dev/serial/01/php-security から最新の一覧を参照できます。 ご意見やご希望などございましたらこのブログから送って頂いても、メールで送って頂いても歓迎致します。ご興味がある方はご覧ください。 現在(4/9)時点

    スクリプトインジェクション対策の特集 – gihyo.jp
  • LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠

    (Last Updated On: 2008年4月3日)誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。 結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。 ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。

    LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
  • 正しいメールアドレスのチェック方法

    (Last Updated On: 2018年8月13日)正しいメールアドレスのチェック方法がちょっとした話題になっているようです。Web屋のネタ帳でも取り上げられていますが、メールアドレスのチェック方法自体は解説していません。ついでなので書いておきます。 「当に正しいメールアドレスかチェック」するには実際にメールを送信して、送信されたユーザしか知り得ない情報をユーザが知っている事により確認しなければなりません。これはWeb屋のネタ帳で解説されている通りです。 安全でより確実なメールアドレスのチェック方法 きちんと正規表現でメールアドレスをチェックするのは面倒です。しかも、RFCを守らない大手企業もあり、正規表現でチェックするのは諦めるのが妥当でしょう。 記入されたメールアドレスが正しいかチェックする手順 @でスプリット(分割)する 配列要素数が2つかチェック。NGはエラー 1つ目の要素

    正しいメールアドレスのチェック方法
  • Apache httpd脆弱性のリスク評価は不十分

    (Last Updated On: 2008年1月24日)先日Apache httpdサーバにセキュリティ脆弱性を修正したリリースが公開されました。 例えばSecuniaのApache httpd 2.2の脆弱性ページをみると先日リリースされた2.2.8で修正された脆弱性のセキュリティリスクは低く評価されています。 http://secunia.com/advisories/28046/ ここにはmod_negotiation脆弱性の記述がありません。mod_negotiationはここに掲載されているmod_proxy_ftp,mod_status,mod_proxy_balancer,mod_imagemapと違い、多くの環境でデフォルトで有効となっていると考えられるモジュールです。 Minded Security Labs: Advisory #MSA01150108 Apache

    Apache httpd脆弱性のリスク評価は不十分
  • Firefox chrome: URL Handling Directory Traversal

    (Last Updated On: 2008年1月25日)前回のエントリでFirefoxの利用をお勧めしているので未パッチのFirefoxの脆弱性を紹介しておきます。 Firefox chrome: URL Handling Directory Traversalにchromeがディレクトリ遷移攻撃に脆弱だとレポートされています。 この脆弱性を用いるとシステム内のファイルを盗まれる可能性があります。(追記に書きましたが、正確にはJavaScriptとして読み取れる必要があります。コードを見ると判りますが、JSON形式のデータファイル, prefs.js等が読みとられる可能性があります。)PoCとしてWindows上のThunderbirdのall.jsを取得するコードが公開されています。 <script>pref = function(x, y){document.write(x + ‘

    Firefox chrome: URL Handling Directory Traversal
  • 文字エンコーディングを利用したSQLインジェクション

    (Last Updated On: 2008年1月19日)PHPSQLインジェクションを実体験 http://www.thinkit.co.jp/free/article/0801/5/2/ を書かせて頂きました。この文字エンコーディングを利用した攻撃は古い脆弱性です。知っている方なら2年以上前からよくご存知とは思います。 記事のタイトル通り、文字エンコーディングを利用したSQLインジェクションを実体験できます。ご興味のある方、まだご存知でない方はぜひご覧ください。 万が一、文字エンコーディングベースの攻撃に未対策で攻撃される可能性のある方はできるだけ早く対策することをお勧めします。

    文字エンコーディングを利用したSQLインジェクション
  • UPnPルータ+Flash=深刻なセキュリティ問題

    (Last Updated On: 2008年1月18日)GNUCITIZENは重要なセキュリティ問題を次々に公開しているのでセキュリティに興味がある方はチェックしているのでご存知とは思いますが、 Hacking The Interwebs http://www.gnucitizen.org/blog/hacking-the-interwebs に非常には深刻なセキュリティ問題が解説してあります。具体的な攻撃方法などはGNUCITIZENを参照してください。日でもいろいろ書かれるかな、と思っていたのですが予想より少ないのでブログに書くことにします。ここでは重要な部分だけ要約して書きます。 攻撃 Flashを利用したUPnPルータの攻撃シナリオは以下になります。 UPnPが有効なルータがある 悪意のあるFlashをWebブラウザで参照する UPnPルータの設定を変更するSOAPリクエストを

    UPnPルータ+Flash=深刻なセキュリティ問題
  • Cross Site Printing

    (Last Updated On: 2008年1月11日)クロスサイトスクリプティングと同じ要領でネットワークプリンタに接続して印刷してしまう「Cross Site Printing」と呼ばれている手法が公開されています。 <img src=”myprinter:9100/Print_from_the_web”> ポート9100でネットワークプリンタが印刷できる状態で待機しているので印刷できてしまいます。クロスサイトリクエストフォージェリと同じようなもの、と言った方が分かりやすいかも知れません。PDFにはFAXの送信方法も記載されています。 Cross Site Printingの仕組みは単純ですが根的な対策は簡単ではありません。

    Cross Site Printing
    no_ri
    no_ri 2008/02/20
    ルータを操作するのと似たような感じ
  • Ruby on Rials – Session Fixation脆弱性の攻撃方法

    (Last Updated On: 2008年2月3日)前回に引き続きWeb関係のセキュリティ脆弱性がどのように攻撃されるのか解説した記事がThinkITに掲載されています。 今回はRuby on Railsの脆弱性が対象です。Ruby on Railsにもいくつかのセキュリティ脆弱性が報告されていますが、URLベースのセッションがいかに脆弱であるか解説しています。 解説対象の脆弱性 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5380 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6077 Railsのセッション管理機構にはSession Adoption脆弱性は無いのに何故攻撃できるのか?と思った方は読んでみてください。記事を読んで頂くと脆弱性を実際の攻撃に

    Ruby on Rials – Session Fixation脆弱性の攻撃方法
  • 安全にInternet(ブラウザ)を利用する為のTips

    (Last Updated On: 2008年2月1日)一般的なユーザはインターネットを利用する場合のリスクを十分理解していない場合が多いと思います。コンピュータに詳しくない方が、より安全に利用する為のTipsを考えてみました。 常に最新バージョンのブラウザを利用する 常に最新バージョンのブラグインを利用する JavaScript/プラグインを無効にする ブラウザにインストールする拡張機能(プラグイン)は最小限にする 仮想環境でブラウザを利用する ログアウトする ブラウザを終了させる 管理者権限を持たないユーザでログインする ブラウザとプラグイン以外のアプリケーションも最新版を利用する 信用できそうなサイトもできるだけ信用しない インターネットからダウンロードしたアプリ、プラグイン、コーデック、ドライバ等をインストールしない サイト毎に別のパスワードを設定する 文字エンコーディングの自動認

    安全にInternet(ブラウザ)を利用する為のTips
  • 企業ユーザはPHP4からPHP5への移行は慎重にすべき

    (Last Updated On: 2018年8月13日)2008年1月3日のPHP4.4.8のリリースを持ってPHP4サポートが終了しました。海外では「PHP5へ移行しよう」キャンペーンも始まりました。 私は従来から「PHP5へ早く移行すべきです」と繰り返し勧めて来ました。現在でも全てのオープンソースアプリケーションの開発者は、今すぐPHP5に移行すべき、と考えています。 しかし、新規開発を除き、企業ユーザには今すぐPHP5へ移行すべきだ、と一概にアドバイスできません。3つのお薦めしない理由があります。 PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP5に移行するとマイナーバージョンアップに追随しないとならない PHP5.3のリリースが準備されている PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP4からPHP5への移行でチェックしなければなら

    企業ユーザはPHP4からPHP5への移行は慎重にすべき
    no_ri
    no_ri 2008/02/18
    『PHP 5.2からPHP 5.3へのバージョンアップはメジャーバージョンアップに近い、と言える機能追加が行われます。』  たとえば、PHPを…
  • クロスサイトスクリプティングを防ぐための10のTips

    (Last Updated On: 2007年12月19日)クロスサイトスクリプティングを防ぐための10のTipsをgihyo.jpのブログに載せました。 Webサーバの設定になるので書いてませんがApacheなどでも明示的に文字エンコーディングを指定した方が、誤って違った文字エンコーディングで静的コンテンツを書いてしまった場合でも分かるのでよいと思います。 AddDefaultCharset utf-8 などとhttpd.conf/仮想ホストの設定ファイル、.htaccessなどに記述すると静的なコンテンツにも文字エンコーディングをHTTPヘッダレベルで指定できます。 あまりやらないと思いますが11番目を追加するなら「VBScriptを動的に生成する場合に注意を払う」あたりだと思います。

    クロスサイトスクリプティングを防ぐための10のTips
    no_ri
    no_ri 2008/01/07
    使えないサイトも多いけど
  • WordPress Charset SQL Injection Vulnerability

    (Last Updated On: 2007年12月15日)http://www.securiteam.com/unixfocus/6N00D0AKKM.html に解説されている脆弱性は基中の基です。 Most database query in WordPress uses escape() method to sanitize SQL string, which is essentially filtering input via addslashes() function. However addslashes() fails to consider character set used in SQL string, and blindly inserts backslash before any single quote, regardless of whether such

    WordPress Charset SQL Injection Vulnerability
  • セキュリティ対策の基本とセーフガード

    (Last Updated On: 2007年11月26日)備考:かなり古いブログですが公開し忘れしていた分です。 セキュリティ対策の基とセーフガードを セキュリティ対策の基は -外部システム(人間を含む。DNS、メールのデータ等も)は信用しない -信用できないデータは確実に確認する -外部システムに出力する場合は外部システムの仕様に従った形式で出力する ですがセーフガードの話をしているのに「セキュリティは…」と説明し始めるケースがよくあります。 セーフガードは「問題が発生しても問題を最小限に留める仕組み」であるのでセーフガードの話をしているのに「セキュリティは …」と議論をすりかえられては議論になりません。セーフガードが必要無いならJavaやC#なんて使わなくてもC++を使ってポインタをバリバリ操作すれば良いです。JavaにもSandboxなんて必要ないです。PHPのopen

    セキュリティ対策の基本とセーフガード
  • Webアプリスキャナの性能

    (Last Updated On: 2013年12月3日)NTOSpider, AppScan, WebInspectとメジャーなWebアプリスキャナの性能を比較した方がいるようです。結果のPDFは以下のURLです。 クリックしてCoverageOfWebAppScanners.pdfにアクセス Forty Tracerを使ってスキャン中のコード実行カバレッジを利用してアプリケーションスキャナの性能を評価しています。 結論はNTOSpiderがダントツの性能のようです。AppScan、WebInspectは同じ程度となったようです。いずれにせよWebアプリスキャナは「セキュリティを維持」する為のツールではなく「最低限のセキュリティが維持できているかチェック」する為のツールなので多少の性能差ならそれほど気にする必要はないでしょう。しかし、多少と言える性能差ではないのでIBMとHPには頑張って

    Webアプリスキャナの性能
    no_ri
    no_ri 2007/10/26
    『Webアプリスキャナは「セキュリティを維持」する為のツールではなく「最低限のセキュリティが維持できているかチェック」する為のツール』
  • フォームの2重送信の防止…

    (Last Updated On: 2013年12月3日)ちょっと気になったので… 記事はコラム形式だったので書いていないだけだと思いますが2つ問題があります。 1. 識別可能なフォームの数に限りがある セッション変数を利用しているため変数名でフォームを識別する必要があり、ユーザが複数のフォームを利用した場合、正しく動作しない。この制限をなくす事もできますが、その場合セッション変数が大きくなりすぎた状態に対処するようにしないとならくなります。(ガーベッジコレクションの実装が必要) 2. レースコンディションによる2重投稿の可能性がある コードを見て分かる通り if (isset($_POST['submit_button'], $_SESSION['ticket'], $_POST['ticket']) && $_SESSION['ticket'] === $_POST['ticket']

    フォームの2重送信の防止…