Web脆弱性を考えるときの参考に少しでもなれば…

はじめに

ipaのリンク本家のもの切れていたものアーカイブで補っていますが、リンク404の時は以下のようにURL作成して試してみてください。
https://warp.ndl.go.jp/info:ndljp/pid/12446699/<"ここにwww以降のurl">
参考:https://twitter.com/kazken3/status/1642110987670282241?s=20

ここに書かれたことが全てではありません。
そもそも書いている本人が教えて欲しいぐらいの気持ちです(・ ・｀)な！！何！！！
ここではこれから少しでもWeb脆弱性向けの本やサイトを見る上での手助けができればいいなと書いています。
そして現在100%の実装だとしても新しい攻撃は増え続けます。
新しい攻撃には新しい対策を。
完璧なセキュリティーホームが無いように完璧なセキュリティーWebもありません。

『はは〜〜〜ん。ってことはどうせ運だろ』
っと思っているかたは、家に泥棒が入ってくるのはどうせ運だからと家の鍵を閉めないようなものです。

できることはする。これ大事です。大事！大事！。

逆に家に監視カメラをつけたり、常に警備隊を配置しているかたはそうそういないと思います。

お金もかかりますし労力もかかります。しかしそれぐらい労力をかけても守りたいものだってあるはず。
宝石店や銀行などなど、あとちょーお金持ちの家なら何億何千ものする絵などがあれば守りたいでしょう！

そうなんです。

セキュリティーを考えるときは、どれぐらいのものを守りたいから、これだけのことをする的なことも考えないといけません。
他にもこれだけ狙われるはずだからこれだけの対策をするなど。

仮にもし家に食パン一枚しかおいていなかったりすれば、なかなか狙われない気もします。

や、いるかもしれませんね。
**『あそこの家においてある食パンがほしい！どんな手を使ってでも食パンを盗んでやる』**的な人が。

しかしその食パンが100円で同じものを買うことができるならば、何万もかけて監視カメラをつける必要があるでしょうか？…

冗談はさておき…

そろそろ本題へ。

まず考えないといけないことの要点

• 秘密な情報は外部にださない(POST、GETの使い分け、httpでなくhttpsで、うっかり大事なセキュリティーIDを見えるところに書いちゃうとか)

• 信用できないものは使わない

• 脆弱性を作らない(SQLインジェクション対策、XSS対策、知られてはいけない値は憶測させない、CSRF対策とか)

• 自分ではできないセキュリティー強化(WAFの導入とか)

• 攻撃されたらいち早くみつけられるようにする(ログ監視するとか)

• 定期的にデータのバックアップを行う

• 攻撃されたら報告する(IPAに報告とか、警察に被害報告とか)

• 確認する(いつもと違うところからログインされていますが、あなたログインしましたかのメール送信とか)

• 攻撃されたら対策を行う(すぐなおす、すぐになおせなく被害増大するぐらいならサイト止めるとか)

ここに書いてあることも参考になります。

見て置きたい本やサイト

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版(本)
IPA(サイト)
OWASP(サイト)
徳丸浩の日記(サイト)

あと、
OWASP 2017年版PDF
OWASP 2018年版PDF

おそらく新しい2019年版は2019年終わって、2020年頭ぐらいにでるのかな？と感じています。

サイトで考える前に家で考えてみる

• 家がもしスケルトンなら見られたくないことも見られてしまう

- **家がもし穴ぼこなら聞かれたくないことも聞かれてしまう**

- **誰でもWelcomeな家なら悪い人が入ってくることだってありえる**

これを見て、
『ありえない。こんなのサイトではありえない』っと思うかもしれません。
しかし本当にそうでしょうか？

例えば、httpsに対応していないサイトは穴ぼこの家に相当するのではないでしょうか？なぜなら通信経路が丸見えなのですから…。
他にも便利だからとライブラリを入れてたら、誰でもWelcomeな家と同じではないのでしょうか？その便利なライブラリを全て解読してから大丈夫だと使っている方は少ないのではないでしょうか？
サイトも同じことだと私は考えています。こういうことをいかにシンプルに考えれるようになるかが少しでもセキュリティについて詳しくなる近道なのではないかと考えています。私もまだまだできていないのでそんな大きく言えないのですが…。

しかし、こんなことを言われてもいまいちピント来ないかと思います。
一番は詳しく知っている本やサイトを見て勉強するのが正しい知識になると思うのですが、ここでも少しお話させていただければと思います。

脆弱性(例)

※あくまで概念的なこともあるので詳しく本当に詳しく知りたい方は以下の参考サイトや本などがオススメとなっています。

例1
CSRF(クロスサイトリクエストフォージェリー)
どんな攻撃か:ログインしているユーザーを狙った攻撃
具体的説明:
想像してください。もし仮に銀行サイトにログインしているとします。
その銀行サイトで何かを行うときにはリクエストと言うものを送ります。
そのリクエストとは、
https://aaaaa?a=aaa&c=asa…
的なURLです。
この中にログインしていますよ。これおこなってくださいねの情報が入っています。
ログインしているかの情報はこのURLを送るときに勝手につくことを想像してください。
ってことはこのURLを送らせるようにすれば…

では果たしてそれはどんなときでしょうか？
例えばリンクってタイトルつけられますよね。https://aaaaaとか書かなくても言い訳です。
例えば[これは〇〇のサイトです。クリックしたら1万円送ります]と書いてリンクを貼ることもできるわけです。

いやいや、そんな都合よくいくわけないじゃないかと思うかもしれません。
そんなこともありません。例えばTwitterをみている人はほぼTwitterにログインしていると思います。
でたまたまみたツイッターの面白そうなリンクが実は勝手に何かをツイートしてしまうようなリンクだったら？

〇〇の銀行サイトにログインしていそうな人が、たまたま〇〇の銀行を偽っているサイトでそのようなリンクがあったら…？

結構この攻撃が実行される可能性が見えてきました(/ω＼)

実際の攻撃はもう少し複雑ですが概念は変わらないと感じています。
では対策としてはどのようなことが考えられるか？
まず何も対策がされていなければ以下の状態になります。

ではこれをどう回避するか？それはその使っているサイトでしか持っていない情報を渡してもらうこと。
それはリクエストを送るときにそのサイトでしか教えてもらってない秘密の暗号も一緒に送ってもらうこと。

一番わかりやすいサイト乗せておきます。
https://techacademy.jp/magazine/19300

秘密の暗号も期限付きならなおいいですね。ちなみに図だと以下のような感じです

もちろんこの感じなら他にも対策はあります。
本当にユーザーかを再度アカウントのIDとパスワードを教えてもらって確認するとか。
ま、ユーザーがめんどくさい、使いにくいと思われたりもしますが、大事な実行ならこれぐらいしたいですよね。

他にもメールで期限つきコード送ってそれを入力してもらうとかも。

きっと考えれば悪用する人も対策する人ももっと色々出てくるかもしれません。
メールで期限つきコードはログインなどでよく行われたりしているきもしますが…。

例2
XSS(クロスサイトスクリプティング)
どんな攻撃か:意図しないテキスト入力などで攻撃されてしまう
具体的説明:
想像してください。あなたのサイトでテキスト入力実行するところで、その実行によって書いたjsコードや書いたHTMLが反映されるとしたら…

ないって〜〜〜〜そんなことっと思われますよね。しかし実際にHTMLにjsを追記することも、HTMLを追記することもできますよね？逆に考えるといいかもしれません。ここに入力して送信したら送信jsが実行できるようなサイト、HTMLタグを挿入させるようなサイト。対策を行わなければこのようなことがおきて、jsなら保存していた情報が抜き取られるなんてこともあり得るのです。HTMLもどんだけの量書いてもいいなら勝手にformタグを入れられるってこともあります。
ではそれを実行させないようにするのは、そこでhtmlなた<h1>のような<を認識させないようにするとかです。入力されなければそもそも\

a\

とか打たれても何も起こらないのですから。一番はこれが基本です。入力されてもそれを認識されなければとかも。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版(本)
にそれら書いてあるので。ぜひ。
ここでそれを書くとなんけいけないような気がして本の方の紹介となります。ごめんなさい。

他にも文字数制限することでそもそもスクリプト実行できる文字数打たせないとかもありますよね！
WAFでも防御できるみたいなのでいいかもしれません。
https://www.shadan-kun.com/blog/measure/1052/
あれかな？これはリクエストの内容みておかしかったら弾いてくれるって感じなのかな？他にも色々ありますが！！

本にも書いてありますが、WAFの導入が自分たちで行う対策より安全なこともあるとか…。

セキュリテイを考える時に抑えておくべき用語を私的視点で厳選してご紹介

XMLHttpRequest
jsから送るリクエスト。画面表示一部だけ変えるのにjsからapi送って、戻って来た値で画面の一部変える。その時に送るリクエストのこと。ブラウザ上のjsから送られてくるため、以下のSame-Origin Policy(SOP)チェックが発生する。のため、これを利用して、XMLHttpRequestでしかつけれない、独自のヘッダを使ってCSRF対策を行うとか。
Referer
現在のページにアクセスする前のリンク。
例えば、[https://qiita.com] → [https://qiita.com/1]
のアクセスの場合
[https://qiita.com/1]の中の[Referer]は[https://qiita.com]
これを確認することで意図したページ遷移が行われているかの確認で確認されることもあるそうですが、ブラウザの設定などによって消されることも多いため、あまり有効ではない。逆に大事なものをURLにつけておくとこのリファラーの大事な値抜き取られて悪用されるなんてことも起こります。
ちなみにこの[Referer]はヘッダーの項目の中の一つ。
POST
リクエストを送る送り方的な意味で捉えてくれればOKかと。POSTで送るデータ送信ならデータを見られない。Getで送るデータ送信はデータを見られる的なことから、大事なものはPOSTで送るの必須。こわかったら全部POSTにしたいよねって思う。ここで最初私はGETの必要性がわからなかったがこのデータだとこのページにアクセスする的なものだったらSEO的には必要何だろうなと感じ納得した感じです。そうしないとリンクが全てどのページも同じならGoogleでページ紹介されても飛ばされるのは全部Homeじゃ…ってなりますもんね。
SSL通信
暗号化通信。『アイウエオ』という文字列がてくてく歩いていれば、あれは『アイウエオ』と分かってしまう。なので『アイウエオ』を『sdjlsjfksjgl』といった感じにするもの。
[http://]ではなく[https://]のことをいいます。
実際は暗号化通信のみではないです。詳しくは以下サイトを参考にしてください。
SSLとは？
Same-Origin Policy(SOP)
「スキーム、ホスト、ポート」が同じであるかの確認
『https://qiita.com:80/』の場合『httpsがスキーム』、『qiita.comがホスト』、『80がポート』である。これと同じ感じで来たものは同じオリジンとなるがこれのどれかが異なれば違うとなる。例えば『https://qiitwa.com:80/』。よくみるとホスト名が『qiitwa.com』だということがわかる。
クロスオリジン
上記のような「スキーム、ホスト、ポート」が同じでないこと。この場合、許可されていなければレスポンスにアクセスできない。以下のようなイメージ。

だがしかし、これはあくまでブラウザ上の話。PHPとかからだったアクセスできます！！
HttpOnly(クッキーの属性)
php.iniでの設定必要
この属性指定があるとクッキーがjsからアクセスできなくなる。
Secure(クッキーの属性)
HTTPSの場合のみクッキーを送信する設定

よく聞かれる?WebStorageとcookieのセキュアな保存はどっちが好ましい？

https://postd.cc/web-storage-the-lesser-evil-for-session-tokens/
ここでの私が大事だと思う論点としては、WebStorageはXSSなどの脆弱性対策がなされていなければ勝手に抜き取られてしまうこと。cookieは勝手に送られてしまうこと。もちろんcookieだと属性指定がなされていれば同じドメイン。つまりは同じサイトからのリクエストでないと弾かれてしまうなどがあるのですが、同じサイトでもXSS脆弱性があればサイト自体改変されて同じドメインでも送るようなことはできてしまう。よって私が思うに、どっちも危険。どっちにしろ使うならそれ相応の対策が必要。対策していなければどっちも危険に辿りつきました。

参考本と参考サイト

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版(本)
IPA(サイト)
OWASP(サイト)
株式会社LAC(サイト)

CSRF（クロスサイトリクエストフォージェリ）の意味とその対策
クロスサイトリクエストフォージェリ(具体的な被害例が乗っています)
「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
【ハッシュ値】
リクエスト強要（CSRF）対策
クロスサイトリクエストフォージェリ（CSRF）とは？
[【PHP】CSRFとは-----対策]
(https://qiita.com/Chelsea/items/edebb04254461d213f83)
とっても簡単なCSRF対策
このWeb APIってCSRF対策出来てますか？って質問にこたえよう
サイトを安全に！PHPでcsrf対策を行う方法【初心者向け
認証用トークンはクッキーに保存すべき？ローカルストレージに保存すべき？
葉っぱ日記
[クロスドメイン問題と Access-Control-Allow-Origin ヘッダ]
(http://dotnsf.blog.jp/archives/1063051117.html)
JavaScript初級者から中級者になろう
独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？
http://d.hatena.ne.jp/momijiame/20111204/1323000833

最後に

結局はそのような攻撃があって、それについてどのように対応しなければいけないかをしっかり知っておくことが必要だと思いました。そのためには今の知識では不十分なのでこれから色々な本やサイトを見させてもらい勉強させていただきたいなと感じました。しかしやはりセキュリティーを考える上ではとりあえずWAFいれておきたいなとも思いました。