ssh にてパスワードを使用しないでログインする方法
ssh(Secure Shell)を導入しているホスト間でパスワードを入力せずにログインすること を可能にする方法を解説します。 【概要】 ssh は、接続先によって使用する protocol version が決定されます。 バージョンにより、設定方法が異なりますので、ご注意ください。 Turbolinux Server 6.5 より、version 2 が優先的に利用されています。 ssh の protocol version 1 は、ログイン時にRSA認証を行います。 そのために、事前に ssh-keygen を実行し、RSA キーの組を作成しておきます。 ssh-keygen を実行すると、プライベートキーは~/.ssh/identity に、 公開キーは ~/.ssh/identity.pub に作成されます。 この identity.pub を、リモートマシンの ~/.ssh/
Greasemonkeyの共通な落とし穴を避ける - minghaiの日記
Greasemonkeyの過去においてのセキュリティ上の問題の解説。 Greasemonkeyだけに限らず、JavaScriptによるユーザ拡張を作成している全ての方に対して一読の価値があるドキュメントだと思われます。 原文：O'Reilly Media - Technology and Business Training Greasemonkeyの共通な落とし穴を避ける Greasemonkeyのセキュリティの歴史があなたの今にどう影響するのか (著) Mark pilgrim "Greasemonkey Hacks"の著者 2005/11/11 昔々、あるところにセキュリティホールがありました。（これは普通のおとぎ話ではないからそのまま読んでください。） Greasemonkeyのアーキテクチャは最初に書かれて以来大幅に変更されてきた。Version0.3は初めて広範囲に人気を得たバー
yohgaki's blog - いろいろ変わったXSSがありますが...
(Last Updated On: 2007年10月12日)私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、ECMAScriptにXML機能を追加したのはどうなんでしょうね…. 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。 <script> 123[”+<_>ev</_>+<_>al</_>](”+<_>aler</_>+<_>t</_>+<_>(1)</_>); </script> 好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。 日本語訳 http://www.ne.jp/asahi/nanto/moon/specs/ecma-357.html 原文 http://www.ecma-international.org/pu
ここギコ！: 携帯サイトで位置情報の詐称を許さない方法
Web2.0ワークショップで紹介したように、様々なケータイやPHSでユーザの現在位置が取れるようになってきていて、それを使っていろいろアプリケーションが作れるようになってきている。 その中には、実用アプリだけでなく、私も前管理人をしていたアンテナ奪取や、ケータイ国盗り合戦、Ittemiaのようなエンタメアプリも考えられるわけですが、その際に問題になってくるのが「現在位置の詐称」問題です。 ケータイ、PHSでの位置取得は、SoftBank簡易位置情報のようにHTTPヘッダ、DoCoMoのiエリアのようにPOST等で返ってくる場合もありますが、多くの場合、GETのクエリストリングとして返ってきます。 なので、一旦URLを得てしまえば、クエリストリング中の経緯度を書き換えさえすれば、簡単に詐称できてしまうのです。 実用アプリならば、飽くまで位置情報はユーザの調べる位置を現在位置とするため
Atom や RDF を利用したXSS - 葉っぱ日記
Internet Explorer の悪名高い Content-Type: 無視という仕様を利用すると、Atom や RDF/RSS を利用してXSSを発生できることがあります。条件的に対象となるWebアプリケーションは多くはないと思いますが、それでもいくつか該当するWebアプリケーションが実在することを確認しました。以下の例では Atom の場合について書いていますが RDF/RSS でも同様です。 例えば、http://example.com/search.cgi?output=atom&q=abcd という URL にアクセスすると、「abcd」という文字列の検索結果を Atom として返すCGIがあったとします。 GET /search.cgi?output=atom&q=abcd Host: example.com HTTP/1.1 200 OK Content-Type: ap
迷惑メールを「削除」してはいけない - ワークスタイル - nikkei BPnet
迷惑メールを「削除」してはいけない （須藤 慎一＝ライター） 迷惑メールを識別して、「迷惑メールフォルダ」に自動的に振り分ける機能の付いたメールソフトを使っている人は多いだろう。このとき、迷惑メールフォルダにたまった迷惑メールを、無意識に「削除」していないだろうか？ この操作はやめなければいけない。迷惑メールフォルダが備えている安全対策機能を無にしてしまうからだ。 「受信トレイ」を未処理メールの保管場所として使い、処理を済ませたら「削除」する。こういうメール整理術を採用している人がとくに危ない。このタイプの人は、過去メールが必要なったとき、「削除済みアイテム」を探すことが多いからだ。 削除済みアイテムは、迷惑メールフォルダほど安全対策が徹底していない。迷惑メールをかき分けながら必要なメールを探すとき、ついうっかり迷惑メールを見る（開く、あるいはプレビューする）というのはマズいこと
Kazuho@Cybozu Labs: クロスサイトのセキュリティモデル
« Japanize - IE 系の User JavaScript エンジンに対応しました | メイン | 安全な JSON, 危険な JSON (Cross-site Including?) » 2007年01月04日 クロスサイトのセキュリティモデル あけましておめでとうございます。 昨年、社内で「XMLHttpRequest は何故クロスサイトで使えないのか。画像や SCRIPT タグは使えるのに」という疑問 (というより試問) を耳にしました。おもしろい話なのでブログネタにしようと思っていたのですが、新年早々 GMAIL の事例がスラッシュドットされていたので、自分の現時点での理解をまとめてみることにしました。文書を確認して書いているわけではないので、間違いがあれば指摘してください。また、よい参考文献をご存知の方がいらっしゃいましたら、教えていただければ幸いです。 ウェブブラウザ
T.Teradaの日記 - ログイン直後のレスポンスの返し方
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう？というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して（HTTP1.1では303応答）、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
PHPセキュリティチェックリスト:phpspot開発日誌
Checklist for Securing PHP Configuration | Ayman Hourieh's Blog Inside is a check list of settings that are intended to harden the default PHP installation.PHPセキュリティチェックリスト。 PHPの設定ファイルによってはセキュリティ的によろしくない場合もよくあることなので、そのチェックを行うためのリスト。 allow_url_fopen、register_globals など、一連のphp.iniに関する設定のチェックする際に役立ちます。
PHPで安全なセッション管理を実現する方法
_ 残り容量が数十Mバイトになっていた PCがなんかくそ遅いなーと思ってふと空きディスク容量をみたら、残り数十Mバイトまで減っていた。Folder Size for Windowsで各ディレクトリ単位のディスク使用量をながめてみたところ、 Thunderbirdでimapでアクセスしているアカウントのデータフォルダに、なぜか1GバイトオーバーのINBOXファイルがあった。なにこれ？ 削除したけど別に動作には支障はなし。 puttyのlogが無限に追記されたよ……。数Gバイト。 昔ダウンロードしたCD/DVD-ROMのisoイメージファイルが、そこかしこに消されず残ってたよ。10Gバイトオーバー。 あと、細かいテンポラリディレクトリの中身とか消したら、30Gバイトくらい空いた。そこまでやって久しぶりにデフラグを起動したら、表示が真っ赤（ほとんど全部断片化されている）だったので、最適化実行中。
【PHPカンファレンス2006】PHPで書かれた実際のアプリケーションに潜む危険なコード
「（PHPで書かれたアプリケーションには）アバウトなコードが多い」。エレクトロニック・サービス・イニシアチブの大垣靖男社長は，2006年8月19日に開催されたPHP関連イベント「PHPカンファレンス2006」の講演「危険なコード」で，PHPで書かれたアプリケーションに存在する危険なコードを指摘した。講演の中では，実際に存在するアプリケーションの名前を出し，そのソースコードからセキュリティ上危険な個所を挙げていった。「安全なコードを書くには悪い例も知っておかなければならない」というのが同氏の主張である。 大垣氏はまず，「セキュリティのリスクはサブシステムとの境界の部分で発生する」と指摘した。サブシステムとは，データベース，メール・システム，ユーザーのWebブラウザといった外部のシステムのこと。「境界で入力時にきちんとバリデーション，出力時にきちんとエスケープ処理（フィルタリング）を行えば，か
XSS - 表示系パラメータに存在する盲点 :: ぼくはまちちゃん！
こんにちはこんにちは！！ クロスサイトスクリプティングの時間です！ XSSというと…！ まっさきに思いつくのが、入力データ送信 → 確認表示の部分での無害化漏れですよね！ たとえばこんな感じのフォームから受け取ったパラメータを、 確認として表示するページとか！ (入力) <form action="register.cgi" method="post"> タイトル：<input type="text" name="title"> ← 「ぼくはまちちゃん！」を入力 本文：<input type="text" name="body"> ← 「こんにちはこんにちは！！<script>alert(1)</script>」を入力 </form> (確認) <p>この内容で登録していい？</p> <p> タイトル： ぼくはまちちゃん！<br> 本文： こんにちはこんにちは！！<script>alert
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
俺の「パスワード：*****」って何でしたっけ？ ― ＠IT
俺の「パスワード：*****」って何でしたっけ？ ～アプリケーションのパスワード調査編～：ツールを使ってネットワーク管理（5）（1/6 ページ） パスワード再発行ばかりが仕事じゃない 律子さんの会社では、基本的に1人1台マシンが支給されているのですが、プロジェクトの都合やリース期間切れなどで、意外と頻繁にマシンの変更が行われます。 そんなこともあってデータの移動は手慣れたものですが、つい忘れてしまうものがあります。パスワードです。 特にメールのパスワードなんかは最初に管理者に渡されたものを設定して（設定さえ管理者に任せっ切りの人もいますが）、それをアプリケーションに記憶させている人がたくさんいます。もちろんそういう人はマシンを移動するときにはパスワードは頭の中からすっかり抜け落ちているのです。一度しか打ち込んでいないので仕方ありませんが、そういう人に限って、なぜか渡されたパスワードが書かれ
セキュリティレベルの高いサイトを構築する 22 カ条 :: Drk7jp:
最近、何処の会社でもセキュリティに関してうるさく言われているかと思います。自分としても今まで気を遣ってきていたつもりではあります。しかしながら、 なぜSSL利用をケチるのか：IT Pro SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも 安全なWebサイト設計の注意点 を読んでみて、お恥ずかしい限りですが勘違いしていた部分もありました。実際、Amazon とか Yahoo! のログイン画面を見ても、デフォルトが http によるアクセスになっていたりして、メジャーどころでも最新の注意が払われている訳ではないのだなぁ〜と思ったり・・・。本当は全ページ SSL が理想とは知りつつも、SSL の処理負荷の高さ故に、ついついケチったページ遷移にしまうからなのでしょう。。。自分含めて。 自分への情報もかねて、上記ページに記載されている、31箇条の鉄則と最近の事情を加
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[openmya:035806] IE における "expression" の過剰検出による XSS の 誘因
はてな外のサイトからはてなダイアリーが閲覧できていた件につきまして - はてなダイアリー日記