インターネットに公開するサーバーの基本的なセキュリティ設定 | 774::Blog
定期的にこういう内容を書いて公開している気がする。昔の記事もあるのでそちらを読めばいいのだが、また書く必要性が生じてきたのであらためて書きます。 現代では AWS のようなクラウドや VPS など格安で手軽にインターネット上にサーバーを持てるようになった。しかしインターネットで誰でもアクセスできる環境でサーバーを稼働させるということは、常に人間やロボットの攻撃に晒されるということを同時に意味している。したがって初心者だからだとか、会社の中ではこうやって仕事をしているからといった言い訳は一切通用しない。セキュリティ設定をきちんとしなければ内部への侵入をたやすく許し、思わぬデータの漏洩につながるのである。とはいえセキュリティというのはトレードオフを考慮しなければいくらでも強化できるものでありキリがない。ここでは最低限これだけはやっておこうという現実的な落とし所を提示し、人々への啓蒙をはかるもの
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
パスワードをソルトつきハッシュ化してDBに保存するのがベストプラクティス…とは限らないという話 - kazuhoのメモ置き場
フレームワークの責務とセキュリティ - MugeSoの日記についての感想文です。 世の中にはたくさんの通信プロトコルが存在し、中には、特定の条件でパスワードを含む文字列をハッシュ化した値を検証しなければならないものも含まれています。 例えば、HTTP Digest認証の場合は、MD5("realm:user:password")を保存しておく必要がありますし、APOPの場合は生のパスワードを、CRAM-MD5の場合はMD5("password")を保存しておく必要があったはず。 で、こういった様々なプロトコルに対応可能な認証データベースを準備しようとすると、パスワードを復号可能な方式で保存しておく必要があります*1。 ただ、パスワードを復号可能な方式で保存するとか、開発者あるいは管理者としてやりたくないというのはもちろんそうなので。で、長期的には世の中どこへ向かってるかというと： 選択肢a
IOS Application Security Testing Cheat Sheet - OWASP
This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests. To view the new OWASP Foundation website, please visit https://owasp.org Last revision (mm/dd/yy): 02/16/2019 After an exchange with the leaders of the OWASP Mobile Security Testing Guide (MSTG) project, it was decided to replace the content of this cheat sheet by a reference to the dedicated content on th
Linuxセキュリティの基礎を学べる教科書、LPIが無料配布
オープンソースソフトウェア（OSS）／Linux技術者認定機関のNPO法人、エルピーアイジャパン（LPI-Japan）は10月1日、技術者育成および教育のための教材「Linuxセキュリティ標準教科書（Ver1.0.0）」を公開した。PDF版、EPUB版はWebサイトから無料でダウンロードできる。 Linuxセキュリティ標準教科書は、Linuxにおけるセキュリティを学習／再認識するために最低限必要となる知識が体系的にまとめられたテキスト。PDF版は179ページあり、CentOSをベースとして、Linuxサーバーのセキュリティ基本チェックからiptables、SELinux、ACL、OpenSSHなどのツールの利用法、改ざん／侵入検知、脆弱性チェックなどのノウハウを解説している。セキュアなシステム設計やサーバー構築のスキルを認定する「LPICレベル3 303試験（LPI - 303 Secur
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
他人のCookieを操作する - T.Teradaの日記
脆弱性検査をしていてしばしば出くわすのは、他人のCookieの値を操作できるとXSSやセッション固定等の攻撃が成功するようなWebアプリケーションです。 このようなアプリがあると、業界的には「Cookie Monsterという問題がありまして、、、でも、、、基本的に現状のブラウザではリスクは低いです」みたいな話がされることが多いのではないかと思います。 本日の日記では、それ（Cookie Monster）以外にも状況によっては考慮すべきことがある、という話をしたいと思います（過去の日記でも少し書いた話ですが、もう少しちゃんと書いておこうと思います）。 通信経路上に攻撃者がいる 被害者のブラウザとサーバの通信経路上に、アクティブな攻撃者がいると想定しましょう。 そのような状況では、攻撃者は正規のサーバになりかわってブラウザと通信をしたり、ブラウザと正規のサーバで交わされる通信に介入することが
HTML5関連のセキュリティ情報 - 葉っぱ日記
HTML5に関連したセキュリティの話題で、とりあえずこれまでに話した資料の一覧や、考察した記事。今後もっと増える予定です。「このAPI使う上で気を付けることないの？」みたいなリクエストもあればぜひ言って下さいませ。 JavaScript Security beyond HTML5 (2013-09-20 Developers Summit Kansai 2013) HTML5セキュリティ その1:基礎編、XSS編 (2013-06-13 OWASP Night 6th) Web::Security beyond HTML5 (2012-09-28 YAPC::Asia 2012) HTML5時代のWebセキュリティ (2012-09-15 第5回愛媛情報セキュリティ勉強会) Same-Origin Policy とは何なのか。 - 葉っぱ日記 XMLHttpRequestを使ったCSRF対
phpMyAdminを狙った攻撃観察 - ろば電子が詰まつてゐる
今日は、前々から準備していたセキュリティ勉強会が台風でポシャってしまった。あーあ、せっかく楽しみにしてたのに……最近ツイてないなぁ……。 で、なんだか不完全燃焼気味なので、ちょっと記事を書いてみる。前にちこっと見た、phpMyAdminへのアタック観察記というネタ。 phpMyAdminとは何か まぁ何を今さらという感じだけれども、phpMyAdminとはPHPで書かれたMySQLの管理ツール。GUIで分かりやすくデータベースが操作できるため初心者にとても人気のツールなのだが、残念ながら過去に大量の脆弱性が発見された(いや、現在形で「され続けている」と言った方が良いか)ため、日々世界中から不正アクセスの猛威にさらされている。 というわけで、Webサーバを立てていると、phpMyAdminが入っていないかとかスキャンしにくるアクセスがとても多い。この記事ではその辺のアタックを観察してみる。
安全なPHPアプリケーションの作り方2013
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
Masato Kinugawa Security Blog: たぶんXSSが理由でインターネットがとまった
昔自分が利用者だったサイトのセキュリティ問題(XSS)をいくつか報告していたのですが、おそらくそのリクエストを理由にインターネットが使えなくなりました。プロバイダに接続を止められたのです。 そのサイトで問題をみつけたとき、サービス提供者側の反応を示す兆候がありました。 問題を発見後、しばらくしてアクセスしようとすると、アクセスを拒否されたからです。 サービス提供者には問題を報告し、アクセス拒否についても、一応、今報告してる通りこれは攻撃ではないので誤解なきようよろしくとメール連絡したところ、問題は修正されました。 これで真意は伝わり、アクセスと関連付けられ、アクセス拒否に対する誤解も解決しただろうと思ったのですが、その後急にインターネットが使えない事態にまでなるとはだれが予想できたでしょうか…。(今は携帯の回線を使っています) プロバイダから書面が届き、書面には問題の報告時とほぼ同じ日付に
ApacheのVirtualHostによる高集積Webホスティングでsymlink問題を根本解決する方法について考えた
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 最近、各所でApacheのVirtualHostを利用した高集積ホスティングのセキュリティに関するインシデントが起きています。僕自身、自分の専門の一つがWebサーバのセキュリティなので、他人事には思えず、毎日各所の経過情報を眺めています。また、数社からApacheのセキュリティに関してもいくつか質問を受けたりしており、公に話せるような内容はこのブログでも公開していきたいと思います。 ということで、ApacheのVirtualHostによる高集積Webホスティングにおけるsymlink問題を根本解決するにはどうしたら良いのかを考えました。まずは、静的コンテンツも動的コンテンツのようにファイルのユーザ権限で処理する方法から紹介します。その後、ホス
Apache HTTPD: `Options -FollowSymLinks` は不完全 - ダメ出し Blog
シンボリックリンク攻撃を防ぐための Apache HTTPD モジュールの解説はこちら: Apache HTTPD: mod_allowfileowner https://fumiyas.github.io/apache/mod-allowfileowner.html 背景 ロリポップの共有 Web サービス下のサイト改ざん事件で、 攻撃手法の一つとして 「他ユーザー所有のファイルへのシンボリックリンクを自分のコンテンツディレクトリ下に作り、Apache HTTPD 経由でアクセスする」手順が利用されたらしい。 参考: http://blog.tokumaru.org/2013/09/symlink-attack.html 当社サービス「ロリポップ！レンタルサーバー」ユーザーサイトへの第三者による大規模攻撃について http://lolipop.jp/info/news/4149/#090
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
@PAGESご利用ガイド - 13/08/29 【お詫び】ユーザ情報流出に関するお知らせ【第2報】
いつも@pagesをご利用頂きありがとうございます。 昨日8月28日発表いたしましたとおり、ユーザ用の管理情報が流出したことが確認されております。 このような事態が発生し、ユーザの皆様に多大なご迷惑をおかけすることになりましたことを、深くお詫び申し上げます。 現在、弊社では、ユーザの皆様の情報の流出に関し、 情報流出の原因や経路などについて、 全力を挙げて全容解明に取り組んでおりますが、 現時点までに判明いたしました内容およびこれまでの対応施策などを報告させて頂きます。 ○流出したユーザデータ情報 2013年2月27日午後2時54分時点で@PAGESに登録されているすべてのユーザについての ・ユーザ名 ・パスワード ・メールアドレス ・登録日時 ・登録時のホスト名 ・登録時のIPアドレス ・登録時のユーザーエージェント ・その他のユーザ管理の情報 ※パスワードは平文のまま流出いたしてお
AWS IAMによるセキュリティ・ベストプラクティス（スライド紹介） - ブログ日記
IAM Best Practices from Amazon Web Services AWSのPrincipal Security Solutions ArchitectであるMax Ramsayが、AWS IAMのベストプラクティスを説くスライドの紹介。AWS IAMとは、AWSのサービスやリソースへのアクセスをセキュアに制御するためのサービス。 クラウド･ベンダーはメインとなる仮想サーバー機能やストレージ機能だけではなくて、IAMのような地味ながら極めて重要な機能を提供できることが大切であると個人的には感じている。ところが、IAMがあっても十分に活用されていない場合もあるので、この良スライドを意訳しつつ日本語でサマリーを書いてみる。 最小権限の原則といったセキュリティ管理における常識的な内容を、AWS IAMという機能にマッピングするのが本プレゼンテーションの趣旨なので、実現方法の説
レインボーテーブル – パスワード流出への対策を根本から理解する。 | DevelopersIO
はじめに 先日、Yahooに不正アクセスがあり、ユーザ名とパスワードを抽出しようとするプログラムが見つかったそうです。 そんな事もありまして、今回は少し趣を変えて、レインボーテーブルのお話をしたいと思います。 今まで概念は知っていても使う事がなかった技術ですが、この機会に詳しく知っておくのも良いかと思います。 レインボーテーブルは、ハッシュから平文を得るためのアルゴリズムの一つですが、実際にそのアルゴリズムで使用されるテーブルの事をいうこともあります。 今回はレインボーテーブルというアルゴリズムについて掘り下げて行きたいと思います。 ハッシュと平文のセットのテーブル レインボーテーブルの基本的な考え方は、非常にシンプルで、このハッシュだったら平文はこれですよというのを事前に用意しておきましょうという事です。 例えば人気パスワードランキング2012より、上位5件のパスワードに付いてもしこのハ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
共用サーバにおけるSymlink Attacksによる攻撃とその対策について - さくらインターネット創業日記
GMOグループのクラックわっしょい祭、永江一石氏「クラックされてるよ」→熊谷社長「されてないWPが悪い」→石森大貴氏「侵入経路分かったWP関係ない」 : 市況かぶ全力２階建
XSS再入門
