Code Archive Skip to content Google About Google Privacy Terms
JavaScriptを使ってイントラネット内を外から攻撃する方法:Geekなぺーじ を見て、なるほどと思ったので試してみた。 原理としては「あるURLにアクセスしたことがあるかどうかは、そのURLへのリンクの文字色でチェック出来る」というものだ。 というわけで早速デモページを作ってみた。詳細はソース参照。 デモページ ブラウザによってAタグの文字色のデフォルトが異なるのでCSSで固定化しておくのもポイントかも。 チェックする対象のURLはピンポイントでチェックしてやらなければいけないので、ブラウザの履歴をごそっと抜くようなことは出来ない。 チェックするURLを充実させてやれば何かと活用(悪用)が可能な気がする。 ブラウザ履歴チェックをされない為にはJavascriptを無効にするしかないと思われる。
Greasemonkeyの過去においてのセキュリティ上の問題の解説。 Greasemonkeyだけに限らず、JavaScriptによるユーザ拡張を作成している全ての方に対して一読の価値があるドキュメントだと思われます。 原文:O'Reilly Media - Technology and Business Training Greasemonkeyの共通な落とし穴を避ける Greasemonkeyのセキュリティの歴史があなたの今にどう影響するのか (著) Mark pilgrim "Greasemonkey Hacks"の著者 2005/11/11 昔々、あるところにセキュリティホールがありました。(これは普通のおとぎ話ではないからそのまま読んでください。) Greasemonkeyのアーキテクチャは最初に書かれて以来大幅に変更されてきた。Version0.3は初めて広範囲に人気を得たバー
Fortify、Ajaxのセキュリティ問題に警鐘 (スラッシュドット ジャパン) Gmail で発見された時点で知っとけ>ヲレ、って感じですが。。。今ちょうどこの辺取り掛かろうとしていたところなのでメモ。 原理としては、そのまんま eval する前提で生 JSON を吐き出す CGI を作ってしまうと、Setter を利用したマリシャスコードを設置した悪意あるサイトへ誘導することによって、JSON による通信内容を横取りできちゃうかもしれないよ、というもの。マリシャスコードのコード例は、たとえば以下のような感じかしら? (とか言いながら、試してないのでもしかしたら動かないかも知れんが。。。つか、setter = 式だからこそ書けちゃうものなのかなぁ?) <script> Object.__defineSetter__("email", function(x) { var objstr =
aSSLの動作の仕組み 執筆現在における最新版は8日(米国時間)にリリースされたaSSL ver 1.2 beta3。同バージョンにおける基本的な通信確立手順は次のとおり。 クライアントからサーバへ接続確立要求 サーバからクライアントへRSAモジュール(公開鍵)および暗号化指数を送信 クライアント側でサーバの公開鍵および暗号化指数を使ってランダムな128ビットの交換鍵を生成 クライアントから交換鍵をサーバへ送信 サーバ側で自身の秘密鍵を使って交換鍵を復元 サーバ側で通信可能を確認したら、サーバからセッション継続時間をクライアントへ送信 クライアントがセッション継続時間を受け取ったら接続保持時間を設定 接続が確立したあとは、aSSLを経由したサーバクライアント間の通信はAESアルゴリズムを使って暗号化が実施される。暗号化通信を開始するまでのネゴシエーションはシンプルでわかりやすいものだ。 H
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く