2 段階認証は本当に安全なのか調べてみた | はったりエンジニアの備忘録
このブログを読んでいる人なら Google や AWS の 2 段階認証（マルチファクタ認証）を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。 有名どころのサービスでは使えるところが増えてきましたが、2 段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。 というわけで、2 段階認証は本当に安全なのか仕様を紐解きながら調べてみました。 ワンタイムパスワードの仕様 ワンタイムパスワードを生成する仕様は HOTP と TOTP の 2 つがあり、RFC の仕様になっています（TOTP はドラフト段階）。 HOTP (HMAC-Based One-Time Password Algorithm) TOTP (Time-Based One-Time P
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
革命の日々！ __attribute__(alloc_size) を使わないと_FORTIFY_SOURCE を活かせないよ。という話
_FORTIFY_SOURCEというバッファーオーバーフロー攻撃を防ぐのにとても有用なマクロがある。 知らなかった人は以下のmanでもまず見てください http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/feature_test_macros.7.html _FORTIFY_SOURCE (glibc 2.3.4 以降) このマクロを定義すると、文字列やメモリの操作を行う様々な関数を 使用する際にバッファオーバーフローを検出するための軽めのチェックが 実行されるようになる。すべてのバッファオーバーフローが検出される わけではなく、あくまでよくある例についてだけである。 現在の実装では、以下の関数にチェックが追加されている: memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3),
Androidアプリセキュリティ 〜Webサイト閲覧でroot権限を取得されてしまう脆弱性(1)〜 | Remote TestKit
Androidのブラウザ(図中ではWebkitと記載)の脆弱性を利用して相手の端末の管理者権限を取得されてしまうのはどういった仕組みで起きるのかについて解説します。 「○○○の脆弱性により任意のコードが実行される可能性があります」といった文章を一度は見たことがあると思います。 しかし、実際にどのような流れで任意のコードが実行されるのか？読者の皆さんはイメージできるでしょうか？ 今回説明するのは、Androidのブラウザ(図中ではWebkitと記載)の脆弱性を利用して相手の端末の管理者権限を取得する、という少し過激な内容です。 読者の皆様、特にAndroidアプリケーション開発技術者の方々に、今回の記事を通して少しでもセキュリティに興味を持っていただき、セキュアなアプリケーション開発のヒントになればと思います。 1．全体の流れ 遠回りになっていまいますが、まずは、「Android端末からWe
X-Frame-Options - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) X-Content-Type-Options X-Frame-Options X-XSS-Protection サイトの安全化 HTTP Observatory HTTP アクセス制御 (CORS) HTTP 認証 HTTP キャッシュ HTTP の圧縮 HTT
twitterに学ぶなりすまし投稿対策
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
IPAから「クリックジャッキング」に関するレポート出ました
Webアプリケーションのセキュリティの分野で「新しい攻撃手法」は実はそれほど多くないのですが、比較的新しく対応が求められているものとしてクリックジャッキングがあります。クリックジャッキングは、CSRFと同じように「Webアプリケーションのサーバー側機能」を利用者（被害者）に実行させる手法です。CSRFは、当該機能を実行するHTTPリクエストを送信させる罠を使いますが、クリックジャッキングの方は、iframe等に当該機能を呼び出す画面を表示しておき、利用者（被害者）に実行ボタンを押させる（=クリックジャック）手法です。クリックジャッキングに関しては従来詳しい解説がありませんでしたが、この3月26日にIPAから「クリックジャッキング」に関するレポートが公開されました。 このレポートから、クリックジャッキングのイメージを示す図4を引用します。 サイトAが攻撃対象のサイト、悪意のあるページは罠にな
僕が考える最強の超高集積型Webホスティングシステム！
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでの記事を振り返って、まとめの意味でも、現状僕が考えうる最強の高集積型Webホスティングシステムの設計を忘れないうちに書いておこうと思います。これらは夢のような話ではなく、現実的にAmazonEC2上にプロトタイプとして作ってもいいなぁ、と思っていたりします。 最強の超高集積型Webホスティングシステム！とは ホスティングシステムということで、ホストをかりる側がどういうコンテンツを使うのか分からないので、できるだけ自由度の高いシステムを考えた時は、やはりベースソフトウェアはApacheが良いのではと思います。また、超高集積にする事でハードウェアのコストを下げ、超低価格を実現し、かつ、セキュアで運用性が高く高機能なシステムを目指します。
Amon2とJSONとセキュリティ - tokuhirom's blog
[1]http://d.hatena.ne.jp/ockeghem/20110907/p1[2]http://www.atmarkit.co.jp/fcoding/articles/webapp/05/webapp05a.html[3] http://msdn.microsoft.com/ja-jp/asp.net/ff713315[4] http://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/cross-site_including.phpあたりをよんで、JSON とセキュリティについてかんがえてみた。 ここで、有効とされている対策のうち while(1); を先頭に付与するPOST ですべて処理するといったあたりは、RESTful でないし、BK 感がひどいというか本質的ではないのでできるだけやりたくない。 また、Amon2 では互換
PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)～JSON等の想定外読み出しによる攻撃～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
Webアプリケーション向けの自動セキュリティスキャナ「Skipfish」を試してみました
* GNU C Compiler * GNU Make * GNU C Library (including development headers) * zlib (including development headers) * OpenSSL (including development headers) * libidn (including development headers) KnownIssues – skipfish –参照。 私の環境では、libidnがなかったので、yumで入れました。 さて、skipffish本体のインストールを行いましょう。 ※最新のダウンロードはこちらのページを参照ください。 http://code.google.com/p/skipfish/ # wget http://skipfish.googlecode.com/files/skipfi
高木浩光@自宅の日記 - SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも, クレジットカード業界は最もWebセキュリテ..
■ SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも 24日のIT Proの記者の眼に「なぜSSL利用をケチるのか」という記事が出ていた。筆者の阿蘇氏には勤務先でWebアプリケーションセキュリティについて取材を受けたことがある。この記事の主張はこうだ。 Webサイトはログイン画面からSSLを使い，利用者はログイン時に鍵マークを確認するのが常識。 阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日 正しい。より正確には「ログイン時」というのは、パスワードを入力する前にということだろう。ただ、その根拠としてこの記事は、フィッシング対策としてサイトが本物かを確かめるためという点だけを挙げているが、その根拠はやや弱い。 SSLをパスワード送信先の画面からではなく、入力画面から使わなくてはならない理由のもうひとつの重大な理由
ubuntuでAircrack-ngを使ってみた 1 - jitsu102's blog
Eee PC 901-16Gにインストールしたubuntu 9.04でAircrack-ngを使ってみました。 Aircrack-ngで使用できる無線LANチップは、ここで確認できます。 Eee PC 901-16G標準のRalink RT2860 STAでは動きません。 Aircrack-ngのインストール $ sudo aptitude install aircrack-ng インストールされる主なツール類は、以下の通り。 airmon-ng ->無線LANカードをモニタモードにする。無線LANカードを使っているプロセスを確認する。 airodump-ng ->無線LANパケットキャプチャ。 aircrack-ng ->airodump-ngで取得したパケットを解析する。 aireplay-ng ->アクセスポイントを突っついて、解析に必要なパケットを増幅されるなどのサポートツール。
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
Linux Security HOWTO: ファイルとファイルシステムのセキュリティ
次のページ 前のページ 目次へ 5. ファイルとファイルシステムのセキュリティ システムをネットワークに繋ぐ前に少し準備と計画を行うだけで, システムとその中のデータを守るのに役立つでしょう. ユーザのホームディレクトリに SUID/SGID したプログラムを置いて実行させる理由は全くありません. root 以外のユーザが書き込み可能なパーティションに対しては /etc/fstab で nosuid オプションを使いましょう. また, ユーザのホームパーティションや /var では nodev や noexec を使おうと考えるかもしれません. これらのオプションはプログラムの実行や, キャラクタデバイス・ブロックデバイスの作成を禁止します. これらはいずれにせよ必要無いはずです. NFS を用いてファイルシステムをエクスポートしている場合は必ず, アクセスをできる限り厳しく設定してく
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
「失敗」事例を拡充、IPAがWebサイト構築の最新資料を公開
IPAはセキュリティを考慮したWebサイトを作成するための資料「安全なウェブサイトの作り方 改訂第4版」を公開した。 情報処理推進機構（IPA）は1月20日、セキュリティを考慮したWebサイトを作成するための資料の最新版「安全なウェブサイトの作り方 改訂第4版」をWebで公開した（PDF資料）。 同資料は、IPAが届出を受けた脆弱性関連情報を基に、届出件数の多い脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、Webサイト開発者や運営者へセキュリティを考慮したサイトを作成することを目的に提供している。 最新版では、OSコマンドインジェクションやパス名パラメータの未チェック、クロスサイト・リクエスト・フォージェリ、HTTPヘッダ・インジェクションの脆弱性に関する失敗例を追記。Webアプリケーション開発に携わるベンダーでの脆弱性事例を参考に記載した。また、Webアプリケーションファイアウォール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hbstudy# 28 SELinux HandsOn 公開版
