仮想空間も、サブプライム問題なの？。。。

ここの記事
三重県いなべ市がセカンドライフ内に開設した支所が突然閉鎖、委託業者と連絡取れず
http://slashdot.jp/it/09/02/27/0121229.shtml
（以下斜体は上記サイトより引用）

伊勢新聞の報ずるところによれば、昨年1月に三重県いなべ市がセカンドライフ内に開設した支所が、同年末に突然閉鎖されていたことが明らかとなりました。

市では、「昨年末、運営委託先の業者から突然サービスを打ち切られた。業者とは連絡が取れておらず、打ち切りの経緯については全く分からない。今後、セカンドライフに参加している他の自治体に連絡を取り、情報収集に努めたい」(担当部長)と説明していますが、支所の開設に反対していた市民は市監査委員に対し、既に住民監査請求を行っている模様です。


委託業者が。。。という話らしいけど、
こんなところにも、サブプライムの影響？？

これだけじゃなく、Ｗｅｂ制作やデータ管理を他社に任せていた場合、その会社がおかしくなると・・・
っていう話は、今後も増えそうですよね。

UNIXの権限とパーミション（の脆弱性）

きのう、Ｃ／Ｃ＋＋セキュアコーディング　ハーフデイキャンプPart2 File I/Oに行ってきたので、その内容について。

　３部構成にわかれていて

１、UNIXの権限とパーミション
２、ファイルシステムの脆弱性
３．ファイル入出力と競合状態

　となっていました。ここではまず、「１、UNIXの権限とパーミション」について、ポイントをメモメモ

---

■脆弱性対策の原則

・最小権限の原則
　必要なくなったら、権限を落とす

・権限を分離

---

■パーミッションについて
大きく２つの話題
・プロセス権限
・ファイル管理

●プロセス権限
・プロセスＩＤには、
　　「実ユーザーＩＤ］，
　　「実行ユーザーＩＤ］，
　　「ＳＳＵＩＤ」（いったん保持用）
　の３つがある

・権限を変えたいときはsetresuid()で、３つを
　明示的に変えたほうがいい
　　→理由説明すると長くなるので省略
・ただ、solarisでは、それができないので、
　その場合、seteuidを使うのがいい

・適切なsetuid
　→必要なくうなったら、権限を落とす

●ファイル管理
・セキュアなディレクトリ
　所有者＆管理者以外は、ファイル作成、リネーム、削除
　できないようにしておく

・ファイル名でアクセスするより、fdやFILE構造体など
　実体を使うほうがいい
　　→ファイル名は悪意あるユーザーに書き換えられる危険性アリ

・fopenする「前に」umaskを使う
　→ファイル作成後、chmodすると、ファイル作成後、
　　悪意あるユーザーにファイル名を書き換えられる危険性アリ

---

■そのた

・ステッキービットＯＮ
　ファイル所有者のみ削除可能

・wall　端末に書き込めるプログラム
　　→readは、覗き見されないように権限を落としてる

・postfixのソースを見ると、参考になる。

「竹島の日」に関連？島根県ＨＰにアクセス６５０万回、韓国ＩＰアドレス

ここのニュース
島根県ＨＰにアクセス６５０万回　韓国ＩＰアドレス
http://www.asahi.com/national/update/0226/OSK200902260069.html
（以下斜体は上記サイトより引用）

　島根県は２６日、県のホームページ（ＨＰ）が同日午後２時ごろから約２０分間にわたり約６５０万回のアクセスが集中し、閲覧しにくい状態になったと発表した。

　県情報政策課によると、韓国のプロバイダーに割り当てられた１０個のＩＰアドレスからのアクセスで、これらの通信を遮断して復旧した。


なんという分かりやすい攻撃（＾＾；）


今月２２日には県などが主催する「竹島の日」の記念式典があった。同課の担当者は「ＩＰアドレスは偽装できるので、現時点で竹島問題との関連は分からない」と話している。


こんなに分かりやすいと、逆に、ほんとに韓国から？って疑っちゃうよね。
「竹島の日」の抗議のように見せて、実は・・みたいな・・・

WAFをリバースプロキシでやった場合、リバースプロキシが倒れたら？

今日、Ｃ／Ｃ＋＋のセキュアコーディングの話を聞いてきて
（今度、レポートします。その内容）

そこで、ファイルアクセスにおけるぜい弱性の話を聞いてきた。

つまり、ファイル名をユーザーにいれてもらうと、ふつうは
foo.xml
のように、素直に、ファイル名をいれると想定しちゃうけど、ここに

../../../../../etc/passwd

とかかいて、思いもよらないところにアクセスして、ファイルを書きだしてしまう
危険があるというはなし。

これを防ぐには、ファイルのパスを正規化(canonicalization)する、
具体的にはrealpath()をつかうそうな・・・

って、それ、ＣやＣ＋＋ですよねえ・・・

ＪＡＶＡは？File#getCanonicalPath()なのかしら？？

---

うん、でも、ひょっとして、それって、ＷＡＦでやってくんない？

とおもったら、

第3回 WAFはどのように脆弱性を防御するのか
http://www.atmarkit.co.jp/fsecurity/rensai/waf03/waf03.html
に、そんなのありました（以下斜体は上記サイトより引用）


　強制ブラウジングを防ぐためには、オブジェクトタイプのチェックによる意図しないファイルタイプへのアクセスからの防御と、正規表現を使用したネガティブセキュリティモデルによるディレクトリトラバーサルからの防御を行う。ディレクトリトラバーサルとは、パスをさかのぼることによって、本来、管理者がユーザーに見せるつもりのないファイルやディレクトリを閲覧したり実行したりする攻撃である。「../」という文字列などをリクエストパスの中に入れる手法がよく使われる。


おお、じゃあ、ＷＡＦにすれば、ばっちり・・・なの？？

---

でも、ふとおもったんだけど、ＷＡＦって、リバースプロキシ＊使うよねえ。。

（使わない方法もあるらしい）

じゃあ、このリバースプロキシが倒れたら、どーなるの？？

---

そんなくだらないこと考えてないで、getCanonicalPath()使えって（＾＾；）
（まだ、こいつ使ったことない、今度試してみるね）


＊リバースプロキシ：外から、中のあるサーバーに対する通信を行う際、かならず、このサーバーは通ってね！っていうプロキシ、ふつうのプロキシは、中の人→外に行く時に使うのに、こいつは、外→中にいくときにおもに活躍するので、ふつうの逆＝リバース