概要

「安全なWebアプリケーションの作り方」という包括的にWeb技術のセキュリティが書かれた本があるのですが、それを久々に読んで盲点だったなーと思うことをまとめました。

に分けてまとめていきます。

アプリケーションレイヤーで対策できること

基本はhtmlspecialcharsですが、それ以外に盲点になりそうな対策として、クッキーにHttpOnly属性を付与するというのがあります。

セッションIDのCookieにHttpOnlyを付与することで、万が一XSS脆弱性があってもセッションIDが盗まれることがなくなります。

HttpOnlyというのは、JavaScriptなどのHttp以外の読み取りに対するOnlyなんですね。

滅多にはないと思いますが、動的に生成されるURLが画像に対するhrefとかsrcだった場合、javascript:HOGEHOGEという形式の文字列がそこに入ると任意のJavaScriptを実行できてしまいます。

なので、そういった出力パタメータにはhttp(s)から始まっているかどうかのチェッカーを挟みましょう。

とはいえあるかな・・・だいたいURLはサーバー側で生成している気がする。が。

CGMなどでユーザーにHTMLタグの入力を許可する場合は表示していい要素だけ逃してエスケープしよう

https://github.com/paquettg/php-html-parser
こういうライブラリを使って、HTMLの内容をパースして個別でタグに包んであげる、という感じでしょうかね。その際に中身をエスケープすれば無事で済みそうです。

もちろん静的プレースホルダー利用一択なのはわかった上で。さらにやったほうがいいこと。

これはうっかりしそう。
アプリケーション側から利用するデータベースユーザーが例えばTableの削除権限を持っている必要はありませんし。

データベース消されるとかが一番ひどいので、こういった根っこの対策はやっておいて損は無さそう。

例えばこのページに権限の一覧が書かれているようなので参考までに。
権限の種類と設定されている権限の確認

何度見てもCSRFはどういう脆弱性なのか説明が難しいですね。

ざっくりいうと、僕が作ったサイトからTwitterのパスワード変更画面にリクエストを飛ばして、それをTwitterが承認したらやばいよねってやつです。
偽サイトをいくらでも作れてしまいます。

なので、CSRF対策とは、あるリクエストが本物のユーザーによる当サイトからのアクセスであることを証明する手段ということになります。

全ページに上記の対策をしたら大げさだし、そもそも自然流入してくる人たちまで弾かれちゃうのでやめましょう。

トークン埋め込みが一般的だけど・・・
JWTが一昔前に流行りましたね。
JWT（JSON Web Token）でCSRF脆弱性を回避できるワケを調べてみた話

このQiita見たら多分思い出せる。手前味噌ですが。

こういうのちゃんとキャッチアップしないとなぁ。。。
https://jvn.jp/rss/

SSHは特定のIPからしか許可しないようにしましょう。

上記の記事のように検知する仕組みを作るのもいいなと思います。

総当たり攻撃を仕掛けられる可能性があるので、パスワード認証はそもそも避けておくべきです。

Linuxサーバーのセキュリティに関してはこの記事がとてもわかり易くてよかったです。

そこそこセキュアなlinuxサーバーを作る

Webセキュリティは壊滅的なリスクを回避するためのスキルであるがゆえに、どうしても経営層とか企画レイヤーから甘く見られてしまう背景もあると思っていて、意識的にエンジニアサイドが身につけていかないと、と個人的には危機感を持って学んでいきたいなーと思っています。

おすすめのサイト、書籍などありましたら是非コメントやTwitterにて教えていただければ幸いです！！