プログラミングの作業に何の価値も見出せなくなってしまったd金魚による日記 このページをアンテナに追加 RSSフィード

 iTunes Music Store(Japan) なかのひと あわせて読みたいブログパーツ
|

0001 | 00 |
2004 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2008 | 01 | 02 | 03 | 05 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 |
2010 | 03 | 04 | 06 | 07 | 09 | 10 | 11 |
2011 | 01 | 02 | 10 |
2012 | 04 |
2013 | 01 | 05 | 06 | 07 | 08 | 10 |
2014 | 02 | 03 | 05 | 09 |
2015 | 04 |
2016 | 09 | 11 | 12 |
はてな一覧
アンテナに追加
私のアンテナ
私のダイアリー
私のアーカイブ
私のアイデア
私のブックマーク
私のグループ
私のキーワード
ニュース系、今まで続いているシリーズモノの読み物
dKingyo Utility Toolkit Projectのリリース情報
やっぱり暗号化は大人の味(笑)
プログラムのパッキング方法を調べよ
ココが厳しいよMinGW
ライブラリアン通信
ゲームプログラミングどうしよう
CRCについて
ビット演算練習
d金魚の今更Ajax
Windows Tips
VC6 Tips
Win32 WTL Tips
Ruby for C++ User
Ruby Tips
今日のRubyで嵌った事
正規表現PIECE
書きかけ
続く・・・

私のダイアリーの人気記事
新しくブックマークされた記事


あまり、役に立たなそうな個人的に調べた情報や妄想に耽った事、今 勉強している事ヒソヒソと公開していたりします。 | 登録してくれている方々 | d金魚にメール | 当サイトは640x480の画面解像度に対応しています。
日記へのリンク、アンリンクはフリーですが、selfタグのついている部分のコンテンツの引用はご遠慮願います。ご協力よろしくお願いします。


 | 

2005-03-07 セキュアなコーディングの仕方

[][][]Writing Secure Codeを読んで。 Writing Secure Codeを読んで。を含むブックマーク Writing Secure Codeを読んで。のブックマークコメント

実は、某本*1 と この本 を悩みに悩みあげ、この本を買ってしまった。

ちなみに買うときは

http://www.amazon.co.jp/exec/obidos/ASIN/4891004460/studiokingyo-22

http://studiokingyo.fc2web.com/dxlib/shiryou/book.html

から買ってくれると嬉しい。mousugude amazon gift ken wo moraerukarada.

このページからたどって買ってくれたら きっと貴方にはイイ事あるかも!!? (祝福)


閑話休題・・・


まず、共感したのは「関数の外は悪の巣窟」みたいな事が書かれていたことだった。

私もライブラリを組むときは意識している。

私は一つ一つの関数を作る時、目的に応じて「関数に渡す引数を信用しつつ信用しない」ことにしている。

関数引数を指定するのは所詮 人と言う事にあるのだ。


第一に関数内部に処理するデータの情報をすべて渡すのが筋だと思う。

このポリシーを見事に踏み倒してくれる悪の関数として挙げるとしたら私はstrcat(dest,src)にするだろう。

この関数の特にあくどい所を上げると

が最有力である。

また、細かいかもしれないが

  • srcの有効なバッファのサイズはいくらかが関数内部には分からない
  • destが何バイト文字列が入っているかが関数内部には分からない(以下は関数内部でstrlenでもすれば良いだろうが・・・念のため。)
  • srcが何バイトの文字列が入っているかが関数内部には分からない

と、いった点がある。

これらはすべてセキュリティーホールにつながると私は考える。

非公開、inline展開するならいざ知らず公開関数(C言語の標準関数)がこのようなチェック無しの無責任な処理をしてはいけないと考える。


第二に関数外部から流れてきたデータが製作者の意図をはずれたデータの場合の対策が大切だ。

例えば・・・時間を表す変数として23が実質上上限のchar型の変数があるとしよう。*2

私なら、マイナスになったとか。24以上になったりにするとバグが発生すると考えるのが筋だと考える。

開発者側が引数指定で間違う場合もあるだろうし、通信するプログラムであれば正規のデータが途中で改竄されてソフトを混乱させるを意図としてそのようなデータがで流れて来る事もあるだろう。


そう言うときにitoaとかsprintfとか使って文字列にした場合、

その文字列に必要なバッファが3byteで良いと思っていたのがオーバーフローしてしまったと言う事になりかねない。

え?127が最大だから問題無い?昔の私ならそう思いそうだ・・・

今の私なら昔の私に

このバカチンが〜!!!  川`0´)/☆#T。T) アウッ!

と胸を張って言える。^^;*3


また、それらの通信するプログラムで送られて来て得たデータは信用しないのが筋だ。*4

例えば、

は もってのほかだ!!!


前者は改竄されてUINT_MAXになっていたら・・・メモリ一杯一杯の値になっていたら・・

後者は状態が破綻をきたしてなんらかの不具合が・・・(恐ろしい結果もありうる)

と、

開発者の意図とした動作が出来なくなってしまう。


私がまず、この本を読んで思った事は以上だ。

次回はこれらの対策をするためのコーディングスタイルについて書こうと思う。


関連:http://d.hatena.ne.jp/studiokingyo/20040620#p3



久々に断言系の語尾を沢山使って書いたが・・・実は(((( ;゜д゜))))ものだったりするのデースケドガー^^;

*1http://d.hatena.ne.jp/studiokingyo/20050221#p1 http://d.hatena.ne.jp/studiokingyo/20050128#p3

*2:unsigned charだとマイナスの対策が無くなるだけ楽だが、ここはバグ条件を増やし、身近なところにセキュリティーホールの源がある事を明示するためにcharとする。

*3:NULL文字分も考慮して上げないとネ・・・また-128ってのもありえるし

*4:もちろん条件によってはここまで徹底する必要な無い

*5HTMLJavaScriptActiveX等がこれにあたる。確かに既存の問題を解決するために作った規格だろうが、私は好きではない。このせいで安全性チェック処理等でソフトウェア自体が重くなってしまうのだから・・・

 | 
Program | Debug | dKingyo Utility Toolkit | library | D言語 | 御本とか | 備忘録 | テクニック | WayBack | 格言 | 英語 | 他力本願 | news | software |

デースケドガー
Connection: close