エンジニアが今いちばん知りたいことに答えるイベント「MANABIYA -teratail Developer Days-」レポート

#3 teratailのQ&Aから学ぶWebセキュリティの現状

この記事を読むのに必要な時間:およそ 3 分

ITエンジニア特化型Q&Aフォーラムteratailが主催となり,2018年3月24,25日の2日間に渡り開催されたMANABIYA -teratail Developer Days-ではITエンジニアの問題解決カンファレンスをテーマに「疑問」を主題としたセッションが多く実施されました。その中から,徳丸 浩さんによる基調講演「teratailのQ&Aから学ぶWebセキュリティの現状」のレポートをお送りします。

徳丸氏による基調講演の模様

徳丸氏による基調講演の模様

セキュリティのプロがteratailで回答し続ける理由

講演は徳丸さんの自己紹介から始まりました。セキュリティを仕事としてセキュリティの書籍『体系的に学ぶ安全なWebアプリケーションの作り方』⁠SBリエイティブ)『徳丸浩のWebセキュリティ教室』⁠日経BP社)を執筆し,脆弱性診断やコンサルティング業務を行う徳丸さんが,無償でYahoo!知恵袋やteratailなどで回答し続ける理由は,⁠正しい情報を知ってほしいという衝動や,間違った情報が書かれていると正したくなる,また課題が解決されていない状態で放置されているのがムズムズするから」ということです。

次に,生活のためだけに開発している人やあまり勉強をしない人が,どうやって開発をしているかという点を問題提起されました。

本を読み勉強する人,インターネット検索をする人,Q&Aサイトで質問する人,職場の先輩に聞く人も多くいると思います。不勉強な人は多くの場合,インターネット検索やQ&Aサイトのコードをコピペして少し変更して使うでしょう。teratailでも,学校の宿題や,仕事を丸投げで質問する方がいらっしゃいます。検索して,Q&Aサイトで聞いてつくっていく人が多いという現状があります。これ自体は変えられないと考えています。であれば,変えられない中で何が出来るのかということを考えていたりします。

昔はベストアンサーがついていても脆弱性がある例が多かったのですが,今のQ&Aはだいぶ改善されいるようです。

teratailのQ&Aを覗きながらWeb開発の現状をみる

セキュリティチェックを何処までしたらいいのか

画像

「どのような方法で,どこまでチェックをしているのかを知りたい」という質問に対してですが,徳丸氏は,セキュリティチェックをする前提でなく,まずは脆弱性が入らない方法で開発をしたほうが良いとアドバイスされていました。処理や局面,それぞれどういった個所でどういった脆弱性が入るかを知り,その点を考慮した方法で開発をしたほうが良いと答えています。

続いては,データベースの暗号化方式について,よくセキュリティのリリースなどを読んでいると,暗号化されているのから大丈夫ですというのを見るのですがそういったところについての質問です。

データベースの暗号化方法の選択

画像

「データベースの機能で暗号化するか,アプリケーション側で暗号化するのかどっちが良いのでしょうか」という質問。これに対して徳丸さんは以下のように解説を加えました。

どちらが良いということはなく,目的に応じて選択する必要があります。言語で暗号化して保存すると,SELECT文でデータを取得しても,データは暗号化されています。なので,復号されない限りSQLインジェクション対策として効果があります。しかし,データベースエンジン側で暗号化するとSELECT文でデータを取得すると,データは平文で返ってきます。この場合はSQLインジェクション対策として効果がありません。

では,データベースエンジン側での暗号化は意味が無いのかというと,HDDが盗まれた等の場合,復号鍵と共に盗まれない限り復号が難しいので,そういった場合は意味があります。ただ単純に暗号化するのではなくて,暗号化が求められているかを判断し,正しく暗号化しましょうということですね。

SQLインジェクション対策がわからない

画像

「addslashes関数を使うと良いと本に書いてありましたが,なぜこの関数を使うと良いのかわかりません。」という質問です。回答は「addslashes関数を使うのをやめましょう」なのですが,本当の問題はそういった古い教科書を使って学んでいることです。

まずadslashesがなぜだめなのかということから解説してくださいました。adslashesといえば,昔はMySQLにおいてインジェクション対策の標準でしたが,今は否定されています。MySQLはバックスラッシュを入れてエスケープするという仕様です。ただ,MySQLサーバの設定を変えると,バックスラッシュをエスケープしなくても良いシングルクオートは重ねるという仕様になります。たまたま,MySQLのバックスラッシュでのエスケープとadslashesと合致していたので,MySQLのSQLインジェクション対策の標準となっていたそうです。

また,もう1つ大きな問題があります。文字コードがShift-JISの場合,addslashsesは文字コードを考慮しないため,実際はエスケープ処理が必要ない「ソ」の文字コード(835c)の前半83を「NBH」⁠後半の5cを「¥」と解釈し,¥をエスケープして「¥¥」とします。こういった動作があることからSQLインジェクションが可能になるそうです。

著者プロフィール

上田直樹(うえだなおき)

レバレジーズ株式会社 teratail開発エンジニア

メディアグロースのために企画,フロントエンド,バックエンドの開発までを担当。趣味は野球観戦。主にセ・リーグのTwitterを分析基盤に放り込んでニヤニヤする。

コメント

コメントの記入