SSL通信の根本を揺るがす「SuperFish」問題をどう見るべきか：セキュリティクラスター まとめのまとめ 2015年2月版（2/3 ページ）

PCにプリインストールされたソフトが通信に割り込み、その内容を全て見ていたかもしれない――2015年2月、レノボの「SuperFish」問題は大きな爪痕を残しました。

[山本洋介山（エヌ・ティ・ティ・コミュニケーションズ），＠IT]

2015年冬、最後のバリデーション論争が行われる？

　ここ数年、季節の風物詩のようにことあるたびに繰り広げられていた感がある「入力バリデーション」に関する論争が再燃しました。「PHPポケットリファレンス」や「はじめてのPHP 言語プログラミング入門」を執筆した@yohgaki（大垣靖男）氏と、「体系的に学ぶ 安全なWebアプリケーションの作り方」を執筆した@ockeghem（徳丸浩）氏との議論です。

　事の発端は、先日話題になった「GHOST」脆弱性はバリデーションで防げると主張した@yohgaki氏のブログについて、攻撃を防げるとするバリデーションの仕様が明記されていないと@ockeghem氏が指摘したことです。

　@ockeghem氏は過去の@yohgaki氏のバリデーション方法を引き合いに出し、ホスト名のバリデーションを論じますが、それに対し@yohgaki氏は新たにRFC1123の規格にのっとっているとするホスト名のバリデーション方法を掲載します。そして、255字以上のホスト名を考慮に入れた@ockeghem氏のブログの内容に関して、「RFC規格外のことを説明するのはセキュリティ専門家として問題では？」と問題視します。

　それに加えて、「バリデーションの基準はアプリケーション仕様」とする徳丸氏の主張に対し、「入力バリデーションはセキュリティ仕様であり、ISO27000やSANSで一番のセキュリティ対策である入力バリデーションをないがしろにするのはセキュリティ専門家として問題があるのでは？」と@ockeghem氏に問い掛けます。

　そして自身のホスト名バリデーションのやり方を書いたブログに対する@ockeghem氏の「バグがある」というはてなブックマークのコメントに対し、@yohgaki氏は「そんな細かいことより入力バリデーションはセキュリティ対策なのか」の論争を再度取り上げます。対して@ockeghem氏は「セキュリティ対策ではない」と返答します。

　このやり取りに対して、ISO27000シリーズは情報管理をどう管理してどう実施していくかを決める基準で、バリデーションやセキュリティに触れたものではないと@yukimao氏は指摘します。それに対して@yohgaki氏は、PCI DSSやCWE/SANS TOP 25の内容からも、入力バリデーションを実施すべきと主張します。

　@yohgaki氏はその後もブログで主張を繰り広げたり、@ockeghem氏のブログに訂正依頼を出したりした上で、@ockeghem氏のセキュリティ対策は「主観のセキュリティ対策でWAFを売るためのステルスマーケティングだ」と主張します。が、結局@ockeghem氏が関わるのが面倒になったのか@yohgaki氏に終結を告げ、ここ数年にわたった論争は終わりを迎えました。

　その後@yohgaki氏は入力バリデーションはISO27000に規格化されている、規格に則ったセキュリティ対策だと、持論の優位性を述べます。

　その後@s_hskz氏が、「ISO27000:2014で書かれているValidationは入力バリデーションとは関係ない」という指摘をしますが、@yohgaki氏は「以前の規格に書かれている」と反論します。これに対して@s_hskz氏は、@yohgaki氏が著書やブログに書いたプログラムにバグが残っていることが多い原因が、「そもそもISO27000に沿って開発していないからだ」と指摘しましたが、@yohgaki氏が返答することはありませんでした。