パスワード管理で陥りがちな9つの落とし穴
ITの世界では至る所にパスワードがある。デスクトップにもWebサイトにもVPNにも、常にパスワードが絡んでくる。幸いなことに、パスワードを管理しやすくする手だてはある。だが不幸なことに、当分の間はパスワードから逃れられそうにない。つまり、パスワード管理の不手際から生じるセキュリティ問題は今後も続くということだ。 どんな組織であれ、セキュリティ上の弱点の50％以上は脆弱なパスワードに原因がある。パスワードに本来の役割を果たしてもらい、逆にセキュリティの妨げになるような事態を防ぐため、パスワード管理で陥りがちな9項目の落とし穴を以下に紹介する。 1．弱いパスワード OSレベルでは強い（破られにくい）パスワードに気を配るのに、OSと同じくらい簡単に破られてしまうほかの重要システムのことは忘れてしまう人が多い。スマートフォン、無線LAN、VPN、ファイアウォール、データベース、重要文書などは、いず
おさかなラボ - passwordのより安全な保管方法(saltとは何か)
UN*Xパスワードの保存方法を知っている人には常識のはずだが、最近パスワードの保存方法について誤解が散見されるように思うのでこのエントリを立てた。 パスワードはMD5などでハッシュを取って保存する(DES等を使う場合もある)方法が広く使われている。その際、パスワードをそのままハッシュすると危ないので、プログラム側でMD5を取る時に、ランダムな定数を混ぜ、これのハッシュを取ることによってハッシュの安全性が増加する。つまり以下のようなコードになる $passwd = Digest::MD5::hex_md5($user_id . ‘woeifoweij’); # これで大丈夫(?) これで簡単にクラックすることはできない。 ……という理屈は正しいとは呼べない。パスワードに付加する文字列をsaltと呼んだりするが、これでは充分とは言えない。saltの利点はそれだけではないのだ。 このク
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
第12回■主要言語別：入力値検証の具体例
これまで2回にわたってWebアプリケーションにおける入力値検証とセキュリティ対策の関係を説明してきた。入力値検証はセキュリティ上の根本的対策ではないが，保険的な対策として効果が期待でき，特に制御コードや不正な文字エンコーディングによる攻撃対策には有効であることを説明した。 今回は，Webアプリケーション開発によく使われる4種類の言語（Perl，PHP，Java，ASP.NET）に関して，入力時処理の具体例を示す。ここで取り上げる「入力時処理」とは以下の内容を含んでいる。 文字エンコーディングの検証文字エンコーディングの変換入力値検証 Perlによる実装の方針 Perl言語はバージョン5.8から内部文字エンコーディングとしてUTF-8をサポートし，文字単位での日本語処理が可能だ。文字エンコーディング処理にはEncodeモジュールを使用する。入力値検証には正規表現を用いるのが便利だ。 ■文字エ
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
何故かあたり前にならない文字エンコーディングバリデーション - ikepyonのだめ人間日記
http://blog.ohgaki.net/char_encoding_must_be_validated まあ、当たり前にはならないでしょう。どう考えても不正な文字エンコーディングを受け付ける言語やらフレームワーク、DB、ブラウザが悪いと思う。不正な文字エンコーディングをチェックするというのはバッドノウハウだと思うし。そんなことに対応するのは大変すぎるからねぇ。 アプリ開発者を啓蒙するより、PHPとか直したほうが早いと思うんだけど。 XSSやSQLインジェクションが発生しないようにエスケープ処理やバインド機能を使うというのは、プログラムの基本に立ち返って、どんなデータが渡されても正確に処理を実行するために必要なことなので、当たり前といえると思う。 でも、不正な文字エンコーディングのチェックはプログラミング手法ではなく、それを受け取って変に解釈してしまうDBやらブラウザなどが直せないから
symfony1.2のCSRF対策について
こんにちは、小川です。 symfony1.2ではsfFormクラスを用いてフォームのレンダリングや入力項目のバリデーションを行います。このsfFormクラスにはCSRF対策も実装されているのはご存じでしょうか。 今回はこのCSRF対策が具体的にどのように行われているかをお話ししたいと思います。 先にどのような手法で対策を行うかですが、フォームごとに異なるトークンをHTML上に埋め込み、その値をバリデーション時にチェックするという方法で対策を行っています。 具体的にどのようにトークンが生成され、どのようにチェックを行っているかは後ほど詳しく説明します。 CSRF対策を有効にするためにはどうすれば良いでしょうか。Jobeetなどでsymfony1.2について学んだ方はご存じかと思います。 CSRF対策は各アプリケーションごとに設定可能で、アプリケーション作成時に以下のようにすることで有効になり
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
［気になる］JSONPの守り方
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） JSONPだって、セキュリティを気にしてほしい 皆さんこんにちは、はせがわようすけです。今回は、JSONPを使用する場合のセキュリティについて解説しましょう。 JSONPとは、JSON with Paddingの名称が示しているとおり、JSON形式のデータにコールバック関数の呼び出しのためのコードを付加することで、クロスドメインでデータの受け渡しを実現するためのデータ形式です。JavaScriptからクロスドメインでのデータが簡単に扱えることなどを理由に、多数のWebアプリケーションでAPIの一部としてJSONP形式でデータの提供が行われています。 具体的な例を見
無線LANのWPAをわずか数秒から数十秒で突破する新しい攻撃方法が登場、早期にWPA2に移行する必要あり
今回の方法は昨年11月に発表された「Tews-Beck攻撃」(WEPのTKIPにおいて辞書攻撃ではなくプロトコルの不備をつくことによって、15分前後かかるが、鍵の一部を確定的に導出できる方法)がQoS制御を利用する機器に限定されるものであり、鍵の導出に15分もの時間が必要であったのに対して、わずか数秒から数十秒で導出してしまうことができるというもの。 このWPAについての実践的な攻撃方法は8月7日に「A Practical Message Falsification Attack on WPA」という題目で、台湾にて開催される国際会議 JWIS2009（Joint Workshop on Information Security ）にて大東俊博氏（広島大学 情報メディア教育研究センター）と森井昌克氏（神戸大学大学院 工学研究科）によって発表される予定となっています。 詳細は以下から。 Jo
はてなのCAPTCHAを破るプログラムは30分で書ける - やねうらおブログ(移転しました)
CAPTCHAとは、スパムコメントなどを防止するための認証画像のことである。 それにしても、はてなのCAPTCHAはひどい。無いよりマシという考え方もあるのでそれについてはあまり議論する気は無いのだが、それにしてもこれを破るプログラムは30分あれば十分書ける。 具体的には、はてなのCAPTCHAには8つの好ましくない特徴と、2つの脆弱性がある。 ■ 8つの好ましくない特徴 ・画像自体のサイズが小さすぎる。→ こんなに小さいと探索量(計算量)が小さくて済む。 ・フォントにゆがみがない → フォントはある程度変形させたほうが良い。変形させてあるとテンプレートマッチングがしにくくなる。 ・フォントが固定。→ フォントは毎回変えたほうが良い。 ・フォントを回転させていない → フォントは文字ごとにある程度ランダムに回転させた方が良い。 ・フォントサイズが一定 → フォントサイズは文字ごとにある程度
GnuPG を使って暗号化したり署名したりする - ぽち＊ぷ〜ち
インターネットを介した通信では特別な暗号化手段を取らない限り通常は平文のデータがやりとりされます。こういった平文のデータは通信経路の途中で簡単に覗き見出来、悪意を持って内容を改竄する事も可能です。このページでは debian lenny で、安全なメールのやりとりの為に GnuPG を使って暗号化したり署名したりする方法をメモしておきます。 自分用の公開鍵・秘密鍵ペアを作成する GnuPG は公開鍵暗号方式を利用しているので、自分用の公開鍵と秘密鍵のペアが必要です。 $ gpg --gen-key gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO
GnuPG - The GNU Privacy Guard Version 1.2 (README日本語訳)
GnuPG - The GNU Privacy Guard Version 1.2 README はじめに インストール ソースを検証するには ドキュメント GnuPGの使い方 ユーザIDを指定する8つの方法 バッチモード 終了ステータス Configureオプション インストール時の問題 マシン固有の問題 ランダムデバイス RPMパッケージの作成 さらに情報を得るには 翻訳メモ Copyright 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. This file is free software; as a special exception the author gives unlimited permission to copy and/or distribute it, with or without mod
高木浩光＠自宅の日記 - ビデオ版「日本のインターネットが終了する日」
■ 情報ネットワーク法学会特別講演会を聴講してきた 昨日は、情報ネットワーク法学会の特別講演会「個人情報保護、自己情報コントロール権の現状と課題」を聴講してきた。堀部政男先生の基調講演では、OECDの情報セキュリティ・プライバシー作業部会の副議長を12年間務めてこられた中でのご経験のお話、佐藤幸治先生の特別講演では、憲法学の立場からプライバシーをどうとらえるかの哲学的なお話を伺うことができた。 堀部先生のお話の中で、OECDの作業部会に副議長として参加した際に、他の国からは、「Privacy Commissioner」「Data Protection Commissioner」「Data Protection Authority」といった、国の機関からの代表者が派遣されているのに、日本だけが国の代表者ではなく一人の研究者としての参加であったため、時には一部の情報について教えてもらえないこと
画像ファイルによるクロスサイト・スクリプティング(XSS)傾向と対策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2007年12月6日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 最近、画像ファイルを用いたクロスサイト・スクリプティングが注目されている。本稿では、画像を悪用したXSSについて説明した後、対策方法について解説する。 画像によるXSSとはどのようなものか Internet Explorer(IE)の特性として、コンテンツの種類を判別する際に、レスポンスヘッダ内のContent-Typeだけでなく、コンテンツの内容も判断基準にしている。このため、Content-Typeが例えばimage/gif(GIF画像)となっていても、中身がHTMLであればHTMLと解釈して表示する。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パスワードをハッシュ化（暗号化）保存することを法律で義務化するくらいのことが必要だと思う
http://neta.ywcafe.net/000123.html
http://neta.ywcafe.net/001019.html
受け入れテスト用セキュリティチェックリスト for Webアプリケーション