歩道を駐車場だと思ってるバカども

大阪502 ほ 5697

大阪480 す 635

大阪800 さ 4332

大阪301 む 5804
枚方市 ゆ 59802

京都500 ね 1853

京都480 あ 1788

歩道じゃないけど右側駐車で横断歩道踏んでるからバカのレベルは一緒

京都500 み 9058

京都500 め 1578

京都 77 は 4748

目の前で110番しましたけど動じる気配なし

京都483 う 621 ブリヂストングループには国内有数の自転車メーカーもあるのに自転車通行帯の上に車止めるか…

京都11 う 9366

京都 504 む 7

京都100 い 413 株式会社共盛輸送

京都130 あ 3846 山一サービス

京都580 さ 4722 ファルコバイオシステムズ ちょうど運転手がいたので歩道は駐車場じゃないぞって言ったのに完全に無視されました。

京都501の1505。2人がかりでトランクからプロパンボンベ引っ張り出して京都中央卸売市場第一市場の中に運び込んでました。ところでプロパンボンベってそういう運び方していいんでしたっけ？

京都100さ9370 伊藤園

なにわ300り6911

京都480り1380

大阪800 さ 4332 常習なんですよねこいつ
枚方市ゆ40625
寝屋川市ひ2858

赤っぽい舗装は自転車通行帯です

京都100さ396

京都535 む 1221

いつもの桂大橋東詰南側。

京都200 さ 1308 トヨタハイエース(?)

110番した後に運転手帰ってきたので「自分で電話してキャンセルしとけ」って言ったら逆ギレされました。文句あるならもうじき警察くるから待っとけ、と言ったら慌てて逃げていったんですが、捨て台詞はこう。「そうやって人を見下して生きてりゃいいんだ」。意味がわかりません。自分が他人に迷惑をかけておいて、それを注意されたから「自分が見下された」と感じるんでしょうか。精神的にどっかいかれてるんじゃないでしょうか。

というわけで、運転手は危険人物なので絶対に近づかないように。警察には被害を申告済みです。

DoCoMoのL-05Aも。auのW05Kの遅さに耐えられないのと\30,000引き狙い。ヨドバシのポイントが貯まってるので使えたらラッキーかな、と

まずオーナーメードのカウンターでいくつか確認

• DoCoMoの\30,000引きは対象か？→OK
• オンラインで買ったときの3年保証は→付く
• ヨドバシのポイントは？→付かないけど支払いには使える

条件はOK。買うのは決めてるけど\30,000引きするならDoCoMoの契約先にしてきたほうがいいかい？って聞いたら先にこっちで見積もりして、その後DoCoMoの担当者呼んできます、と。構成の選択肢はオンラインと全く一緒なのでさくさく決めておしまい。ここでソニースタイルのID持ってるか聞かれる。持ってるけど今はわからない、と言ったらカウンターの端末でID通知画面(ソニースタイルの普通の画面)出されて、フリーメールだったらこれ使って確認できますが、とのこと。いやちょっとまてそれはこの端末でwebメールにログインして見ろってことかと思いつつ、深く突っ込まずに操作。iPhoneで確認できるし。

次はDoCoMo。正体は兼松コミュニケーションズでしたが。L-02A(\0)をプッシュされたけど、前にL-05Aがチェンジ割つかって\0になるって聞いてたのでそっちにしてもらう。が、チェンジ割に電話番号が必要、と言われて悩む。データ通信カードの電話番号なんてわかりませんがな。しょうがないのでauのサポートに電話かけてすったもんだしたあげく、請求をオンラインにしていたらそこから見られるはず、という回答を引き出し解決。

\0の条件がISP契約だったんですが、なぜかOCNをプッシュされました。moperaはおまけ。いいんでしょうか。料金は同じだけどOCNは2ヶ月無料だったので遠慮せずOCNに。

ここからDoCoMoのカウンターに移ってDoCoMoの契約。あれやこれやの確認が相変わらず面倒ですね。続いてOCN。ISPの契約なんてオンラインでやるとあっさり終わるのに対面だと面倒すぎる。しかも支払いは請求書のみでカード決済にするならあとでオンラインにしてくれだって。うーん。とりあえずおしまい。引き渡しまで1H待ち。

またソニーのカウンターに戻ってソニーの契約の続き。構成を確定してさていよいよ注文。ってオンラインかい。ソニースタイルのIDが必要ですってそういうことか。決済方法のところで「パートナー決裁」という普通出てこない項目が出てくるだけで、後はオンラインで注文するのと一緒。自分で操作させられるし。とにかく注文完了。普通にソニースタイルから注文完了のメールが来ました。

ここでソニーの人がDoCoMoに確認取ってくれて回線開通してるということだったのでまたDoCoMoのカウンターに。ヨドバシの店員に「まだだ」と言われたけどウソ付けコラと言って持ってこさせる。\0の領収書もらっておしまい。

最後にPCの支払い。ソニーのカウンター近くのレジにまた移動。都合2往復半ですか。もうちょっとどうにかならないもんでしょうか。結局約2時間かかりました。あとソニースタイルのパスワード変えとかないと。

まとめ。

・オーナーメードは店頭でもオンラインでも支払い方法以外は注文操作を自分でするのも含めて一緒。ソニースタイルのキャンペーンやクーポンも対象。納期も一緒。
・IDは事前に調べておくこと。
・支払いは店舗レジになる。量販店のポイントは使えないけど支払いには使える。他社のキャンペーン(データ通信契約で割引とかPCと何かを一緒に買うと割引とか)もたいてい普通に使える。
・(他社はどうだかしらないけど)DoCoMoのデータ通信契約でPC\30,000引き、は手続きが面倒。吊しのPCを買うときでもそれなりの時間を覚悟しておいた方がいい。mopera契約にしたら多少は短くなるかも。

NetAppが行ったベンチマーク(リンク先PDF)によると、ジャンボフレームを使用してもスループットは上がらない(iSCSIでは悪化)、CPU負荷はジャンボフレームを使用したときの方が低い、という事になったようです。設定変更のリスクを考えると微妙ですね。

ポテトとベーコンのグラタン(2日連続2回目)

枚方市駅構内で売っていた焼き芋スイートポテト

結論

セキュリティ対策の一環としてSQLの数値リテラル(が期待されるパラメータ)をシングルクォートでくくる(文字列扱いする)手法は使用すべきでない

理由

少なくともMySQLでは標榜されている通りの動作はしない上、意図しない副作用が発生する。

解説

数値リテラルをシングルクオートでくくる手法は、これを推奨する大垣氏によると次のような効果があるとされています。参考:なぜPHPアプリにセキュリティホールが多いのか? 第14回　減らないSQLインジェクション脆弱性

• 攻撃目的の入力が行われてもSQLインジェクションが発生しない
• 簡単に攻撃用の文字列が検出できる

これらはどちらも数値型が期待されるパラメータに不正なデータが渡されるとクエリエラーが発生することが前提となっています。例として、

SELECT * FROM table WHERE id = $VALUE; --ここでidは整数型

というSQLがあった場合に、$VALUEに"1 OR 1 = 1"という入力がされていた場合、WHEREが無効になってしまいますが、

SELECT * FROM table WHERE id = '$VALUE';

というSQLであれば、$VALUEが数値として解釈できなければクエリエラーになる(であろう)ということです。

しかし、MySQLの場合、データベース側で文字列を可能な限り数値に変換するという動作をするため、クエリエラーが発生しません。どのような変換がされるかはこれだけは覚えておきたい!!MySQL の６つの自動変換 - sakaikの日々雑感～©編に詳説されていますが、簡単に言えば

• 頭から読んでいって数値と解釈できなくなったら後ろは無視する(例:123abc456→123)
• 頭から数値と解釈できなければ0とみなす(例:abc123→0)

というものです。これは、数値(が期待される)パラメータを文字列扱いすればクエリエラーになる、という考えとは相容れません。

実際に試してみると、以下の通りwarningは出ていますがエラーにはなりません。

mysql> SELECT * FROM test;
+------+------+
| id   | text |
+------+------+
|    0 | 000  |
|    1 | 111  |
+------+------+
2 rows in set (0.00 sec)

mysql> SELECT * FROM test WHERE id = '1a';
+------+------+
| id   | text |
+------+------+
|    1 | 111  |
+------+------+
1 row in set, 2 warnings (0.00 sec)

mysql> SELECT * FROM test WHERE id = 'hoge';
+------+------+
| id   | text |
+------+------+
|    0 | 000  |
+------+------+
1 row in set, 2 warnings (0.00 sec)

このような変換によってSQLインジェクションを成立させることは難しいとおもいますので、SQLインジェクションを防止するという点については機能しているといえるかもしれません。しかし、大垣氏はこのように主張されています。

整数型にキャストすればよいのでは？　と考えられた方もいると思います。しかし，キャストする方法は2つの理由でベストプラクティスとは呼べません。キャストした場合，不正な攻撃目的の入力が行われてもクエリエラーが発生しない可能性があります。

(なぜPHPアプリにセキュリティホールが多いのか?：第14回　減らないSQLインジェクション脆弱性｜gihyo.jp … 技術評論社より)

この手法の前提が「不正入力があればクエリエラーが発生する」というものである以上、SQLインジェクションが成立しないのは単なる偶然と言うべきだと考えます。また、クエリエラーが発生しないので、簡単に攻撃用の文字列が検出できるという機能も実現されていません。

また、クエリエラーが発生しないだけでなく、開発者の意図しない検索条件の成立や異常データの挿入が行われるという問題があります。上記の例の通り、"1a"→1、"hoge"→0として検索条件が成立していますが、これはほぼすべての場合において開発者が意図したものではないはずですし、常識的な動作とも異なります。

なお、この手法を用いなかった場合には、MySQLにおいてもクエリは失敗します。

mysql> select * FROM test WHERE id = hoge;
ERROR 1054 (42S22): Unknown column 'hoge' in 'where clause'

mysql> SELECT * FROM test WHERE id = 1a;
ERROR 1054 (42S22): Unknown column '1a' in 'where clause'

これはおそらく開発者の意図通りでしょう。

もっと根本的なレベルでこの手法を用いるべきでない理由があります。このような問題がこの手法を推奨する側から全く示されていないことです。本記事の内容は、MySQLという超メジャーなデータベースについてすら全く検証が行われていないことを示しています。文字列→数値の変換については、数値リテラルをシングルクォートで囲むことの是非 - ockeghem(徳丸浩)の日記において一部のデータベースについて検証された結果が記載されていますが、データベースによってかなりばらつきがあります。パラメータやバージョンの違いによっても動作が変わるかもしれません。実際手元のMySQLはこの表とは違う動作をしました。

以上の通り、この手法は

• 少なくともMySQLにおいては標榜されている機能は全く実現されない
• 他のデータベースにおいても慎重に検証が必要だが、その分の労力はパラメータの検証やテストを確実に行う方向に費やすべき。
• 仮に検証の結果ある時点では動いたとしても何らかのきっかけで意図した動作をしなくなる可能性がある

という理由で全く使うべきではありません。

南米チリ中部沿岸の大地震で発生した津波で、気象庁は１日午前１０時１５分、太平洋沿岸全域に出していた津波警報や注意報をすべて解除した。同庁の関田康雄・地震津波監視課長は同日午前の記者会見で、「津波の予測が過大だった。警報が長引き迷惑をかけたことをおわびしたい」と語った。

(asahi.com（朝日新聞社）：津波注意報を解除　気象庁おわび「津波の予測過大」 - チリ地震より)

地球のほぼ真裏で起こった地震で予想3m、実績1.2mは大当たりの範疇だと思います。「過大」と言いますが、警報が出ているにもかかわらず海岸地帯でマラソン大会を強行した気が狂ってるとしか思えない自治体が存在することからも明らかなとおり、なんの根拠もなく勝手に過小に修正する人々が存在しますので、万が一過小な予想をした場合、甚大な被害が発生する可能性があります。

気象庁は批判に対し、「警報を無視し人命を軽視する人々が存在する以上、可能な限り大きな予想をしておく責任がある」と毅然として反論すべきでしょう。

ワンタイムパスワードを使ってsshでログイン出来るようにするまでの/etc/pam.d/sshdをどう書いたらいいか悩みまくった試行錯誤の記録です。結論は、control-flagのsufficientは成功すればそこで打ち切りとマニュアルに書いてあるが実はそうではない。

まずデフォルト。

auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
auth            required        pam_unix.so             no_warn try_first_pass

これがどういう意味になるかは別記事に書きましたが、簡単に言うとワンタイムパスワードが有効なユーザーはワンタイムパスワード認証でログインでき、ワンタイムパスワードを設定していないユーザーはUNIX認証になります。

失敗例1。UNIX認証を無効にすればいいんだろ？とばかり最後の行をコメントアウトしたとしましょう。

auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
#auth           required        pam_unix.so             no_warn try_first_pass

ワンタイムパスワード認証が有効なユーザーでは変化ありませんが、そうでないユーザーはなんとパスワード無しでログインできてしまうという大変危険な設定です。

失敗例2。そうかそうか、ワンタイムパスワード認証を使わないユーザーは上2行を突破するからそこで拒否すればいいんだろう、ということで、こうする。

auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
auth            required        pam_deny.so

mod_deny.soはとにかく拒否、という認証モジュールです。これがどうなるかというと、ワンタイムパスワード認証を有効にしているユーザーもログインできなくなります。/var/log/auth.logを見ると

sshd[]: Accepted keyboard-interactive/pam for shin from xxx.xxx.xxx.xxx port 12345 ssh2
sshd[]: fatal: PAM: pam_setcred(): failed to set user credentials

なんて出てます。パスワードを間違えたときは

sshd[]: error: PAM: authentication error for foo from xxx.xxx.xxx.xxx

になるので、ワンタイムパスワード認証自体は正常に動いている様子。

マニュアルを見ても実際に試した結果でもcontrol-flagがsufficientのモジュールは成功すれば後ろの処理は走らないはずなので、後続に何が書いてあっても関係ないはず。なので、認証の問題ではなくてPAMのアカウント/セッション/パスワード管理がらみの問題かな、と判断し試行錯誤すること数日。

結局うまくいかないので、いよいよソースを追いかけてやっと原因がわかりました。

PAMの設定のauth(認証)サービスの部分は実は2回なめられます。実際の認証処理と、エラーメッセージにあるpam_setcred()の処理です。実際の認証処理ではcontrol-flagではマニュアル通りに処理されますが、pam_setcred()の処理でなめられるときは、sufficientだけ動作が異なり、成功しても処理が継続されるのです。PAMのソースに思いっきり書いてありました

/*
* For pam_setcred() and pam_chauthtok() with the
* PAM_PRELIM_CHECK flag, treat "sufficient" as
* "optional".
*/

なんでこんな実装になってるんでしょうね。いやなんか意味はあるんでしょう。しかしみんなよくこんなの悩まずに設定できるなぁ。だれも使ってないのか？

理由がわかったところでどう設定すべきか改めて考えて結局こうなりました。

auth            requisite       pam_opie.so             no_warn no_fake_prompts

とにかくシンプルに考えると、うちの要件ではワンタイムパスワード認証に成功するかどうかが全て、でいいのです。

なまじデフォルト設定をベースに考えると失敗する、という事例でした。

FreeBSDには標準でワンタイムパスワード機構(OPIE)があり、ワンタイムパスワードでのsshログインが可能です。実際に試してみました。

前提

• 現在は公開鍵認証だけ有効になっている(普通そうしますよね)
• UNIXアカウント/パスワード認証は引き続き使用しない

まずこれを実現するために、PAMのsshdの設定を変更します。/etc/pam.d/sshdです。デフォルトでは

auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            required        pam_unix.so             no_warn try_first_pass

auth            requisite       pam_opie.so             no_warn no_fake_prompts

これだけに変更します。この変更は十分注意してください。油断するとパスワード無しでログイン出来る状態になったりします。ここにたどり着くまでにえらい苦労したんですがそれは別記。

もしportsからsudoをインストールして使用している場合、こっちでもワンタイムパスワードが有効になってしまいます。それが鬱陶しい場合はsudoについてはワンタイムパスワード認証を無効にします。/usr/local/etc/pam.d/sudoの

# auth
auth            include         system

こうなっているところを

auth            required        pam_unix.so             no_warn try_first_pass

こう変更します。いっそのこと/etc/pam.d/systemの

auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local

この行をコメントアウトしてしまってもいいかもしれません。

sshdの設定を変更します。/etc/ssh/sshd_configです。

#ChallengeResponseAuthentication yes
 :
#UsePAM yes

デフォルトではこうですが、どっちかをnoにしていると思いますので元に戻します。変更したらsshdを再起動します。

公開鍵認証を使わずにログインを試して、リモートログイン出来ないことを確認します。繰り返しますが、設定ミスするとパスワード無しでログイン出来る状態になることがあります。

最後に、利用したいユーザーでワンタイムパスワードを有効にします。ローカルまたは安全な接続のコンソール上でopiepasswdを実行します

% opiepasswd -c foo
Adding foo:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase: (パスフレーズ入力)
Again new secret pass phrase: (繰り返し)

ID foo OTP key is 499 ho1234
FOO BAR HOGE FUGA PIYO

これでユーザーfooのワンタイムパスワードが有効になりました。

最後から2行目にある499というのがシーケンスナンバーです。ワンタイムパスワードを1回使うと、この数字が1個減ります。その後のho1234はパスワードを生成するためのseed(種)です。ワンタイムパスワードを生成するにはシーケンスナンバーとseedとパスフレーズが必要です。

次に要求されるシーケンスナンバーは498になるので、作ってみます。

% opiekey 498 ho1234
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
NESS REND NICE WHEN EVER MANA

sshで実際に接続してみると、このようなプロンプトが出ますので

% ssh remotehost
otp-md5 498 ho1234 ext
Password:

さっき生成された"NESS REND NICE WHEN EVER MANA"を入力するとログインできるはずです。

ワンタイムパスワードはログイン先のホストで生成する必要はありません。シーケンス番号とseedとパスフレーズで一意なものが生成されるので、手元のホストでopiekeyコマンドを使って生成されたパスワードでもログインできます。他のOS用のパスワード生成機もあるらしいのですが実物は見つけられていません。

手元でパスワードが生成できない場合、opiekeyに-nオプションを付けると複数のパスワードを生成できます

% opiekey -n 5 999 ho1234
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
995: RACY FAT YAP TIE FORT NAP
996: GIN AWAY DIN HUGE FORT PAP
997: SKIM PAW BONE FALL DUMB BOCK
998: MITE CODY DUSK REEL GLUM ARK
999: HALE PET GEE WYNN DANK AWN

ので、これを控えておけばいいでしょう。未使用の物を間違っても落とさないように。

よくわかんないので表にしてみた

例えばFreeBSDの/etc/pam.d/sshdはこうなってる。

auth sufficient pam_opie.so       no_warn no_fake_prompts
auth requisite  pam_opieaccess.so no_warn allow_local
auth required   pam_unix.so       no_warn try_first_pass

1行目。OPIEを有効にしているユーザーであれば、OPIEの認証に成功すればそこでおしまい。失敗したら先に進む。OPIEを有効にしていないユーザーは失敗するので先に進む。

2行目。詳しくはman pam_opieaccessなんだけどデフォルトではOPIEを有効にしているユーザーは失敗してそこでおしまい。OPIEを有効にしているユーザーは成功するので先に進む

3行目。UNIXアカウント認証に成功すれば成功。sufficient(fail)->requisite(success)->required(success)と北野で最終結果は成功。

required

そのモジュールが成功しない限り全体が失敗するが、処理は続く。(失敗しても処理を続ける意味はよくわからない。pam_execとかでプログラム動かしてなんかするときのため？)

requisite

そのモジュールが成功しない限り全体が失敗する。失敗したときに後続を動かしたくないときはこれ。(例えば後ろにpam_unix.soがいるとrequiredだとプロンプトが出るがrequisiteだとでない)

sufficient

これが成功すれば(前段で失敗条件を満たしていなければ)認証成功。失敗しても後続で救済

biding

これが成功すれば(前段で失敗条件を満たしていなければ)認証成功。失敗したら全体が失敗。

optional

成功しようとしまいと結果は後続次第。

ABC-MARTで仕事用の靴。底が抜けて水がしみてくるようになったので。安いのもいくつかあったけど結局前と同じもの。これで3回連続。\9,990

鬼おろし。プラスチック製。\105

桃屋の辛そうで辛くない少し辛いラー油

3D上映初挑戦というわけでアバター。

赤青メガネのイメージが残っていたのであんまり期待してませんでしたが、結構すごい。「思わずのけぞった」りはしませんでしたがまぁそれなりに3D見えますね

しかし、字幕まで立体にする必要は無かったんじゃないかと。しかもいつもの字幕に比べて画面の中央に近い。したがって大変鬱陶しい。

次は吹き替えでアニメ見てみますかね。評価はそれから。

京阪三条からスタート

通りがかると「だん王」って何？っていつも思ってしまうんですが人の名前でしたか。見事な銀杏のある檀王法林寺。

工場かなんかかと思ったら飯屋

粟田神社

蹴上から南禅寺

南禅寺の裏にある最勝院高徳庵。

南禅寺に戻ります。

哲学の道

ねらったようにナイスなポジションに猫がいました。

この直後、無神経に近づいていったバカのせいで逃げてしまいました。

出町柳に戻っておしまい。

全部の写真

Map your trip with EveryTrail : 東山で紅葉狩り