Category Archives: プログラミング

C#ってシーシャープって読むんだぜ?

何を当たり前のことをと思われた方、何を今更と思われた方いらっしゃると思いますが、私は今頃になって「何でシーシャープって読むんだ?」と疑問になりググってみました。C/C++を使うのでC#を使うことは殆どないので今頃なのかも。

何を言ってるんだ?と思われた方はよくタイトルを見てください。C#ですC#。C♯じゃないんですよ。私も日本人だから「RとLの発音の区別できないくせに!」と提督に言われるのと同じように「#と♯の区別」が出来てなかったんです。

キーボードの「#」はシャープではない件について – ♪8th Note♪
http://blog.c-production.com/archives/2008/02/post-446.html

そこで、皆さんC#をシーシャープと読むから、その記号シャープじゃないってばーと思っているうちに、海外ではなんと読まれているのだろうと気になってしまった。

そしたら・・・。

C# – Wikipedia (日本語)
http://ja.wikipedia.org/wiki/C_Sharp

C# (programming language) – Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/C_Sharp_(programming_language)

普通にシーシャープって読んでるぞ?
さらに調べると日本人なら疑問にすら思わない読み方も海外ではやはり疑問になるようです。

[NMLUG] Trivial persuits: how to pronounce C#?
http://nmlug.org/maillist/2000-October/msg00060.html

結局のところ正式な呼び名は何だ!とMicrosoftサイトを見てみました。

Visual C# (日本語)
http://msdn.microsoft.com/ja-jp/library/kx37x362.aspx
「C# (“C シャープ” と読みます) は~プログラミング言語です。」とあり、

Visual C# (英語)
http://msdn.microsoft.com/en-us/library/kx37x362.aspx
「C# (pronounced “C sharp”) is a programming language~」とあります。

MS自らC#と書きC sharpと呼べと書いているので、定義みたいなものですね。これは日本で言うと「ギャル文字」と呼ばれている本来の読みと違う読みをする記号みたいな状態かも。あースッキリ。

リアルな架空のダミー個人情報

オプトインメールのシステムやCRM等の開発時や更新時にはテストの為にダミーの個人情報が必要になりますが、開発会社側で用意するのも大変で顧客に問い合わせると、バックアップされている既存システムの顧客データを渡されたりと個人情報の取り扱いが大変なことが多いのですが、こういったダミーデータ集あると安全にテスト運用ができますね。People to People Communicationsから公開されたデータは一応商用利用はダメみたいですが無償でダウンロードできるみたいです。

People to People Communications(川崎市)は11月25日、統計データを元に作成した「疑似個人情報」の無償提供を始めた。非営利目的に限り、1人3000件まで無料でダウンロードできる。

プレスリリース:『疑似個人情報』の無償提供を開始 | People to People Communications 株式会社
http://www.ptpc.co.jp/release/081125.html

本物そっくり「疑似個人情報」を無償提供 – ITmedia News
http://www.itmedia.co.jp/news/articles/0811/26/news012.html

 

Cookieを使ったSQLインジェクション

最近Cookieを使ったSQLインジェクションが発見されたということでその手法の詳細記事がありました。前置きが長すぎてもっと簡潔にして欲しかったのですが問題点は以下のようになります。

  • メジャーな侵入検知システムはPOST/GETの検査を行うがCookieを見逃していた。
  • スクリプト側でPOST/GET等メソッドを明示的に区別してデータ取得していない。
  • スクリプト側で入力データの検査が出来ていない。

元記事には

ここまで聞くと、「うちのサイトではクッキーにデータベースに関連するような情報は格納していないから関係ない」と、早合点する人もいるかもしれない。それは間違いなので、もう少しお付き合いいただきたい。

なんて書いてるからよくよく読んでみましたがCookie使う以前の問題で仕事でウェブプログラミングしているならその会社のスキルを疑って良いレベルです。PGのスキル不足は常にあると仮定してもレビューせずに素通りかPLが無能。PMが放置主義って言ってる様なもので会社でレベルで恥かいてるぞ。私ならこんな杜撰なコード組む会社に2度目の外注はしない。

まずコードの品質を上げる前に侵入検知システム等に頼るのは気が進まないし費用のムダ。これの方法の恐いのは侵入検知システム自体に穴がある場合だけでなく、サーバー移設等環境が変わった場合にミスが起きやすい。ニュースで「サーバーの設定ミスで情報漏えい」というケースがこれ。

次にデータ取得においてメソッドを区別していないのはCookie以前の問題でGETしか想定していないスクリプトでPOSTで渡されてもスクリプトのみでは同じ問題が起きるので注意すること。昔Perlで外部ライブラリなしでコーディングしているときは非常に面倒だと思いつつもどうやってデータがウェブサーバに送られてくるのか勉強になりました。今時よく利用されるASPやPHPはその辺の面倒な処理を自動的にやってくれて組込関数グローバル変数から読み込めますがRequest系の実装は気持ち悪くて使えない。未だにRequestについてGET/POSTを気にせずどっちでも使えるから便利とか発言するPGを見かけるが変数名が重複したときの対処方法を考えていないのが大半。セキュリティはともかくバグの元になる事を想定できていない。そういう人に限ってデバッガ未経験だったりする。

あとニュース記事には書かれていませんがPHPの場合、Requestでなくても$_POSTや$_GETのみで変数を上書きできるから注意ですね。通常リスト構造のデータを受け取るときは配列型にしたほうが便利ですが、それをせず同じ変数名で並べて送ってくるフォームがありそれにも$_POSTや$_GETは対応できないのでPerlの時のように素の入力データから抽出しています。それと同じ方法で本来の変数を上書きされても発見できない場合がありますので注意です。

最後に入力されたデータを検査していないのは論外、今回のセキュリティホールもPOST/GETを想定した変数だとしてもスクリプト側で検査していれば問題になっていない。メソッドを明示していればCookie経由で上書きしようとした変数はその場でイジェクトできるし、Request受けていてもそのデータを検査できていれば良いのである。とは言っても現実はApacheエラーログを見ずに組む人が多い、サニタイズどころかValidateやisset検査すらせずにエラーログを汚しまくる奴もいる。指摘するとErrorじゃなくてWarningだから大丈夫だろうとか言葉を理解できていない人やErrorじゃ無いんだからサーバー側でログ出力止めろよ!と逆ギレする民度の低いPGも少なからず存在する。そういうのに限ってこれまたPHPはPerlと違ってセッション実装できているから凄いとか内部処理を知らずに自慢(それもPHP作った本人じゃないのに)していたことがあって呆れたこともあります。

以上で愚痴込みのまとめは終わりますが、元記事を見てハッと気付いた脅威が一つありました。
最低限の作業として送られてくるデータは特定して検査するように書いているつもりですが、セッション変数はサーバーに保存されているデータなのでそこまでは強制的に検査していませんでした。(ヒマがあればするけれど他人にまで強制していない)

これの何が原因かというと、一度送られたフォームデータ(特にショッピングカート等)は途中ページでの改ざんを防ぐ為にセッション変数として保持することがありますが、保存したセッション変数からデータを再取得するときに検査をしていない場合がありました。近年はCookieに値セットして使うことが無いので完全な見逃しですが、Cookieを改ざんされた時に$_SESSIONが自動的に汚染されないか確認したことが無かった・・・。これは週明け直ぐにでもチェックしてみます。

他にDBとの入出力に対しての検査も、最初はそこまでする必要あるのかな?と思っていましたが仕事で使う内に必須だと思うようになりました。セキュリティ的には外部と接触する部分で一斉検査すれば大体良いのですが、開発途中でDBのデータがいい加減に入力されているとか仕様外の構成になっていたりするとが多く、というかほぼ100%でデバッグの障害になってたりもします。これでPGとDBエンジニアが鶏が先か卵が先かみたいなケンカもします。そこでスクリプト側としてはDBとの入出力にも開発効率を上げるために検査を入れておいたほうが良いと思います。あとApache管理者の意見として、大量のUndefined indexでログを汚すなというのもあります。

またまた進化したSQLインジェクションの脅威 クッキーを悪用 セキュリティー-最新ニュース:IT-PLUS
http://it.nikkei.co.jp/security/news/index.aspx?n=MMIT2g000028102008&cp=1

ApacheModuleの作り方

C言語のCGIは速いと思っていましたが実は遅かったんですね。Servletみたいにプログラムがメモリに常駐されていればディスクアクセスが発生するCGIに勝ち目は無いのか・・・でもFastCGI組み込んだらどうなんだろ?

以下の記事はCGIをC言語で作るというより、Apacheモジュールの作り方に重点を置いています。Webシステムのモジュールをバイナリ形式で配布する際にとても参考になりそうです。

ApacheModuleでWebアプリケーションをつくろう:CodeZine
http://codezine.jp/a/article/aid/2502.aspx

最近PHPがフルボッコのようです

PHPが非難される流れは去年の後半あたりから把握してますが、PHP5以降は言語として特に非難される程のものもないような気がします。PHP本体のセキュリティホールとかは別ですが…。ただPHPプログラマーが訳も分からないまま叩かれているような気がしてちょっとかわいそう。

私も何故かここ3年程仕事で一番多く使った言語がダントツPHPで次がC++そしてPerlといった感じ。PHPが選ばれたのはクライアントや上流の決定による物ですが、理由は単純明快で「書くコード量が少なく開発効率が良いから」「誰にでも割り振れてアサインが楽だから」ということです。当然工数も費用も削減できて良いように思えますが正直コンピュータの動作や通信については理解の妨げになっているので学習者や初心者にはオススメしたくない言語です。あとVBでリストラになってPHP再チャレンジの人も同様です。

簡単であることと基礎的なものは別次元の内容なので学習の際にはこの部分を混同して欲しくない。PHP言語はウェブプログラミングする際に便利な組み込み関数や定義が容易されていて初心者でもすぐにある程度ちゃんとしたものが作れてしまう。だがそこにウェブプログラミングとしての基礎を学ぶことが出来ない。GETやPOSTをPHP言語上でどのように取得するか覚えても、HTTPプロトコル上でどのような形式で送信されていてプログラム内で切り抜き処理をしているかなんてPHPだけでは想像もつかないだろう。PerlやC言語であればそのへんも全部自分で考えて処理しなければならないので勉強になる。

数学に例えれば微分の公式覚えて、微分が出来るようになったけど微分の理論を全然理解してないと似ている。(というのが高校生時代の私…orz)

ゲーム制作スキルとなれば物理や数学の基礎からプログラミングの応用まで勉強すべき事があるのですが、RPGツクールやオーサリングツールだと簡単に作れてしまうみたいな。

だからPHPだけしかやってないと他の言語で同じ事を達成するにはコンピュータ理論や通信の基礎的な学習が必要だし、プログラミングに対しての理解の深さに差が出てきます。仕事で初めてプログラミングに触れてそれがPHPだった言う人も最近は多いのでこの機会にぜひPerlや他の言語にも挑戦してみてください。

最近は確かに学生時代までに趣味または専門授業でコンピュータ理論を勉強したことがなくこの業界にプログラマーとして就職している人も増えてきたので非難する前に勉強するチャンスをあげたほうが良いなと思いました。

マシン語の理解力

私も現場では似たような事を言っているほうですが意外にも反響あるんですね。

shi3zの日記 – マシン語を知らない子ども達
http://d.hatena.ne.jp/shi3z/20070911

私自身マシン語といえば中学生からPC無しでNHKラジオの情報処理試験講座を勉強したり(当時はプログラミング言語の選択をマシン語にしてました)。高校生のときに286マシンしか持って無いのに80386の勉強を独学でやって挫折したり、大学ではZ80アセンブルの講義があってそれまでの経験が生きたりということもあって、今ではメインでプログラムを組むことが無くて寂しいのですが過負荷障害系のカンだけ冴えているのはその経験があるからなのかも知れないですね。最初に就職したときもプログラマー志望なのに半導体の論理回路設計なんてとこにいたので、最初から高級言語だけで開発してきたプログラマーとはテスト・デバッグ方法などの話題でギャップを感じます。

別にマシン語自身はこだわる必要も教育を受ける必要もないと思いますがPCの構造を知るには近道だと思います。最近は優秀なクラスライブラリも出ているのでそれに依存しなければいけないことに抵抗が無ければそれでもいいと思っています。最近はネットワークを利用するプログラミングが多くなっているのでスモールエンディアンのIntel系でもネットワークに乗せるときはビッグエンディアンに変換しないといけないとか知っておけばお得な事も有りますね。全く知らない、知ろうとしないというのは技術者としてどうかと思いますが中途半端な知識で特攻するのもリスクが大きいので、知らないフリしつつ機会があれば勉強してみるのが賢いんじゃないかな。それで仕事として請け負ってよいレベルに達すれば仕事も広くなるし悪くは無いと思います。

メルマガのソース配布

メールマガジン御購読ありがとうございました。そしてお疲れさまでした。今年のGWシリーズのサンプルソースを配布します。

コンフィグファイルの読み込み(C++とSTL利用)
2007050601-1

これにコンフィグ新規作成・書き込み用クラスなんて作るととりあえずまともかな。カレントディレクトリの認識は特にやってないのでそこが甘いかもしれません。実際に使用するときはその辺の応用も考慮して修正してくださいです。

半年ぶりにメルマガ発行

メルマガを久しく発行してなくて強制退場されかけていました。本来ならMMO開発の進捗にあわせてTips感覚で発行続けようとしていましたが肝心のプロジェクトに手を付けられず周辺の作業ばかりでネタの作成ができていませんでした。今回は期限もあったのでかなり意識して作成しました。

本日発行したメルマガで書いたプログラムはここからダウンロードできます。

2007042901-1

空メールでユーザ登録

無料ケータイサイト等では空メールを送信することで利用登録するシステムがありますが、簡単に実装するとしたらこんな例があります。

1.空メールを送信。

2.メールサーバのalias若しくはforwardでスクリプトに転送。

3.スクリプトはメールのヘッダを解析し、登録完了メール返信及びDB登録を行う。

4.登録完了メールのURLからアクセスすると送られたIDの認証を行い案内する。

と、こんな感じです。

メールサーバをqmail、スクリプトをPHPとしてこんなサンプルを作ってみました。

1と4は同じPHPページml.phpを使用し、IDがない場合は空メール送信の案内。IDで認証できた場合はコンテンツを表示。
3は登録用スクリプトとしてmlreg.phpを使用。メールサーバからのみ起動される。

ml mlreg

mlreg.phpのサンプル中にあるFrom抽出は完全ではありませんが、メールの規格は実質無法地帯な状態できりがないのである程度対応できるレベルに留めておきます。

そしてqmailのaliasを使う場合
# cat /var/qmail/alias/.qmail-regist
| /usr/local/apache/htdocs/mlreg.php

このように転送先にスクリプトを設定します。
別に登録用PHPはウェブからアクセスする必要がないのでこの場所は不適切ですが…。

【2007/08/27 19:40追記】
上記プログラムはあくまで動作確認用でセキュリティに関しては一切考慮に入れておりません。
まさかそのまま使う人はいないだろうと思っているので注意事項も書かず放置しておりましたが、はてなブックマークからリンクされているのに気づき自分の愚かさと恥ずかしさで申し訳ない気持ちでいっぱいです。今後もセキュリティに関するサンプル以外はセキュリティ対策コードを含めることは少ないと思いますが、必ずどこが危険かは併記したいとおもいます。

因みに上記のプログラム内では、
ml.txt 6行目:
直接MySQLにGET引数を渡している事、これはセミコロンを挟んで閲覧者が任意のSQL文を実行できます(SQLインジェクション)。外部から取り込むパラメータには必ず内容のチェックを入れます。
ml.txt 9行目:
逆にDBから取り出したデータをそのまま表示するのも推奨できません。出力する書式に合わせて内容のチェックを行います。
ml.txt 12行目:
exsample・・・orz typoです。しかも実在するドメインですね。exsampleの方申し訳ありません。
ml.txt 16行目以降:
とりあえず表示されれば良いレベルで書いているので実際はちゃんとしたHTML書くなりしてください。
mlreg.txt 12~14行目:
ここはあまり参考にならないと思います。ヘッダー内にFromが2箇所あったりしても最初のFromを拾いますし、この部分については他所で良いライブラリが公開されています。
mlreg.txt 16~17行目:
コピペかすです… このコードはメールアラートに使っているものの流用です。その上変数名の変換忘れ
orz
mlreg.txt 22行目:
ここも$toまで用意して何故か$from[0]にしている…。どっちもどっちですが。
mlreg.txt 23~30行目:
これはauto_incrementで得たidをそのままアカウントに使用することに問題があります。つまり他の数字を使ってアクセスしたら他人の情報が表示されるという罠です。ここは連続性のないユニークIDを作成して発行するなりの工夫が必要です。(セッションハイジャックというのも厚かましいセキュリティホール)
mlreg.txt 35行目:
これも$titleではなく$subjectです。また元の文字コードを考慮していないので文字の組み合わせが悪いと誤認識するかも。実際にローカルで動作確認した時は日本語すら使ってなかったのでこのコードは跡付けです。
mlreg.txt 40行目:
ここもtypoです。

この度は大変お騒がせしました。直ぐに無意味なコードとtypoを修正したサンプルをアップします

【2007/09/23 02:20追記】
うわぁ…修正ファイルのアップを忘れてました…。一ヶ月近く経ってる。
とりあえず上記のとおりtypoと無意味なコードを省いたもので更新しています。セキュリティはまったく考慮していないので、使用するときは変数無害化とアクセス制限を追加してください。

メールサーバ上でのメール受信をトリガーとしてメールの内容を処理に使用するデータとして取り出すまでがエントリーの趣旨だったのでそれ以降の処理は端折っています。

シェルスクリプトで関数

今までは単純にコマンド入れるだけとか単純な振り分け程度でしたが、一まとめの処理を変数の内容を変えながら実行するものを作ったのでシェルスクリプトでも関数みたいのが作りたいなぁ。

#!/bin/sh
var1=ON
var2=OFF
myfunc () {
echo ARG1=$1, ARG2=$2
}
myfunc $var1 $var2

上記のように書けばよいみたい、さすがにプロトタイプ宣言みたいのはないかなー?関数の定義は実際に使用する前に書かかないと見つからないようです。