00:06
はい、みなさんこんにちは。keethことくわはらです。本日もやっていきましょう。
keethのエンジニア雑談チャンネル。
この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、
雑談形式で発信していきたいと思います。
で、今日は、昨日はちらっと言ったんですけども、
最近、トクマル本を読んでいて、トクマル試験っていうのがあるんですけど、
ウェブアプリケーションセキュリティ基礎試験みたいな名前だった気がします。
正確な名前はすみません。忘れましたけど。
通称トクマル試験っていう試験があって、それを受けてみようというところです。
受けてみようというか、会社のいろんな施策があって、その中、会社のお金で、
僕は受けさせてもらえるっていう感じですけど、それを受けてみるところですね。
試験ギリギリになって勉強しているので、落ちる可能性はありますけど、
全然やれると信じて頑張ってます。
が、本がまだ1週しか終わってないので、できれば3週したいなと思ってますね。
全然僕自信ないので、頑張りたいんですけど、
そのトクマル本を読んでいて感じたことの一つとして、
やっぱりまずバリデーションって大事だってすごく思ったっていう。
今日はそういう話をしようかなと思ってます。
意外にですね、バリデーションをちゃんとやってないサイトって、
まあ、だいぶ減りましたし、もう最近滅多に見なくなったんですけど、
たまに見ますね。
そして、昨日の職業用で言えばよかったんですけど、
新しいサイトとか、そういうフォームを持つもの、テキストボックスとか、
ファイルテンプとか、ああいうのを一応フォームと言ったらですね、
フォームの要素とかって言うんですけど、
そのフォームを使ったウェブアプリケーションとかウェブサイトの
ページにアクセスした時に、僕はちょっとついついフォームでたまにやります。
最初にダブルクオートとかシングルクオートを付けてから
送ってみるみたいなことを。
あんまりよろしくないし、そういうのは本来はテスターとか中のエンジニアがやるべきで、
外からやるのはあんまりよろしくないんで、
これは僕がダメな人間ですっていうところの発表になってしまうんですけど、
たまにやります。
で、バリエーションやってなかったりとか、
僕が昔テスターでもあったので、
いわゆる境界値テストっていうものを結構やるんですね。
境界値っていうのは、例えばテキストボックス、テキストエリアじゃなくて、
一行のテキストボックスの入力フォームに対して、
何文字みたいな最大文字数、マックスレングスとかを設定したりするんですけど、
そのレングスが本当に設定されていても、
それを超えた時にちゃんと投げてバリエーションが引っかかるのかなみたいな、
もしくは数字だけを入力させるボックスがあるじゃないですか。
で、あれに対してちゃんと数字以外のものを入れて、
入れられなくできているかどうか。
それを開発者ツールとか開いて、
設定をして、それで送った時にちゃんとエラーが起きるのかなみたいなことを、
本当やっちゃダメなんですけど、
僕がたまにそういうのを入力して送ったり。
そういう文字種チェックだったり、境界値テストっていうのは、
僕がちょいちょいやるんですけど。
で、文字種チェックはちなみに、
ちょっと余談を挟むんですけど、
03:01
いろんな文字種類があるじゃないですか。
単純に半角、全角の違いがありますし、
ひらがな、カタガナ、漢字もありますし、
それでもバイト文字とか言ったりしますけど。
とか、英数字ですね。
英字と数字で分けられたり、記号もありますし、
サロゲートペア文字みたいなすごい特殊な文字もあったりとか、
漢字の中でも旧漢字とかありますよね。
高いって漢字をはしご高って言ったりしますね。
はしごみたいに見える高いっていう漢字もあったりしますし、
どこまで細かくやるかはそのサイト次第ですけど、
そういういろんな文字の種類があるので、
それぞれに対してチェックできてますかみたいなことをやったりします。
で、そこでバリデーションかかってるかっていうのを気にしてるんですけど、
たまにはバリデーションをやっていないサイトもあります。
で、それはやっぱりよろしくないよねっていうのがあって、
なぜかというと、とくまる本読んでる中でバリデーションをすると、
何がいいかというと、実はセキュリティ対策に
結果的につながるケースがあるよってそういう話をしてます。
さっきも言いましたけど、入力フォームの例えば文字種類を
単純に英数字だけとかにしてた場合は、
インジェクション、クロスサイトスクリプティングとかは仕掛けにくくなる。
多分仕掛けられないのかな?
いやいや、できる可能性はありますけど。
単純に文字種とかで記号が入力できなかったら、
例えば、SQLインジェクションとかクリスタルスクリプティングもそうですけど、
何かしらの記号ですね、ダブルクオートからスタートしたりとか、
セミコロンで挟んで後ろにSQL文書いたりとかするんですけど、
必ず最初に何かの記号をつけないと
そういうインジェクションとかXSSとかはできないはずなので、
文字種類を単純に英数字だけとか数字だけとかに
ちゃんとフォームフォームに縛っておけば、
結果的にはこういうことのセキュリティ対策をしたことにも繋がったりします。
あとは物によっては文字の数とかですね。
マックスレングスが何本ですかね。
生年月日。月日とかだとそれぞれ月と日で、
単純に多分数字になってるし、
マックスレングスも2文字しかないじゃないですか。
ってなると記号を入れて後1文字しか入れないので、
何かしら悪いことをすることはできないんですよね。
文字数が足りないから。っていうのもあったりするので、
ちゃんとやっぱりバリデーションはやるべきで、
そういうことをすることでセキュリティ対策になるので、
セキュリティ対策がどうしたらいいかわかんないとか、
今からどうするみたいなところでやるんだったら、
まずまず先にバリデーションを入れましょうっていうのが
僕は観点と思ったりはしました。
まずって言い出すと他にもいっぱいあると思いますけど、
アプリケーション開発者としてやれることとしては、
やはりバリデーションが大事だなって思ったりします。
もちろんバリデーションの大事さは、
セキュリティ対策だけではなくて、ユーザビリティもありますよ。
バリデーションってバックエンド、
フォームから送信した、ポストしたときにチェックをするのか、
そもそもポストする前、入力が終わりましたと。
で、そのフォームからブラーしたとき、
フォーカスが外れたときとかにチェックをかける。
もしくは入力、あれです。
06:01
いろんな入力キーボードとか、スマホもありますけど、
キーアップですね。
オンキーアップとかで入力終わったときに、
JavaScriptを走らせてチェックをするということもできたりします。
そういうことで、ポストしてエラーになってまた入力し直すんだったら、
そのポストして帰ってくるまでの時間がもったいないので、
それまでにパッとチェックをかけてくれたほうがユーザーとしてはありがたいし、
適宜適宜何が大事かとか、何がいけなかったっていうのを教えてくれながらやるほうが、
サポーターとして手元にいてくれる感覚があるのですごくありがたいです。
そういうユーザビリティの観点も深みすると、
バリデーションを入れておくことの大事さっていうのはより強まるよねっていう話です。
逆にバリデーションかかってないサイトでお買い物したりとか、
何かしら自分の個人情報を入れて送信する。
ちょっと怖さはありますよ。
そういうITリテアシーがない方もまだまだ多いと思いますので、
そういう方は知らず知らず投げちゃう可能性ありますけど、
とはいえないところは怖いなと思います。
そういう基準の一つにしていただくのがいいのかなと思いましたね。
先ほど述べましたXSS、クロスサイトスクリッピングですけど、
なぜXかっていう余談は、皆さんご存知の通りだと思いますけど、
装飾の方のCSSってカスケーリングスタイルシートの略。
あれと被るからXになったってことですね。
クロスっていう英単語は頭Cから始まるので、
カスケーリングスタイルシートと被るので、
クロス、つまりXのSSになったってそういうお話です。
そういう余談もちゃんとココアラボには書いてあったりします。
あとバリデーションもあり、
一応さっき言った文字集とか文字数ですね。
大体最小文字数とかありますけど、
いわゆる制御文字とかの含む文字集の検証とか、
あとエンコーディングの検証とかもバックエンド側ではやれるはずなので、
やったりすると良いかもしれないですね。
ちゃんとUDFAとなってますかとか、
このサイトは日本語オンリーだから、
シフト実質ですかみたいなところを見たりします。
シフト実質だけのサイトって最近は減ってきてると思いますけど、
そういうサイトもなくはないし、
観光庁とかはむしろあるかもしれないですね。
この観光庁のサイトは日本国籍の人しか使わないみたいな。
とかはありません。
住民とっている人しか使わないサイトだから、
日本語限定にするっていうのがある意味いい話であるかもしれない。
バリデーションはやろうと思ったらどこまでもできてしまうし、
どこまでも突き詰めようと思ったら突き詰められるんですけど、
やらないよりは絶対やったほうがいいなとは思います。
バリデーションの実装をするのは結構ですけど、
そうすると対応する範囲とか深さを求めると、
必然的にテストケースが増えていく。
ユニットテストなので、
1個1個のケース自体は一瞬で書けるとは思うので、
そんなに工数かからないみたいな話はありますけど、
テストって単純に1個1個単品だけで終わらせるのではなくて、
09:02
組み合わせテストとかやったりするし、
複合テストすると思うので、
結果テストケースって爆発的に増えたりするんですよね。
そういうのもあるので、
どこまでちゃんと担保するかっていうのは結構難しいところでありますけど、
必ず1回は通せるようなテストケースは書いたほうがいいとはもちろん思いますね。
はい。
またテストの話をしだすのはちょっと長くなるんですけど、
基本的には正常系よりもエラー系の異常系のテストのほうが圧倒的に多いですからね。
正常系は1本だいたい、1本なし2本ぐらいかな基本的には。
1つのユースケースに対して。
それに対してのエラーってたくさん出てくるんですね。
というので、とくまる本は本当にいい本だなと思った次第ではありますが、
セキュリティ対策をちゃんとするんだったら、
バリデーションってただの1要素でしかないし、
本来のセキュリティ対策のためのバリデーションではないですから。
ユーザビリティ観点が一番強い気はしますけど、
やらないよりはやったほうがいいというところで。
はい。
あとバックエンドだけで話でいくのであれば、
入力フォームからポストします。
で、バックエンド側のほうで受け取りますけど、
その時に単純にバリデーションだけをするのではなくて、
ちゃんとエスケープがされてますかっていうのをチェックしたほうがいいと思います。
エスケープ自体はフロント側で設定して投げるほうが本当は良いと思いますけど、
バックエンド側でも来た時にそのまま勝利するのではなくてということですね。
なのでバリデーションをどこでやるかっていうと、
フロントとバックエンドできれば両方でやるのが理想的ではあるかなと思います。
で、エンコーディングですね。
HTMLだったら、PHPだとHTMLスペシャルキャラクターセット、
関数がそういう名前の関数が確かあった気がします。
HTMLスペシャルキャラSが終わった気がしますけど、
っていうような関数があって、それにかけておくと
HTMLのタグみたいなやつがちゃんとエスケープをされて投げるみたいなことをしてくれるんで、
フロント側でもちゃんとエスケープ関数をしっかりして投げるのも一つ大事なことではありますね。
やらないでそのまま出したり、送ってしまったり、
逆に受け取ったものをそのまま表示するだけとかならまだ許せるんじゃないか、
そんな問題ない気がしますけど、
受け取ったものに対して何か入力フォームに自動に入れたりとかするとなると話は変わってくるので、
受け取った値に対してもちゃんと検査をかけるっていうのはやったほうがいいだろうなと思いますので。
これはちょっとバリデーションとは違う話ですけど、
セキュリティ対策としてやるんだったら、
エスケープっていう処理もしっかり入れましょうというところです。
あと、エスケープ処理とセットでやるんだったら、
基本的にはシングルクオートではなくてダブルクオートで書いたほうがいいと。
HTMLのタグの属性ですね。
アトリビューツのところは基本的にはダブルクオーテーションで書きましょう。
ことが前ドクマラボにも書かれてましたね。
などなど。
セキュリティ対策の話をしだすともっともっとたくさんあるし、
時間が膨大にいくんですけど、
今日はその中でもバリデーションに関わるという、
関連するお話をしてみました。
何か参考になれば幸いですし、
そんな当たり前だよって言ってる方は大丈夫だと思います。
12:02
今から始める方とか駆け出しの方は、
そこからまずはやっていただくとこが良いのかなって思った次第ですね。
僕もそんなに専門家ではないし、強くはないので、
一緒に勉強していけたらと思いますし、
徳丸試験がほんと目の前なので、
もうあと、明日、明後日、
3日ぐらいはずっと徳丸試験のお話するかもしれないですけど、
ご用意していただければ幸いです。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
