超絶技巧CSRF / Shibuya.XSS techtalk #7CSRF, HTML Form Protocol Attack, Cross-protocol scripting attackについて
Apple vs. FBI、争点となったiPhoneのデータ全消去機能ってなに？
Apple vs. FBI、争点となったiPhoneのデータ全消去機能ってなに？：週末アップルPickUp！ AppleとFBIが、iPhoneのパスコードロック機能をめぐり対立しています。昨年12月に起きたカリフォルニア州サンバーナーディーノの銃乱射事件について、FBI幹部は捜査の重要な手がかりが容疑者のiPhoneに残されている可能性を明らかにしました。 そのため米判事はAppleに対し、パスコード入力ミスによるデータの全消去機能を回避する手段を提供するよう要求。しかしティム・クックCEOは公式書簡を発表し、セキュリティ機能の一部を無効化するツールの提供を拒否しています。 また、FBIからロック解除を要請されたiPhoneは、テロ事件に関連する1台だけではないことが裁判資料から明らかになり、プライバシー保護と国家安全保障をめぐる議論がさらに活発化しています。 このニュースで「iPhon
政府や警察、諜報機関が使っているスパイウェアはiPhoneには通用しない！ - iPhone Mania
国際的な監視技術会社であるGamma Groupから何者かによって漏洩した機密文書によりますと、各国の警察、政府、情報機関などに提供されたFinSpyと呼ばれる監視用マルウエアキットにより、Androidユーザーは知らぬ間に監視の対象になっているようですが、iPhoneユーザーは、「使用制限の解放」をしていなければ、このマルウエアには感染しないようです。 マルウエアにより遠隔操作であらゆる操作が可能に 今回リークされた書類の一部から、FinSpy Mobileと呼ばれるソフトウエアを利用することにより、警察、政府、情報機関は携帯電話やタブレットに遠隔でアクセスし、モニタリングが可能で、以下のすべての操作も可能になるとしています。 ・通話と通信へのアクセス： 電話、SMS、MMSなど ・保存データへのアクセス： 端末とSIMに保存されている連絡先情報 ・端末の監視： 無着信音により架電し、マ
ログ分析勉強会 vol.1 - 資料一覧 - connpass
終了 2015/10/15（木） 19:00〜 ログ分析勉強会 vol.1 セキュリティの陣 kenji kobayashi 他 東京都千代田区平河町2-16-1 平河町森タワー2F
sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました - ろば電子が詰まつてゐる
また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。 今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。 当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。 発表資料 私の発表資料は以下です。 (PDF)攻撃を「隠す」、攻撃から「隠れる」 発表ノート付きなのでPDFです。以下、落穂ひろいなど。 スキャンするポート数と
OSSEC ではじめるセキュリティログ監視 - クックパッド開発者ブログ
インフラストラクチャー部の星 (@kani_b) です。 Heartbleed, ShellShock, XSA-108 (a.k.a. EC2 インスタンス再起動祭), POODLE など、今年は話題となるような脆弱性が各地を襲う一年でした。 脆弱性への対応に加え、いわゆるセキュリティ対策に日頃頭を悩ませている方も多いのではないかと思います。 一言にセキュリティ対策と言っても、実際やるべきことは多岐にわたります。今回はそのうちの一つとして、OSSEC という IDS (侵入検知システム) を使ったセキュリティログ監視についてご紹介します。 OSSEC とは OSSEC は、いわゆるホスト型の IDS (HIDS) です。以下のような機能を持っています。 ログ解析、監視 ファイルの変更監視 rootkit の検知 それらをトリガにしたプログラムの自動実行 (Active Response)
そこそこセキュアなlinuxサーバーを作る - Qiita
先日「サーバーのセキュリティ設定がなにすればいいかわからない」と相談をうけまして。 自分も初心者の時どこまでやればいいかわからず手当たりしだいにやって沼に入っていたのを思い出しながら自鯖構築したときのメモを元にまとめてみました。 注意 セキュリティ対策は用途や場合などによって違います。 自分で理解したうえで自己責任でおねがいします。 対象読者 Linuxのサーバーを建て慣れていない人 Linuxはある程度さわれる人(自分でパッケージを入れたり、サービスを止めたりできる) ラインナップ ☆は導入の重要度と導入の容易さから個人的偏見からつけた値です。 4つ以上が"最低限やること"だと思ってください。 sshd
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
単純ではない、最新「クロスサイトスクリプティング」事情
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
XSS再入門
4. 典型的なXSSサンプルに対する「素朴な疑問」 • クッキーの値がアラートで表示されても、特に危険性はないよ うな気がする • クッキーの値はブラウザのアドオンなどでも表示できるよね • 任意のJavaScriptが実行されると言っても、ホームページ作 れば任意のJavaScriptが書けるし、見た人のブラウザで実行 されるよね… Copyright © 2013 HASH Consulting Corp. 4 5. そもそもの疑問：JavaScriptは危険か? • 実は、JavaScriptの実行自体は危険ではない • Webは、未知の（ひょっとすると悪意のある?）サイトを訪問し ても「悪いこと」が起きないように設計されている • JavaScriptの「サンドボックス」による保護 – JavaScriptからローカルファイルにアクセスできない – JavaScriptからクリップ
IPアドレス・クッキー・JavaScript・UAなどを使わずユーザーを個別に追跡する方法
by Vernon Swanepoel ウェブサイトのユーザーがどれぐらいページを見てくれているのか、訪問頻度はどれぐらいなのかといった情報を追跡するのにはクッキー(Cookie)やJavaScriptなどが使用されますが、そうやって追跡されるのがイヤだということでCookieを受け入れないように設定したり、JavaScriptをオフにしているという人もいるはず。しかし、それでもユーザーを個別に追跡する方法があります。 Lucb1e.com :: Cookieless Cookies http://lucb1e.com/rp/cookielesscookies/ これはオランダ在住でコード・セキュリティ・ネットワークを愛しているというlucb1eさんが明らかにしたもの。手法としては新しいものではなく、多数のサイトで使われているにもかかわらず、そのことを認識している人はほとんどいないというも
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
はてなIDがクッキーで約50サイトに送られていた話 - こせきの技術日記
(追記) 要点を整理をした記事を書きました。こっちのほうが、余計なこと書いてない分、わかりやすいかもしれません。 はてなブックマークに、マイホットエントリーという大変すばらしい機能があって、毎日見ている。 マイホットエントリー機能のご紹介 - はてなブックマーク開発ブログ 自分のマイホットエントリーのURLはこう。 http://b.hatena.ne.jp/koseki/ マイホットエントリーを見ていると、はてなID koseki を含むリファラが各サイトに送信される。 リファラは Google アナリティクスの __utmz に記録される。 Firefox には、全クッキーの値を横断検索する機能がある。 設定 ＞ プライバシー ＞ Cookieを個別に削除 ＞ 検索 自分の環境では、およそ50個*1のクッキーに koseki という文字列が含まれていた。 あんなサイトやこんなサイトを、
iptablesで鉄壁？の守りを実現する3つのTips｜TechRacho by BPS株式会社
iptablesでサーバを守るときに知っておくと良いことを3つ紹介します 1. 接続回数を制限する(IPアドレスごと) hash_limitを使います これにより特定ホストからの大量アクセス、DoS攻撃を緩和することが可能です 例 2. 接続回数を制限する(サービスごと) limitを使って制限します これにより多数のホストからの攻撃、DDoS攻撃を緩和します limitを使った制限は全ホストが等しく制限を受けるため、ssh等に設定すべきではありません。 （攻撃を受けている間は自分たちも制限されるため） Webサーバが大量アクセスで落ちそうな場合は使えるんじゃないでしょうか？ 例 3. 接続IPアドレスを限定する IPアドレスの国別割り当てをAPNIC等から取得してコマンドを作ります この手のルールは長くなるので、ユーザー定義チェインにしたほうが見やすくなります 例 あとはこんな感じのスク
IPAから「クリックジャッキング」に関するレポート出ました
Webアプリケーションのセキュリティの分野で「新しい攻撃手法」は実はそれほど多くないのですが、比較的新しく対応が求められているものとしてクリックジャッキングがあります。クリックジャッキングは、CSRFと同じように「Webアプリケーションのサーバー側機能」を利用者（被害者）に実行させる手法です。CSRFは、当該機能を実行するHTTPリクエストを送信させる罠を使いますが、クリックジャッキングの方は、iframe等に当該機能を呼び出す画面を表示しておき、利用者（被害者）に実行ボタンを押させる（=クリックジャック）手法です。クリックジャッキングに関しては従来詳しい解説がありませんでしたが、この3月26日にIPAから「クリックジャッキング」に関するレポートが公開されました。 このレポートから、クリックジャッキングのイメージを示す図4を引用します。 サイトAが攻撃対象のサイト、悪意のあるページは罠にな
俺史上最強のiptablesをさらす - Qiita
#!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基本的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基本的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基本破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
悲報：アドネットワークがフィッシング行為の片棒をかつぐ時代到来(山本一郎) - 個人 - Yahoo!ニュース
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
