Webアプリケーションセキュリティフォーラム - Journal InTime(2007-07-05)
_ Webアプリケーションセキュリティフォーラム というわけで、発表して来た。 スライド(PDF) スライド原稿(RD) 自分の発表はともかく興味深い話を色々聞けてよかった。 とくに奥さんと高木先生のバトルが面白かった。 追記: リクエストがあったのでバトルの内容について少し。 (曖昧な記憶に基づく再現で言い回しは違うと思うし、内容にも私の勘違いがあるかもしれません。念のため) 高木先生 Greasemonkeyの説明の部分がよく聞こえなかったんですが。 奥さん (内容を説明) 高木先生 ええと、「クッキーが漏洩する程度なので問題ない」と聞こえたような気がしたんですが。 私の心の声 (最初から聞こえてたんじゃ…) 奥さん ローカルファイルにアクセスできたり、任意のコマンドを実行されたりするのに比べれば、ということですね。 高木先生 いや、それは違うと思うんですよ。銀行サイトのクッキーが漏洩
404 Blog Not Found:tips - sshでパスワード無しログイン
2007年09月30日13:30 カテゴリTips tips - sshでパスワード無しログイン 以下に加えて、これも覚えておくといいかも。 odz buffer - SSH の接続を共有する パスワード無しの認証ファイルを作る $ ssh-keygen -d -f ~/.ssh/nopass-dsa -N '' または $ ssh-keygen -d -f ~/.ssh/nopass-dsa -N '' -C you@your.example.com -N ''がポイントです。 前者の場合、ssh commentは$USER@$HOSTになりますが、最近はDHCPでホスト名を決めちゃう場合も多いので、それがいやな場合は後者の方法で決め打ちするのがいいでしょう。 完了すると、~/.ssh/nopass-dsaと、~/.ssh/nopass-dsa.pubの二つのファイルが出来ます。前者は絶
ぼくはまちちゃん！(Hatena) - Port801 (初心者向け)セキュリティ勉強会 Hamachiya2編
こんにちはこんにちは！！ 先日、Twitterで声をかけてもらって、 第一回 Port801 セキュリティ勉強会っていうのに参加してきたよ！！ (↑pw: security) そこで、すこし喋った時のビデオを頂いたので、もったいないので公開しちゃいますね！ プレゼンだとかそういうの慣れてなくて、ぐだぐだな感じだけど、 よかったら何かの参考にしたり、晩ご飯のおかずにしてください＞＜ Port801 セキュリティ勉強会 - Hamachiya2 その1 (http編) Port801 セキュリティ勉強会 - Hamachiya2 その2 (CSRF編1) Port801 セキュリティ勉強会 - Hamachiya2 その3 (CSRF編2) Port801 セキュリティ勉強会 - Hamachiya2 その4 (XSS編1) Port801 セキュリティ勉強会 - Hamachiya2 その5
ssh scp sftp の正しい自動実行方法
Landscape トップページ | < 前の日 2004-11-15 2004-11-17 次の日 2004-11-18 > Landscape - エンジニアのメモ 2004-11-17 ssh scp sftp の正しい自動実行方法 当サイト内を Google 検索できます * ssh scp sftp の正しい自動実行方法この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [ssh] [セキュリティ] scp と sftp について調べていると、正しい自動実行についての文書を見つけた。cron から scp や sftp を自動実行しようと考えている私には役に立つ文書だ。 - 「専用のパスフレーズなしの鍵を作って権限限定」がベスト正しいssh/scpの自動運転は ぴろ日記 http://www.banana-fish.com/~piro/20040609.
Google Hacking Database
Welcome to the Google Hacking Database (GHDB)! We call them 'googledorks': Inept or foolish people as revealed by Google. Whatever you call these fools, you've found the center of the Google Hacking Universe! Stop by our forums to see where the magic happens! Advisories and Vulnerabilities (215 entries) These searches locate vulnerable servers. These searches are often generated from various sec
Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル
« Japanize - IE 系の User JavaScript エンジンに対応しました | メイン | 安全な JSON, 危険な JSON (Cross-site Including?) » 2007年01月04日 クロスサイトのセキュリティモデル あけましておめでとうございます。 昨年、社内で「XMLHttpRequest は何故クロスサイトで使えないのか。画像や SCRIPT タグは使えるのに」という疑問 (というより試問) を耳にしました。おもしろい話なのでブログネタにしようと思っていたのですが、新年早々 GMAIL の事例がスラッシュドットされていたので、自分の現時点での理解をまとめてみることにしました。文書を確認して書いているわけではないので、間違いがあれば指摘してください。また、よい参考文献をご存知の方がいらっしゃいましたら、教えていただければ幸いです。 ウェブブラウザ
クロスドメインでのデータ読み込みを防止するJavaScript ? - snippets from shinichitomita’s journal
GMailのコンタクトリスト漏洩のエントリのついでに。 JSONデータをscriptタグにのせて配信するサービス（JSONPなど）で、限られたサイトのみにしかそのデータを配信しないようにするためには、クライアントが送出してくるリファラ情報を使ってサービスコンシューマとなっているサイトを特定してアクセス制御する方法がある。 この方法はおそらく大部分のクライアント（ブラウザ）に対しては有効で、例えば実際にGoogle MapsなどもそれとAppKeyを組み合わせてサイトを判別しているっぽいのだけど、意図的にリファラ送出を切っているブラウザであったり、あるいはプロキシプログラムなどが自動的にリファラヘッダを除去してしまうようなクライアント環境に対しては無効になってしまう。 ということで、そんなクライアントでもなんとかならないだろうかと考えていたときにちょっと思いついた、もしかしたらこの方法なら許
「攻撃者の“足跡”を探せ」---Windowsレジストリの解析方法：ITpro
自分の管理するシステムが不正アクセスされた場合には，影響範囲や原因を特定するために攻撃者の“痕跡”を調査する必要がある。対象システムがWindowsマシンであれば，レジストリの解析は不可欠。しかしながら通常のログ・ファイルと異なり，レジストリの調査は骨が折れる作業となる。そこで本稿では，不正アクセスを受けたシステムにおけるレジストリの解析方法をまとめた。 なお，Windowsマシンにおける失われやすい情報（揮発性の高いデータ）の証拠保全については以前の記事でまとめているので，そちらを参照していただきたい。 レジストリの分析は容易ではない Windowsマシンが不正アクセスを受けた場合には，通常，以下の3種類のファイルを調査することになる。 （1）Windowsのイベント・ログ （2）各種アプリケーションのログ （3）レジストリ （1）と（2）については，通常の運用においても馴染みが深いので
Latest topics > 拡張機能に電子署名って「必要」なの？ - outsider reflex
Latest topics > 拡張機能に電子署名って「必要」なの？ 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « Firefox 2でタブを縦置きする方法（pure CSS solution） Main フィードバックできるようになって、変わったこと » 拡張機能に電子署名って「必要」なの？ - Nov 15, 2006 Firefoxで拡張機能のインストール時に「この拡張機能は署名されていません」という警告が表示されるけれども、これについて、署名くらい付けろよという話がたまに出る。利用者の安全性を確保するという観点では確かに重要な事だ。けど、現実には、署名付きの拡張機能というのはほとんど無い。それは何故なのか。 署名を付けるには何が必要なん
CSRF対策, Login GeneratorのSession Fixation Attack対策, クッキーのパス, セッションファイルの作成場所 - Journal InTime(2005-07-15)
_ CSRF対策 0.13.0にもCSRF対策のコードはとくにないようだ。 MLの議論を追ってなかったのだが、結局アプリケーション側で対策する べしということだろうか。 まず、ApplicationControllerとApplicationHelperに以下のような記述をしておく。 app/controller/application.rb: class ApplicationController < ActionController::Base private def validate_session if @params[:session_id_validation] == @session.session_id return true else render(:text => SESSION_VALIDATION_FAILED_HTML, :status => "403 Forbi
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
