■ Googleドキュメントの「招待メール」の危険 ことの始まり 先々週の話。1月23日に次の記事が出ていた。 『Google Docs』の設定にご用心：知らないうちに書き換えも？, WIRED VISION, 2009年1月23日 この記事の趣旨は、「Googleスプレッドシート」の共有設定の画面の説明文「Let people edit without signing in」が誤解を招くために、誤って、誰にでも閲覧や編集を許す設定にしてしまいかねないという話である。この画面は、日本語表示では図1の表記となっている。 WIRED VISIONの記事の言い分では、「people」が上の招待メール送信先の人々のことを指すように読めて、下の「プライバシー」設定も変更しないといけないように誤解してしまうという。 そもそも、この機能の意図されている動作はどういうものか。私も試しているうちに一時混乱し
(Last Updated On: )In Session Phishingという興味深いアドバイザリが公開されています。 具体的な記載はありませんが、現在広く利用されているInternet Explorer, Firefox, Safari, ChromeでJavaScriptを利用するとユーザが特定のサイトにログインしていたか判別できるようです。 Recently Trusteer CTO Amit Klein and his research group discovered a vulnerability in the JavaScript engine of all leading browsers – Internet Explorer, Firefox, Safari, and Chrome – which allows a website to check whether
■CSRF - クロスサイトリクエストフォージェリ CSRF - クロスサイトリクエストフォージェリ SpecIII - CSRF - クロスサイトリクエストフォージェリから引用させて頂きます。 CSRFの概略 CSRFはCross Site Request Forgeriesの略です。恥ずかしながら私は最近こういったこういった攻撃方法があることを知りました。日頃のアンテナの低さがバレますね。 CSRFはサイトに対する正規のユーザーの権限を利用した攻撃です。あるサイトのある処理を行うページに正規のユーザーを誘導し、強制的に望まない処理を発生させます。 具体的には記事の編集や削除といった機能を持つページのURLをダミーのリンクに埋め込んで踏ませたり、imgタグのsrcとして指定して知らず知らずのうちにアクセスさせます。特に後者の例ではユーザーが全く気がつかぬうちに攻撃が完了します。攻撃の結果
■ ログイン成功時のリダイレクト先として任意サイトの指定が可能であってはいけない これが「脆弱性」として合意されるかどうかわからなかったが、脅威と対策をまとめてIPAに届け出てみたところ、受理され、当該サイト（複数）は修正された。以下、この問題がどういうもので、どうするべきなのか、はてなのケースを例に書いておく。 4月にこんな話が盛り上がりを見せていた。*1 ソーシャルブックマークユーザーのIDとPASSをいとも簡単に抜き取る手口, ホームページを作る人のネタ帳, 2007年4月6日 Ｂボタンフィッシングとは何？ 記事の最後には私のブログでもおなじみの、はてなブックマークへ追加ボタンや、バザールのブックマークボタン（Ｂボタン）を設置しているブログを最近良く見かける。何気なく私はそれを利用したりしている。（略）『あれ？セッションがきれたのかな』と思い、自分のIDとパスワードを入れてログイン。
なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー
セッション固定化（Session fixation）を調べている時に気づいたのですが、PHPではクエリ文字列内のセッションIDはクッキーとしては出力されないんですね。 良くセッション固定化で例に挙げられるが下のような例です。 攻撃者がセッションID付きURL[http://example.com/?PHPSESSID=abcd]をユーザAに踏ませる ユーザAのセッションが[セッションID=abcd]で生成される。 ユーザAがログインする。 攻撃者が[セッションID=abcd]でアクセスするとユーザAがログイン済みの状態になっており、セッションを乗っ取る事ができる。 これ自体はもちろんそうなのですが、PHPではクエリ文字列に含まれるセッションIDでセッションは生成されますが、クッキーにそのセッションIDは出力されません。（PHP5.2.1のext/session/session.cを見るとそ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
