基本的なWebセキュリティ その2 第03回 20年02月 / 最終更新：2020.02.19
前回は「パスワードの保存」について、言及をしていきました。
それ以外のWebセキュリティで、比較的よく出てくるもの、言い換えると「これくらいは対応をしておきたいもの」を、いくつかチョイスして説明をしていきたいと思います。
まず、一番によく出てくる脆弱性が「SQLインジェクション」です。これは一般のニュースにも出てくるので、ご存じの方も多いかと思います。
この脆弱性は、端的には「DBに対して、読んだり書いたり消したりする事ができる」脆弱性です。もう少しだけ技術的な言い方をすると「サービス提供側が、意図/想定しないSQL文を実行させる事が出来る」脆弱性です。
多くのデータはRDBに保存される事が多いと思われます。そういった情報を閲覧されてしまうと、内容によっては「外部には見られたくないもの」が含まれている事もあろうかと思います。
また、例えば「クラッカー用の管理者アカウントを追加される」といった事も、大変に「避けたい」所かと思います。
データを削除する事も出来るので、理屈からいくと「サービスを停止させる」事もまた、可能です。
さてこの限りなく厄介なSQLインジェクションですが。厄介な事もあって比較的「これを意識した実装」がなされている事は多いか、と思います。
とはいえ勿論「出来ていない」事も実際にありますので、対応が出来ているかどうかの確認をとるとよいでしょう。
SQLインジェクションの対策で、最も単純かつ確実なのは「SQLの組み立てに文字列連結は使わず、値の埋め込みにはプレースホルダ(プリペアドステートメント)を使う」のが一番です。
ただ、例えば「入力された項目を使っての検索」など、多少動的な処理が出てくる事もあると思うので、そういった時は「外部から入ってくる値をSQL文に埋め込む時はプレースホルダ(プリペアドステートメント)を使う」というルールが、幾分現実的です。
一方で「組み立てる全ての値をエスケープ処理する」というのもまた、一つの正しい指針になります。
いずれにしても「外部起因の値(DBの中に入っているデータも、プログラムから見たら"外部"です)」の値を「そのままSQLとして組み立てる」とSQLインジェクションが発生しますので、その辺りの実装を、注意したり指示したり確認したりするのは、とても大切かと思います。
また、もし「エスケープ」を選択する場合「自作は絶対にアウト(公式に出ているものを使いましょう)」を合わせて覚えておくとよいでしょう。
次にやはりよく拝見するのがXSS(Cross Site Scripting)になります。クロスサイトスクリプティング、と呼称します。
先頭の略語をみるとCSSですが、これだとCascading Style Sheetsと見分けが付かないので、脆弱性のほうのクロスサイトスクリプティングはXSSと略されます。
この脆弱性は、HTMLに対して「攻撃になりうるJavaScriptやHTML等を埋め込む」等の事象を引き起こします。
また、XSSは「それを踏み台にさらに別の攻撃を仕掛ける」ような事にも使われるので、しっかりと対応をしておきたいものです。
XSSの対策は「出力時に、出力する全ての要素をエスケープする」という方法になります。
最近のテンプレートエンジンだと「そもそもデフォルトで、出力は全てエスケープされる」ものもあり、そういった場合には「出力をエスケープしている」という意識は大分と薄れてくる事もあるか、と思うのですが。
最低でも開発時に、一度は「エスケープ処理はどのようになっているのか？」を確認するとよいと思います。
次回、もうあといくつか、基本的なWebセキュリティについてお話をしていきたいと思います。
サービス・ソリューション
