おそらくは前回のXSSのあとで機能追加されたリンクだと思う。
cnnでWeb検索してからMapsに移動すると、「Search the web for cnn」というリンクが左側に表示される。
このリンクのhrefがシングルクォート(')でくくられていた。
しかも前回見つけた「必要なのかどうかわからない機能」がこのリンクで発動していた。
前回は同じサービス内のリンクでのみ発動したので、なんでここだけ?と不思議に思ったが同じ手口であっさり通った。
成功して報告したあとに気づいたが、このリンク実は普通にqパラメータにシングルクォート入れるだけでhrefを終わらせることができていた。しかしへんな文字を入れるとすぐにこのリンク自体が表示されなくなってしまう。
がんばれば普通にXSSできるのではないか?と思ってORでつなげたりしてみたが、残念ながらイコール(=)がエンコード(%3D)されてしまった。
ひょっとしてこれ、気づいている人はたくさんいて、攻めあぐねていたんじゃないだろうか?
2011年7月13日水曜日
2011年4月28日木曜日
sendmailでGmailみたいに複数アドレス使えるようにする方法
Gmailではメールアドレスのアカウント部分に+(プラス)文字を入れると、それ以降の文字列が無視されて、複数アドレスが使えるっていう機能がある。
つまりhoge@gmail.comっていうアドレスを持っていれば、hoge+moge@gmail.comでもhoge@gmail.comで受け取れるというもの。
例えば、この機能を利用して登録サイト毎にメールアドレスを変えておけば、メールアドレスが漏洩してダイレクトメールが来るようになったときに、どのサイトから漏れたかがわかる。
ってこんなの自宅サーバでも会社でも、とっくの昔にやってたぜってことでその設定方法を紹介しておく。ただし、うちのやり方ではデリミタは+(プラス)ではなく.(ドット)。
/etc/mail/sendmail.cfに次のような行がある。
あとローカル上でのアカウント部だけの判定部分
要は「regular local names」ってコメントされている行の上に、パターンに「. $+」を追加したルールを増やせばよい。
で、sendmailを再起動するなりSIGHUPを送るなりすれば、
hoge.moge@hoge.jpもhoge.psn@hoge.jpもhoge@hoge.jpに送られるようになる。
つまりhoge@gmail.comっていうアドレスを持っていれば、hoge+moge@gmail.comでもhoge@gmail.comで受け取れるというもの。
例えば、この機能を利用して登録サイト毎にメールアドレスを変えておけば、メールアドレスが漏洩してダイレクトメールが来るようになったときに、どのサイトから漏れたかがわかる。
ってこんなの自宅サーバでも会社でも、とっくの昔にやってたぜってことでその設定方法を紹介しておく。ただし、うちのやり方ではデリミタは+(プラス)ではなく.(ドット)。
/etc/mail/sendmail.cfに次のような行がある。
R$+ < @ $=w . > $#local $: $1 regular local name
これは、ホスト/ドメイン名付きのメールアドレスをローカル判定する部分なので、この上に
R$+ . $+ < @ $=w . > $#local $: $1 regular local name
という行を追加。あとローカル上でのアカウント部だけの判定部分
R$+ $#local $: $1 regular local names
っていう行があるので、同様にこの上に
R$+ . $+ $#local $: $1 regular local names
という行を追加する。要は「regular local names」ってコメントされている行の上に、パターンに「. $+」を追加したルールを増やせばよい。
で、sendmailを再起動するなりSIGHUPを送るなりすれば、
hoge.moge@hoge.jpもhoge.psn@hoge.jpもhoge@hoge.jpに送られるようになる。
※当然だが、sendmail.mcからsendmail.cfを新たに生成した場合、この修正は上書きされる。
2011年4月2日土曜日
Ubuntu10.10にGNU Prolog1.3.1
今時GNU Prologのインストールなんて「Ubuntuソフトウェアセンター」でバイナリをダウンロードすればいいだけの話だが、昔ながらのUNIXプログラマはソースからコンパイルするのです。
gplc -c --fast-math fd2c.pl
fd2c.pl:215-220: fatal error: exception raised: error(instantiation_error,sort/2)
compilation failed
make[1]: *** [fd2c.o] エラー 1
だめじゃん。orz...
このエラーメッセージそのままコピペしてぐぐったら、すぐにこのページが引っかかった。
http://comments.gmane.org/gmane.comp.gnu.prolog.general/1170
ってことで、
./configure --with-c-flags='-O3 -fomit-frame-pointer -fno-strict-aliasing'
でコンパイルは通る。
gplc -c --fast-math fd2c.pl
fd2c.pl:215-220: fatal error: exception raised: error(instantiation_error,sort/2)
compilation failed
make[1]: *** [fd2c.o] エラー 1
だめじゃん。orz...
このエラーメッセージそのままコピペしてぐぐったら、すぐにこのページが引っかかった。
http://comments.gmane.org/gmane.comp.gnu.prolog.general/1170
ってことで、
./configure --with-c-flags='-O3 -fomit-frame-pointer -fno-strict-aliasing'
でコンパイルは通る。
2011年3月18日金曜日
RTA55iでPPTPパススルー
もう古い機種だからか、「RTA55i+VPNパススルー」で検索してもなかなか情報がなく、「RTA55i+PPTPパススルー」でようやく参考になるページを見つけた。
http://blog.goo.ne.jp/takuminews/e/b0278679e6c849b8a7c16710e4230dd6
これを参考に、「付加機能」→「ファイアウォール機能」で、「表示インターフェース」を「WANポート(LAN2)」に切り替えて、「静的フィルタの設定」でフィルタ追加。
フィルタ:pass(ログなし)
プロトコル:gre
送信元IPアドレス:PPTP接続先のグローバルアドレス
受信先IPアドレス:内部ローカルアドレス(192.168.100.0/24)
送信元ポート番号、受信先ポート番号:*
フィルタ番号40で追加後、「適用」の「入」にチェックを入れて「静的フィルタと動的フィルタの適用」の「適用」クリック。
ファームウェアのリビジョンは、Rev.4.06.67。
http://blog.goo.ne.jp/takuminews/e/b0278679e6c849b8a7c16710e4230dd6
これを参考に、「付加機能」→「ファイアウォール機能」で、「表示インターフェース」を「WANポート(LAN2)」に切り替えて、「静的フィルタの設定」でフィルタ追加。
フィルタ:pass(ログなし)
プロトコル:gre
送信元IPアドレス:PPTP接続先のグローバルアドレス
受信先IPアドレス:内部ローカルアドレス(192.168.100.0/24)
送信元ポート番号、受信先ポート番号:*
フィルタ番号40で追加後、「適用」の「入」にチェックを入れて「静的フィルタと動的フィルタの適用」の「適用」クリック。
ファームウェアのリビジョンは、Rev.4.06.67。
2011年3月7日月曜日
2011年2月24日木曜日
CentOS5.5にmod-chxj_0.12.37
結構ハマったわりにはネット上に情報がないので、書いておく。
前提は、openssl, apacheはソースからコンパイルしたものを使い、それぞれopenssl0.9.8oが/home/opensslに、apache2.2.16が/home/httpdにインストールされている。
あちこちで書かれている前提パッケージはすでにインストール済みとする。
まず引っかかったのは、make。
$ ./configure \
> --with-apache-header=/home/httpd/include \
> --with-apxs=/home/httpd/bin/apxs \
> --with-apr-config=/home/httpd/bin/apr-1-config \
> --with-apu-config=/home/httpd/bin/apu-1-config \
> --with-openssl=/home/openssl
でconfigureするとmakeで、
(cd serf; CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure --enable-shared --with-apr=`dirname /home/httpd/bin/apr-1-config` --with-apr-util=`dirname /home/httpd/bin/apu-1-config` --with-openssl /home/openssl; make)
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: /home/openssl
checking for chosen layout... Serf
checking for working mkdir -p... yes
checking build system type... Invalid configuration `/home/openssl': machine `/home/openssl' not recognized
configure: error: /bin/sh build/config.sub /home/openssl failed
なんで/home/opensslでinavlid host typeとか言われるんだ?と思ってよく見てみると、src/serfの下でconfigureやってて、--with-opensslと/home/opensslの間に=がない。
直接src/Makefileの該当個所を変更して、コンパイルは通った。
インストールしてapacheを再起動すると今度は、
# ./apachectl restart
httpd: Syntax error on line 427 of /home/httpd/conf/httpd.conf: Cannot load /home/httpd/modules/mod_chxj.so into server: /home/httpd/modules/mod_chxj.so: undefined symbol: libiconv
0.8.5のインストール手順を参考にしてlibiconvをソースから入れたのがいけなかったらしく、最新はlibiconvは必要ないとのこと。
/usr/local/libの下のlibiconv関係のライブラリ(3つ)削除、/usr/local/includeの下のiconv関係のヘッダ(3つ)削除して、configureからやり直して、起動できた。
前提は、openssl, apacheはソースからコンパイルしたものを使い、それぞれopenssl0.9.8oが/home/opensslに、apache2.2.16が/home/httpdにインストールされている。
あちこちで書かれている前提パッケージはすでにインストール済みとする。
まず引っかかったのは、make。
$ ./configure \
> --with-apache-header=/home/httpd/include \
> --with-apxs=/home/httpd/bin/apxs \
> --with-apr-config=/home/httpd/bin/apr-1-config \
> --with-apu-config=/home/httpd/bin/apu-1-config \
> --with-openssl=/home/openssl
でconfigureするとmakeで、
(cd serf; CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure --enable-shared --with-apr=`dirname /home/httpd/bin/apr-1-config` --with-apr-util=`dirname /home/httpd/bin/apu-1-config` --with-openssl /home/openssl; make)
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: /home/openssl
checking for chosen layout... Serf
checking for working mkdir -p... yes
checking build system type... Invalid configuration `/home/openssl': machine `/home/openssl' not recognized
configure: error: /bin/sh build/config.sub /home/openssl failed
なんで/home/opensslでinavlid host typeとか言われるんだ?と思ってよく見てみると、src/serfの下でconfigureやってて、--with-opensslと/home/opensslの間に=がない。
直接src/Makefileの該当個所を変更して、コンパイルは通った。
インストールしてapacheを再起動すると今度は、
# ./apachectl restart
httpd: Syntax error on line 427 of /home/httpd/conf/httpd.conf: Cannot load /home/httpd/modules/mod_chxj.so into server: /home/httpd/modules/mod_chxj.so: undefined symbol: libiconv
0.8.5のインストール手順を参考にしてlibiconvをソースから入れたのがいけなかったらしく、最新はlibiconvは必要ないとのこと。
/usr/local/libの下のlibiconv関係のライブラリ(3つ)削除、/usr/local/includeの下のiconv関係のヘッダ(3つ)削除して、configureからやり直して、起動できた。
2011年2月1日火曜日
グーグル脆弱性報奨プログラム(まとめ) - グーグルからお金をもらう
今回は「ですます」調で。
日本語のセキュリティのページに書かれていないので、日本では気付いている人が少ないのかもしれません。
Googleでは昨年の11月から脆弱性報奨プログラム(Vulnerability Reward Program)というのをやっていて、同社のサービスに脆弱性を見つけて報告すると、報奨として$500から$3,133.7もらえます。
今後続く方のために、私がXSSを見つけた時の経緯を書いておきます。
最初、ショッピングにXSSを見つけて、すぐにSecurity Team(security@google.com)にメールしました。最初に見つけたものは、ページ表示後ユーザの操作によってスクリプトが動くものでしたが、その後同じサービス内の別のページで、ページ表示時点ですぐにスクリプトが動くものを見つけました。
この時点ではまだ、バグの管理番号が割り振られていませんでしたが、その後他のサービスで同じバグを見つけ、そのとき初めてちゃんとしたリストを作成し、管理番号の入ったサブジェクトのメールに返信しました。
これがちょっとしたトラブルの元になったようです。どうやら共通のバグであっても、サービス毎に管理しているようで、ショッピング以外のバグが見落とされそうになったそうです。
現に私の見つけたXSSは複数のサービスに共通にありましたが、報奨については別のバグとしてカウントされました。
しかも、共通で使われているフレームワークに元々の問題がありそうなので、すべてのサービスで共通に対応するだろうと思っていましたが、直し方はサービス毎にばらばらでした。
ですので、共通に存在するバグを見つけても、サービス毎に別のバグとして報告したほうがよさそうです。また一度報告してしまえば開発者は同じサービス内のその他の部分に気付くでしょうから、同じサービスをひと通り調べてから報告したほうが、とりっぱくれを少なくできると思います。彼らとしてもちまちま報告されるよりは、ある程度まとめてからの方が助かるでしょう。
報奨を受け取るには、
1.USDを受け取れる銀行に口座を持つ。
2.Googleのページでサプライヤ登録する。
3.W8-BEN form(米国源泉税を免除してもらうための書類)を作成、提出する。
ことが必要になります。これらはすべてメールで指示してもらえます。
1.については私の場合、もともとソニー銀行に口座を持っていたので、ここに振りこんでもらいました。
振りこんでもらうにあたり、銀行から被仕向送金手数料を取られます。ソニー銀行の場合$25なので、もし最低額の$500だと5%を取られることになります。私の場合2回に分けて振り込まれましたが、初回は被仕向手数料無料キャンペーン中だったので、1%で済みました。
2.は書くべき項目をメールで教えてもらえますが、受け取り口座は自分で調べて書く必要があります。私の場合不備があったようで、メールで足りない情報を確認されました。
受け取り銀行のSWIFTコード、中継銀行がある場合は中継銀行のSWIFTコードも必須のようです。ソニー銀行の場合、必要な情報はこのページに書いてあります。
3.は、ぐぐればフォーマットのPDFや書き込み例が出てきますので、特に問題ないと思います。
そして、バグが修正されて振込み手続きがひと通り完了したら、バグ情報をBlogに書いたりつぶやいていいそうです。
また、Google Security Hall of Fameページ(セキュリティの殿堂ページ?)に名前が載ります。どう書くか、どこにリンクさせるかは指定した通りにやってもらえました。
報奨を受け取られた他の方のご意見おまちしております。
日本語のセキュリティのページに書かれていないので、日本では気付いている人が少ないのかもしれません。
Googleでは昨年の11月から脆弱性報奨プログラム(Vulnerability Reward Program)というのをやっていて、同社のサービスに脆弱性を見つけて報告すると、報奨として$500から$3,133.7もらえます。
今後続く方のために、私がXSSを見つけた時の経緯を書いておきます。
最初、ショッピングにXSSを見つけて、すぐにSecurity Team(security@google.com)にメールしました。最初に見つけたものは、ページ表示後ユーザの操作によってスクリプトが動くものでしたが、その後同じサービス内の別のページで、ページ表示時点ですぐにスクリプトが動くものを見つけました。
この時点ではまだ、バグの管理番号が割り振られていませんでしたが、その後他のサービスで同じバグを見つけ、そのとき初めてちゃんとしたリストを作成し、管理番号の入ったサブジェクトのメールに返信しました。
これがちょっとしたトラブルの元になったようです。どうやら共通のバグであっても、サービス毎に管理しているようで、ショッピング以外のバグが見落とされそうになったそうです。
現に私の見つけたXSSは複数のサービスに共通にありましたが、報奨については別のバグとしてカウントされました。
しかも、共通で使われているフレームワークに元々の問題がありそうなので、すべてのサービスで共通に対応するだろうと思っていましたが、直し方はサービス毎にばらばらでした。
ですので、共通に存在するバグを見つけても、サービス毎に別のバグとして報告したほうがよさそうです。また一度報告してしまえば開発者は同じサービス内のその他の部分に気付くでしょうから、同じサービスをひと通り調べてから報告したほうが、とりっぱくれを少なくできると思います。彼らとしてもちまちま報告されるよりは、ある程度まとめてからの方が助かるでしょう。
報奨を受け取るには、
1.USDを受け取れる銀行に口座を持つ。
2.Googleのページでサプライヤ登録する。
3.W8-BEN form(米国源泉税を免除してもらうための書類)を作成、提出する。
ことが必要になります。これらはすべてメールで指示してもらえます。
1.については私の場合、もともとソニー銀行に口座を持っていたので、ここに振りこんでもらいました。
振りこんでもらうにあたり、銀行から被仕向送金手数料を取られます。ソニー銀行の場合$25なので、もし最低額の$500だと5%を取られることになります。私の場合2回に分けて振り込まれましたが、初回は被仕向手数料無料キャンペーン中だったので、1%で済みました。
2.は書くべき項目をメールで教えてもらえますが、受け取り口座は自分で調べて書く必要があります。私の場合不備があったようで、メールで足りない情報を確認されました。
受け取り銀行のSWIFTコード、中継銀行がある場合は中継銀行のSWIFTコードも必須のようです。ソニー銀行の場合、必要な情報はこのページに書いてあります。
3.は、ぐぐればフォーマットのPDFや書き込み例が出てきますので、特に問題ないと思います。
そして、バグが修正されて振込み手続きがひと通り完了したら、バグ情報をBlogに書いたりつぶやいていいそうです。
また、Google Security Hall of Fameページ(セキュリティの殿堂ページ?)に名前が載ります。どう書くか、どこにリンクさせるかは指定した通りにやってもらえました。
報奨を受け取られた他の方のご意見おまちしております。
登録:
投稿 (Atom)

