Posts

URL 埋め込みのセッション ID 概要 セッションが URI に埋め込まれることがある。 PHP,Java,ASP.NET などはサポートしている。 http://example.jp/mail/123?SESSIONID=XXXXXXX 課題点： Referer ヘッダを経由して、セッション ID が外部に漏洩する（Referer ヘッダとは） Referer ヘッダーにより、サーバーは人々がどこから訪問しに来たかを識別し、分析、ログ、キャッシュの最適化などに利用することができます。 対策： URL 埋め込みセッションそのものを禁止する 攻撃手法と影響 攻撃の流れ： スタートページ（別ページに遷移） 外部リンクが貼られたページ（パラメータに SESSIONID が付与されている） 外部のページ（referer ヘッダから SESSIONID を取得） 1.URL 埋め込みセッションを使えるするように設定ファイルを変更 2.外部サイトへのリンクがある or リンクを攻撃者が作成できる（メール、掲示板、ブログ、SNS でやられる） 影響： セッションハイジャックを同じ 脆弱性が生まれる原因 2000 年前後の「クッキー有害論」が生じたため -> アクセス履歴を追跡できるのってプライバシーの観点からどうよ？って問題に ドコモのガラケーのブラウザは過去にクッキー対応していなくその影響 —>今はクッキーに保存するほうが安全とされている？ 対策 セッション ID をクッキーにのみ保存してねとすれば OK セッション ID の固定化 概要 セッションハイジャックを起こす攻撃の中に、セッション ID を外部から強制するセッション ID の**固定化攻撃（Session Fixiation Attack）**がある。 攻撃の流れ： セッション ID を入手 ターゲットに奪ったセッション ID でのアクセスを強制 ターゲットが標的のアプリにログイン...

今回作るシンプルなインフラ設計 AWS でインフラ構築をする時は、毎回ブラウザからコンソールをぽちぽちするとセキュリティーグループやルートテーブルの設定に抜け漏れができてしまったりということが多く困っていました。 そのため、今回はコードを書いて実行するだけでインフラ環境を構築してくれるツール「Terraform」を使って構築の自動化をしていきます。 まず、完成図から見ていきましょう。 このように VPC に EC2 が乗っているだけのもっともシンプルな設計で作っていきます。 Terraform とは そもそも「Terraform」とは何かについて簡単に説明します。 Vagrant を開発しているHashiCorp 社が開発しているツールで公式 HP によると、 HashiCorp Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. https://www.terraform.io/ つまり、Terraform とは安全かつ予測可能にインフラ設計を作成／変更／改善がコードとして扱うことができるオープンソースツールです。 これを使うことでコードからインフラ環境を構築でき、削除をコマンドひとつで簡単にできます。 ブラウザ構築を行う際にはコンソールからぽちぽち設定を行わなければいけないとの、立ち上げた環境を潰したい時もいちいちひとつずつ削除しなければいけないというデメリットがありますが Terraform を使うことでこれらの課題を解決してくれます。 一度設計したインフラ構造を使いまわすこともできるので、使いこなすことができるととても便利なツールです。 インフラ構築の手順 それでは、順を追って Terraform によるインフラ構築を行なっていきましょう。...

HTTP の基礎 HTTP ってなに？http://…..com とかいう感じで URL の前の方についている印象しかないですよね。 ここで Wikipedia で HTTP で検索してみると、 Hypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル、略称 HTTP）とは、HTML などのコンテンツの送受信に用いられる通信プロトコルである。主として World Wide Web において、Web ブラウザと Web サーバとの間での転送に用いられる。日本標準仕様書ではハイパテキスト転送プロトコルとも呼ばれる。 HTTP/1.1 が RFC 7230 から RFC 7235 で規定されている。かつては RFC 2616 が HTTP/1.1 を規定していたため、こちらもよく参照されている。また、HTTP/2 が RFC 7540 で規定されている。 https://ja.wikipedia.org/wiki/Hypertext_Transfer_Protocol って感じて正直専門用語が多くて正直よくわからない。。。 HTTP とは HTTP（Hypertext Transfer Protocol）とは、ハイパーテキストというリソースを転送（トランスファー）するための方法（プロトコル）です。 これでも、あまりよくわかりませんよね。 もっと噛み砕いて言うと、HTTP とは「Web サーバとクライアントがデータをやり取りする通信手段」のことを意味しています。 例えると、JOJOHACK(=Web サーバ)を読者(=クライアント)が見るためのパソコン間のデータのやりとりをするための通信方法です。 http://….com の「http」という方法でデータを転送しますよーということを表していたのです。 他にも FTP などといった通信方法もありますが、Web における通信方法は現在ではこの HTTP が主流となっています。 転送できるデータ 一昔前はハイパーテキストと言われるテキストデータしか通信することができませんでした。 しかし、現在ではこの HTTP を使って送ることができるデータは、 ハイパーテキスト 静止画 音声 動画　etc....