ニクニクドットミー

カッコいいおっさんを目指すエンジニアの厳かなブログ

スポンサーリンク

Webの基礎 脆弱性について改めて調べてみた XSS,CSRF,SQLインジェクション,OSコマンドインジェクション

以前、 blog.nikuniku.me というタイトルでヘッダーについて改めて調べてみた。
記事内に

その他のヘッダーについても調べておきたいし、ウェブセキュリティ周りも復習していく予定。

と書いた通り、良く耳にするウェブの脆弱性について調べてみた。

出力に起因する脆弱性

  • XSS

    • 攻撃方法
      • 攻撃スクリプト脆弱性のあるサイトに登録し(DBに保存するなど)訪問した利用者のブラウザ上で悪意あるスクリプトが実行されてしまう(格納型)
        • 入力した内容を登録できる形式のサイトがあった場合にスクリプトタグを登録するなどして攻撃をする。
      • 悪意のあるURLをクリックさせ、脆弱性のあるサイト上でスクリプトを実行させ、クッキー情報などを取得する(反射型XSS
        • 例えば、http://example.com/keyword=usernameのようなURLがあった場合にkeyword=<script>document.cookie</script>をURLに含んだ状態でサイトに遷移させ、サイト上でスクリプトを実行させるなど。
    • 対策
      • <"に対するエスケープ漏れが原因なので、サニタイジングし文字列として画面に表示する。
      • 入力時にvalidateを行い、入力値として数値を期待している場合は数値以外が入力された場合にエラーとする。
      • WAFを導入しXSSに該当するリクエストを遮断する。
  • SQLインジェクション

    • 攻撃方法
      • SQLの呼び出しに不備があるために発生する
      • 例えば、SELECT id FROM users WHERE id = '$id';というSQLがあった場合、$id1';DELETE FROM usersという文字列を渡されてしまうと結果的にこのようなSQLとなりテーブルが削除されてしまう。
        • シングルクォーテーションで囲った値をユーザーが外部から渡す(GETやPOSTの値)場合に悪意あるSQLを組み立てられてしまう。
      • SELECT id FROM users WHERE id = '1';DELETE FROM users;
    • 対策
      • プレースホルダを利用してSQLの組み立てを行う。
      • SELECT id FROM users WHERE id = ?;
        • プレースホルダには2種類あり静的、動的があり、静的プレースホルダを利用するのが良い。
          • 静的(データベース側でがんばる)
            • 値のバインドをデータベースエンジン側で行う。最初にプレースホルダーが付いたSQLがデータベースに登録される。その後、バインド値がデータベースに送られSQLが実行される。
            • SQL文がバインド前に確定するため、プレースホルダに渡すバインド値をクォートする必要がない。そのため、シングルクォートのエスケープ処理が必要ない。
            • 静的プレースホルダをPrepare Statementと呼ぶ。
          • 動的(アプリケーション側でがんばる)
            • バインドをアプリケーション側で行う。バインド時にリテラルは適切に構成されるため、処理系にバグがなければSQLインジェクションは発生しない。
            • 利用するライブラリにエスケープ処理が依存してしまう。
  • コマンドインジェクション

    • 攻撃方法
      • 外部から受け取ったパラメーターをOSのコマンドの引数に渡して実行する場合に悪意のあるコマンドを渡すことで実現する。
      • 例えばアプリケーションからsystem("/usr/sbin/sendmail $mail");を実行する場合に$mail;cat /etc/passwdが渡されるなどして意図していない処理を実行させる。
    • 対策
続きを読む

2021/09/05 ~ 2021/09/11のふりかえり

ワクチン2回目の副反応やばいなという週だった

仕事

  • 久々にEBSのマウント/アンマウントを実施した
    • 久しぶりで緊張したけど面白いなーと思った
  • EBSの拡張に掛かる時間を測りたいと思った
  • プライベートに書くけど妻がワクチン2回目を接種したら副反応でダウンしてしまい、看病が必要になったので午後休みを取った
    • 健康診断がその日にあったけどリスケした

プライベート

  • 土地を買うか迷っていてネットで探しているんだけど土地の説明がわけわからなくて腹が立ってきたので土地に関する書籍を3冊ほど買った
    • 読んで感想を書くつもり
  • 親父が地元に土地があるとのことでgoogle mapで見たけどちょっと微妙だった
    • 両サイドを家で挟まれていた
    • とはいっても現地で見てみると以外と良かったりするのかもしれない
  • ふるさと納税で肉とホンビノス貝を注文した
  • 妻がワクチンの副反応で高熱が出てしまったので看病していた
    • やっと落ち着いたのでなにより
    • ストローは寝たきりの人に最強のツール(横になったままで飲める!)
  • ワクチン2回目の死亡例を聞いてとても不安になってしまい、2回目のワクチンをキャンセルしようかと思った
    • 不安と戦うには情報収集だと思っていろいろ調べた
      • ワクチン接種後にどういう症状が出るのか、予兆はあるのか
      • 違和感を感じたらどこに連絡するのか(明らかに具合が悪くなったら救急車を呼ぶ)
      • 外出時に2回目のワクチンを接種した妻になにかあったらと思い、猫の監視で使っているカメラを起動しておいたり、カメラ越しに異変がわかるように合図を決めておくなどを計画した
    • いまは不安はだいぶ解消されている

See you next time:)

2021/08/29 ~ 2021/09/04のふりかえり

ワクチン打ったりウマ娘の3rdライブを観たりそんな週だった

仕事

  • チームメンバーとパワーランチをした
    • パワーランチはミーティングとランチを兼ねたものみたいだが、今回は業務とは関係ない話題でランチをした
  • 1回目のワクチンを打つためにワクチン休暇を取得した
    • 楽天のクリムゾンハウスで接種したけどオフィスは広くて綺麗で「あーなんかオフィスって懐かしいな」という気持ちになった
    • 対応してもらったスタッフさん、お医者さん、そして楽天に感謝
    • 帰りに芋のお菓子を買った
  • インシデント指揮者を経験
  • 引き続きTerraformを書いている
  • 問いのデザインの読書会が終了
    • 実はまだ全部読めていない...

プライベート

  • 仕事の項目でも書いた1回目のワクチン接種で副反応が出て発熱と倦怠感があった
    • 快復するまで約1日半かかったが発熱に関してはカロナールがよく効いた
    • 倦怠感がなかなか強く、なにか取り組むこともできそうになかったので漫画を読んで寝てた
  • 自分で使う予定のメモアプリのワイヤーフレームを紙とボールペンで書いたけど、我ながら画力もセンスもないのが面白い
    • とはいってもそれで作業が進められそうなのでヨシッ!
    • ワイヤーフレームを作るにはたくさんのツールがあるだろうけど使いこなすのに時間がとっても掛かりそうだったので手っ取り早い手段を取った
  • ウマ娘 3rdライブのDay2を観た(8/29)
    • めっちゃよかった
    • 2022年に4thライブも決定したのでそれまでにがっつりバルクアップしてライブを現地観戦したい
    • マルチアングルを使ってみたけどメインとは違う角度でライブが観られるのはまた面白い発見があるのでこのプランでチケットを買って大正解だった

See you next time:)

2021/08/22 ~ 2021/08/28のふりかえり

暑い。暑すぎるぜ。

仕事

  • 体調が悪い日が続いて月曜はほぼ休んだ。お陰様で回復。
    • ISUCON疲れかもしれない。
  • 問いのデザインの3章に出てくるプロセス目標をちゃんと立てておくのは大事だなとあとで気づいた。
    • これはプロジェクトが終了したあとに「このプロジェクトで他チームとのコミュニケーションが活発になって連携しやすくなった」というような副産物を前もって定義しておこうというもの。
      • いま進めているプロジェクトでは「チーム全体/チーム内で決められてなかったこと」をFix出来たり(Fixしよう進めたり)とプロジェクトの目標達成までの道のりで良い副産物が出ている。定義しておくとさらに出来ることが増えたりすると思っている。
  • 1on1をしたときに「maaaatoさんと話していると前向きな気持ちになってきますね」と嬉しいフィードバックをもらえた。なにか特別なことを言ったつもりはないけど、いまチームで取り組んでいることなどを話したのがよかったのかもしれない。
    • 割と自分はネガティブに取らえてしまって気分が落ちてしまうことが多いなと思っていたのだけど、ストレングス・ファインダーを去年の年末にしたときに「ポジティブ思考」となっていて「え、そうなのか」と驚いたことがある。
    • 最初はネガティブに捉えるのだけどあとから「でもこれってこういうことでいいことだよな」とポジティブな面を見つけて気持ちを盛り返すことがあったなと振り返りが出来たことがある。
    • 物事にはネガティブ、ポジティブがあって両方をバランス良く見る目が必要だと思っているのでこの傾向は自分にとっていい事だと思っている。
  • Google Apps ScriptからTypetalkに投稿するBotを作った。
    • チームをサポートするという意味を込めて「Nanny」命名した。
  • EC2のルートデバイスが枯渇するのコワイ。。。
    • そもそもログインもできない状態になってしまうので拡張ができなくなる。
      • sshは出来たがセッションマネージャーが実行不可能になってしまった。

プライベート

  • ウマ娘 3rdイベント Day1をAbemaで観た。めちゃくちゃ良かった。Day2も楽しみ。
    • マルチアングルにしたけど結局メインアングルしか使わなかった。
    • メインアングルではVRの演出も入っていて迫力があってとても盛り上がった。
    • 会場で見れた人が羨ましい。。。
    • ゲームの最新情報やその他の情報も解禁されて今後が楽しみになった。
  • 結婚記念と付き合った記念をした。
    • 結婚9年目に突入。
    • 付き合ってから14年目に突入。
  • お菓子メーカーのシャトレーゼが気になって近くの店舗を調べて行ってきた。
    • お菓子うまい。
    • 山梨が本社ということもあり、ワインを樽出ししていたので白を飲んでみた。軽い印象で飲みやすい分類。次は赤を飲んでみたい。
  • いつもお世話になっている理容師の方が異動になって別店舗に行くことになった。ちょっと行くには遠くなってしまうので悩む。。。
    • いつも行っているウルフマンバーバー。雰囲気が落ち着いていてとても気に入っている。

See you next time:)

2021/08/15 ~ 08/21の振り返りとISUCON11の感想を添えて

今週は ICL 手術後の一ヶ月検診があったり ISUCON11 に参戦したりした。ISUCON の話にも少しだけ触れておこうと思う。

仕事

  • 普段仕事でペアプロ(ペア作業)をすることが多いのだけどVS Code の Live Shareを試すなどした
    • 1年前くらいに使ったときは挙動が不安定でちょっと利用するのは難しいなとおもったけど今回はサクサク雨後したし、3人でシェアしても問題なかった
  • オペレーション作業をする時にメトリクスを見ながら「あ、この時間帯は避けておこう」と判断するのだけど、今回もやっててよかったなと改めて思った
    • 特にユーザーに影響がないと思っていた作業も実はサーバーリソースを以外と食っているケースがあるので慎重に
  • スクラムセレモニーがだいぶ慣れてきた感じで設けた時間を大きく超過することがなかった
  • 個人開発部が出来たので雑にChromeエクステンション作ってますとチャットに書いたところChromeエクステンションマスターがいたので1on1をしてみていろいろと話しを聞けた++
    • ホットリロードにweb-extがいいよと教えてもらったので試してみる

プライベート

  • 作りかけてまったく動作しなかったChromeエクステンションが動いた
    • github.com
    • エクステンションとして公開しみようと思う(需要はないだろうけど)
  • ICLの一ヶ月後検診が無事終了
    • まだハログレア現象が気になるけど半年もすればだいぶよくなるとのこと
  • 東急プラザ銀座で食べた牛タン利休の「濃い卵」が人生で一番美味しかった。ほんとうに味が濃くて食べた時に醤油に漬けてたのかと思った。それぐらい濃かった。もちろん牛タンも美味しかった
  • 16時間ファスティングを卒業した。朝を抜くと基礎代謝分のカロリーを下回ることが増えてしまったので朝も食べるようにした。ただ夜は20時ぐらいに済ますようにしている。体調はいい感じ
  • ISUCON11に参戦してきた。後述する

ISUCON11の感想

最後に出場したのがISUCON6 or 7だった記憶で約5年ぶりに出場。
毎回3人で出場して主にインフラ面を担当していたのだけど今回はソロで出場してみた(チーム名はpokke)理由はコロナの影響で直接会うことが難しそうだったのとソロでインフラ以外にも手を出してみようと思ったのが理由。オンラインでつないでやることも出来たと思ったけど、ちょっと大変そうに思えたため。
今回はソロでインフラ以外にアプリにも手を出せたのは良かった。ただ、やっぱソロはきつい。当然ながら担当範囲が広くなるのとアプリの改修に没頭してサーバーのリソース状況の把握など全く出来ずという始末。あとスコアの仕様がちゃんと理解する余裕もなかった。。。
結果はもちろん予選敗退でまた来年参戦したい。実力をシンプルに試されるのが本当に面白い。

twitter.com

続きを読む

2021/08/08 ~ 08/14の振り返り

今日も今日とて1週間の振り返りを。一週間経つのは早い。

仕事

  • 一つ目標にしていたところが無事クリアできた
  • PagerDutyのページを毎朝チェックしているんだけどリポートページをちょっと便利にするスクリプトを書いた
    • chromeのエクステンションにする
  • お盆ということもありいろんなミーティングがなかった
  • InteliJに不慣れすぎて疲れた
  • 問いのデザイン勉強会で小さなワークショップを体験した
    • 問い大事

プライベート

  • 読了した
    • お酒は簡単に手に入る「薬物」
    • 依存症の場合は回復するときにいろんな問題が見えてきて余計絶望しやすい
    • シラフの時間が増えたことで筋トレする時間、コードを書く時間が増えた
    • とはいってもお酒は適量であれば時間を楽しく過ごすためのものと思っているので、「特別」な時には飲むことにしている
  • 寝間着を新調しようと思い、ユニクロのエアリズムを試してみたところ、着心地も良いし値段もリーズナブルで大変気に入っている
  • 仕事の欄に書いたchromeエクステンションを書き始めた
    • github.com
    • chromeエクステンションの仕様が全然わかってなくてメッセージパッシングでハマる
    • 全然動いてないので修正する
  • シンエヴァがアマプラで公開されたので2回観た
    • ウルトラマンに出てくるワードが散りばめられていることがわかった
    • 庵野監督の密着も観た
  • 筋トレして2日後くらいに疲労が来るのでグルタミンを買った
  • カロリー制限ダイエットを試しているけどちょっと停滞してきたのでカルニチンを摂ってみる(まだ到着してない)
  • 枯節の鰹節で出汁をとってみたけど荒節とあまりかわらない感じがした
  • Nature Remo2とGoogle Homeを連携させて寝室においたので音声でエアコンのコントロールができるようになった
    • あとなぜか未開封Google Homeが2つ残っている... See you next time:)

強いキャッシュ弱いキャッシュについて改めて調べてみた Cache-Control,Expires,Last-Modified,ETag

キャッシュについて調べることがあったのでそのメモ。強い弱いがあるのを知らなかったりCache-ControlExpiresの関係など理解ができた。やはりキャッシュは複雑だなというのが感想。

キャッシュとは?

なにかしら処理をした結果を保持しておき、その結果が必要になった場合に保持していた内容をレスポンスすることで不必要な処理を省くことができ、結果的にレスポンスを早くすることができる。
例えばDBから値を取得してレスポンスする場合、SQLが時間のかかるものであった場合に結果をキャッシュ(保持しておく)ことで二回目からはSQLの実行を減らすことができる。
一方、古い結果を保持し続けてしまうと新しい結果を取得できない状態になってしまうので、キャッシュする期間やキャッシュする内容は慎重に設計する必要がある。

キャッシュの種類

クエリキャッシュ

RDMS側でクエリをキャシュする。ただしMySQL8.0からは廃止され、PostgreSQLはpgpool-Ⅱを利用して実現するため、実際は使われるケースが少ない。

The query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.

https://dev.mysql.com/doc/refman/5.7/en/query-cache.html

ブラウザキャッシュ(ローカルキャッシュ)

CSS/JavaScript/画像などをブラウザでキャッシュしておき、サーバーから取得する必要がなく高速になる。

経路上のキャッシュ

Proxy/CDNを用いる、配信経路上に配置されたキャッシュ。
キャッシュでオリジンへの負荷を減らすことやクライアントに近い場所へ配置することで経路を最適化したり、大きな配信帯域を確保したりするために導入する

プロキシキャッシュ(ゲートウェイのキャッシュ)

オリジンでのキャッシュ。主にProxyを利用してキャッシュする。
Varnish,nginx,Apache Traffic Serverなど

キャッシュで利用するヘッダー

  • Expire(強いキャッシュ)
  • Cache-Control(強いキャッシュ)
  • Last-Modified(弱いキャッシュ)
  • ETag(弱いキャッシュ)

Expires

レスポンスヘッダーとしてExpiresヘッダーに有効期限を指定することで有効期限が切れるまでは自動的にブラウザにキャッシュされたリソースを参照する。
期限が切れるまではブラウザは一度リソースを取得するとマシン内部にキャッシュするため、一度有効になるとHTTPリクエストをサーバーに送信しなくなる。
Expires: Wed, 04 Aug 2021 13:50:37 GMT

クライアントとサーバー間で時間設定が異なると、うまく設定されないケースがある。

またExpires: -1と設定することでアクセスの1秒前の時間を設定することができるため、Cache-Control: no-cacheと組み合わせることでCache-Controleが有効じゃないブラウザに関しても都度オリジンにリソースの検証を行うことができる。

Cache-Control

Cache-Controlを有効にすることでブラウザにキャッシュが存在する場合にはそのリソースへのリクエストが送信されないようにすることも可能(都度キャッシュが新鮮か確認させることもできる)

  • max-age
    • max-age=600と指定した場合、取得されてから600秒間はブラウザのマシン内にキャッシュされる。

ちなみにCache-ControlExpireが両方設定されている場合はCache-Controlが優先される。

  • shared(public)
    • 複数のクライアントから参照可能な性質を持つ。
    • 1:nでキャッシュする。本来キャッシュできないものでもキャッシュ可能。

  • private
    • 特定のクライアントのみが参照可能な性質を持つ。
    • 1:1でキャッシュする。本来キャッシュできないものでもキャッシュ可能。
    • ユーザー情報を含んだAPIなど、他者から参照されることを防ぐべき情報も含まれるので慎重に扱う

※クライアントに対してキャッシュが1:1を表す図

  • no-cache
    • オリジンサーバーに更新がないか都度確認をし、更新がなければ304ステータスになり、ローカルキャッシュを参照する。更新があればそのデータを取得する。
    • オリジンサーバーに問い合わせをしているのでリクエスト自体は発生している。
  • must-revalidate
    • no-cacheと似た挙動を持つが、キャッシュが有効期限内であればキャッシュの検証を行わないため、リクエストが発生しない。
    • 有効期限が切れている場合はキャッシュの検証を行うためリクエストを発行する。

Last-Modified

レスポンスヘッダーにLast-Modified Wed, 18 Oct 2017 08:00:40 GMTを設定することで次回ブラウザがリクエストを送信するときにはリクエストヘッダーにIf-Modified-Since Wed, 18 Oct 2017 08:00:40 GMTを付与する。
If-Modified-Sinceの日時とリソースの最終変更日を比較し、更新されてなければ304ステータスを返却し、不要なデータの送信を抑えることができる。このIf-Modified-Sinceを含んだGETリクエストを条件付きGETリクエストと呼ぶ。
304 Not Modifiedはレスポンスボディが含まれていない小さなHTTPレスポンス。

ETag

Last-Modifiedと似た挙動をするがリソースの内容が更新されているか判断をする。リソースのinode番号と更新日時とサイズからタグを生成(Apacheの例ではFileETag INode MTime Sizeを仕様した場合)し、レスポンスヘッダーのETagに設定する。
例)ETag: "30-448b28913d700"
次に同じリソースに対してリクエストを送信するときにリクエストヘッダーにIf-None-Match:"30-448b28913d700"を設定し、サーバー側はリソースの現在のETagの値と比較し、同じであればリソースは変わってないので304ステータスを返す。一致しない場合は対応するキャッシュがブラウザ側にないので通常のレスポンスを返す。

キャッシュの陳腐化(stale)が発生した場合の図

陳腐化したリソースへのリクエストをキャッシュが受け取るとIf-None-Matchを付加してリクエストを転送する。
https://developer.mozilla.org/ja/docs/Web/HTTP/Caching

キャッシュさせたくない場合

no-storeを指定すること

ブラウザのキャッシュサイズについて

  • 永続的
    • 長期間に渡って保存されるため、保存する場合はユーザーに警告ポップアップが表示される。ユーザーがデータを削除する。
  • 一時的

    • 長期間に渡って保存する必要がないデータ。ストレージの容量制限に達するとLRUポリシーに沿って削除される。
  • Chrome

    • キャッシュサイズ
      • Chrome allows the browser to use up to 80% of total disk space. An origin can use up to 60% of the total disk space.

      • https://web.dev/storage-for-the-web/#how-much
      • -disk-cache-size
        • 画像やCSSなどのキャッシュサイズ
      • -media-cache-seize
        • HTML5の動画や音楽のキャッシュサイズ
    • データ削除ポリシー
  • Firefox
  • Safari
    • キャッシュサイズ
    • データ削除ポリシー
      • Safari previously did not evict data, but recently implemented a new seven-day cap on all writable storage (see below).

      • Starting in iOS and iPadOS 13.4 and Safari 13.1 on macOS, there is a seven-day cap on all script writable storage, including IndexedDB, service worker registration, and the Cache API. This means Safari will evict all content from the cache after seven days of Safari use if the user does not interact with the site. This eviction policy does not apply to installed PWAs that have been added to the home screen. See Full Third-Party Cookie Blocking and More on the WebKit blog for complete details

      • 書込み可能なすべてのストレージに7日間の上限が設定された模様

参考書籍

See you next time:)