コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

RailsのIpSpoofAttackErrorとは何なのかをざっくり整理する

そもそもどういう事象なのかも含めて整理する。

前提としてIp Spoofing(IPスプーフィング)とは何か

送るリクエストの送信元IPを偽装してアクセスをする手法。IP制限などで特定のIPのリクエストしか受け付けない環境に対して、自身のIPを偽装をすることで制限を突破することなどを目的に行われる。

通常TCP/IPの方式ではTCPが送信元のIPを改ざんするのは難しい作りになっているため、TCPを用いる場合での送信元IPの偽装は難しいとされている。

RailsのIpSpoofAttackErrorとは

IpSpoofAttackErrorが発生するところのv7.2.0のソースコード を見ると、リクエスト元となるクライアントIPを推測する処理のところでraiseされる。

この処理ではIPアドレスをHTTPのヘッダ情報から類推して特定する処理となっている。その際に利用するのが REMOTE_ADDR , CLIENT-IP , X-FORWARDED-FOR ヘッダのいずれかを利用する。その際にあまり併用されることがない CLIENT-IPX-FORWARDED-FOR に関して送信元IPを含むべきX-FORWARDED-FORCLIENT-IPで書かれているIPが入っていない場合に異常として検知するもの。(X-FORWARDED-FOR に関しては過去の記事に書いたので説明は端折ります)該当コードとしては以下のあたりです。

should_check_ip = @check_ip && client_ips.last && forwarded_ips.last
if should_check_ip && !forwarded_ips.include?(client_ips.last)
  # We don't know which came from the proxy, and which from the user
  raise IpSpoofAttackError, "IP spoofing attack?! " \
    "HTTP_CLIENT_IP=#{@req.client_ip.inspect} " \
    "HTTP_X_FORWARDED_FOR=#{@req.x_forwarded_for.inspect}"
end

そのため、原義のIp SpoofingよりもHTTPヘッダでの整合性の合わない話へのエラーとなっている。

無効にするには

このraiseが上がらないように設定をすることもできる。Railsガイド曰く以下の通り。

この設定はconfig.action_dispatch.ip_spoofing_checkオプションとconfig.action_dispatch.trusted_proxiesオプションで変更可能です。 - Rails アプリケーションの設定項目 - Railsガイド

そのためしかるべきところで

config.action_dispatch.ip_spoofing_check = false

としておけばこのチェック自体がスキップされる。

余談:CLIENT-IP ヘッダについて

この調査の際に、CLIENT-IP ヘッダの仕様について調べようとしたところ2024年時点だと全然情報が見つけられずでした。仮に使うとしても X-Real-IP などで同様のことをやるのが一般的という情報しか出てこなかったので、今だとセットするほうが珍しい可能性があります。それ故にもしエラーが上がった場合は経路的にどこでセットされているのかを確かめるようほうが良いかもしれません。

参考・関連リンク

SEOを考えるときに実例を見ながら基本を見返したいときに読みたい『医療情報ネット「ナビイ」のSEO課題と改善策』

未来の自分が見返したくなる可能性があるのでスクラップ的な意味で書き残す。

対象ページ

医療情報ネット「ナビイ」のSEO課題と改善策 | SEO研究チャンネル

みどころ

以下のツイートにだいたいが語られている

内容としては国が運営するナビイを題材に、SEO的に気に掛けるべきところがまとめられている。例えばクローラーが回遊しやすいようにaタグを配置するなどというところに関してはSEOに携わったことがない方だとピンと来ない部分の可能性があるので、そのあたりが実例込みで知れるよい記事となっています。

Googleが用意しているGoogle 検索の基本事項(旧ウェブマスター向けガイドライン)を読んだあとに実例として目を通すと良さそうな記事でした。

関連リンク

iOS17.4.1時点では、QRコードを読み取るアプリ「コードスキャナー」でURLを読み込むとWebViewで起動する。

タイトルどおりの話なのだが、なんの問題がおきるのかを整理する

対象となるOSバージョン

iOS 17.4.1

どういうことか

iOSにはQRコードを読み取るアプリが標準で2種類ある。一つはカメラ、一つはコードスキャナーである。

この2つのアプリでURLを指し示すQRコードを読み取ったときの挙動が異なる。

読み取るアプリ URLを読み込んだときの挙動
カメラ Safariでリンクを開く
コードスキャナー コードスキャナー内でWebViewが開く

この挙動のため、コードスキャナーでページを開くとSafariでのログインセッションなどは引き継がれないため、Safariでログインをしていても改めてログインを要求される。

下記の例ではSafariでログイン済みの状態だったときに、カメラで読み込むとつつがなくSafariが立ち上がりログイン済みだが、コードスキャナーの場合はWebViewがたちあがるのでログイン状態ではない事例

何がおきるのか

WebViewというものを認識していない利用ユーザーからすると「Safariでログインした直後にも関わらず再ログインを要求される」「QRコードからログイン限定領域を見ようとすると毎度ログインを要求される」などの事態がおきる。

気をつけるべきこと

要ログイン領域のページに遷移するQRコードを準備する場合にはこのような事態になることを勘案してオペレーションを設計する。また可能な限りコードスキャナーではなくカメラでのQRコードの読み取りを推奨すると懸念は減らせそう。

関連リンク

2024年7月時点のRFCの仕様を鑑みると、URLの文字数は8000文字まで対応されている

過去に書いた記事へのupdateの意味も込めて

出典

RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

どのようなことが定義されているのか

RFC7230では以下のようなことが記載されている。

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.(リクエストラインの長さに関するさまざまなアドホック制限が実際に見られます。すべてのHTTP送信者と受信者が、少なくとも8000オクテットのリクエストライン長をサポートすることが推奨されます。) - RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing 日本語訳

リクエストライン(リクエスト行)には8000文字程度扱えることが推奨されるということになっている。このリクエストラインとは何かというと、HTTPリクエストを送るときの一行目にあたる情報。

例としてcurlを使って https://example.com/index.html/ にアクセスするリクエストを送る場合は以下の内容がリクエストのテキストになる。

GET /index.html HTTP/2
Host: example.com
user-agent: curl/7.84.0
accept: */*

上記の GET /index.html HTTP/2 がリクエストラインにあたる。

このリクエストラインが8000文字程度のサポートを推奨しているので、ホスト部を覗く文字列の長さもその分だけ表現可能ため、8000文字前後はURLの文字列の長さとして許容できる、という見解になる。

関連リンク

『大吉祥寺.pm』に行ってきたよメモ

大吉祥寺.pm - connpass』に参加してきたのでそのメモです、

各発表の感想

ざっと見たものだけピックアップで… ※資料スライドは見つけたら貼ります。


大吉祥寺.pm 基調講演

感想

  • 出てくるフレーズが一つ一つ面白いご自身の歴史の発表
  • 前夜に行われた生存者バイアスナイトを地で言っている内容だった
  • 人に歴史あり、というのを感じる発表だった

関連リンク


多様性の時代を生き抜くキャリアプラニング

感想

  • キャリアプランニングの考え方の話
  • 日本では総合職に対してジョブローテーションをさせる考え方があるが、その根底は個々人の長所の発掘なのかもしれないなと改めて聞いて思うなど
  • ときにはインフラ、ときにはフロントエンドみたいにできると自分の長所を見出しやすいのかもしれない

関連リンク


開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ

感想

  • カスタマーサクセスからWebエンジニアに変わって景色の見え方が変わった、という内容の話。
  • お互いのコミュニケーションの話で、何を大事にするといいかということを改めて感じる。
  • 異なるコミュニティ文化圏の人たちにうまく伝えることって大事
  • 個人的に強烈に違和感を感じる部分があったので、それに関してはどこかで書き留めたいなと思っている。 書いた。

関連リンク


君たちはどうコードレビューする(される)か

感想

  • コードレビューをどうするかという話
  • 個人的にこの手の話を見るたびに、目指すべきは「チームの共通見解の構築」が第一の目的になるんだろうなとは感じている。
    • どこまで行っても品質の「担保」にはならないので、その部分は品質を守るためにあるいくつかの防御壁の一つぐらいの感覚
  • 最近このコードレビューに至る前にADRなどで仕様の議論をして相互理解を図るのもテクニックの一つなのかなと思いつつある

関連リンク


組織のスケーリングと持続性

感想

  • エンジニアに求められることと、その先の事業貢献する話。
  • スケーリングしたのに売上が増えないと、逆回転して退職につながるというのはなるほどなと思う話だった。
  • 半自動的にプロダクトの未来や事業の未来を自分ごとに落とす仕組みがOKRなのではないかなと思い、この話と連動させると理にかなっている仕組みなのではないのか?とか思ったりなどした。

関連リンク


Linux コンテナの歴史を追うとコンテナの仕組みがわかる

感想

  • Linuxとコンテナの歴史の話。
  • 登壇自体は途中から聞き始めたので、資料ベースで読み返しをしたのですがコンテナ技術がLinuxの技術と地続きなっているのがスッと入る話でした
  • 「コンテナは仮想じゃないよ隔離だよ」というのは意識しておきたいなと思う一句でした。

関連リンク


デザインのこれまでとこれから

スライドはなさそう

感想

  • ここ10年のデザイン周りの話の振り返り
  • そういや色々使ってましたねというのと一斉を風靡したinVisionがサービス終了したのが驚き
  • みんな意外とAdobeFigmaの話を知らなそうな反応だった

関連リンク


僕のキャリアとワインと鍋

感想

  • 飲食店であるワインと鍋にまつわるいろいろな話とエンジニアリングの話
  • ゴーストレストランをやって手応えを掴むというところからしプロダクトマネジメント力高いのでは…?など思った
  • 現在のWeb開発のプラクティスってどこにでも転用可能なんだなと思ったし、そういう話もいろいろなところで聞くなと思いました。

関連リンク


ドメインモデリングの現在地点

感想

  • ドメインモデルというがこれは何を解決したいのかなどを掘り下げていった話
  • 複雑さに関して、本質的なものと偶有的なもの、ローカルなもの、グローバルなものと切り分けて行って考えを整理していく過程はただただ聞いてて面白かった。
  • また、最終的にビジネスロジックとバリデーションの話に着地したのも知見が多く、スライドを自分なりに噛み砕いて解釈したい

関連リンク


集中して作業する技術

感想

  • 健康と集中に関するエビデンスが詰まったスライド
  • 健康のためには睡眠と運動が大事…という話題以外にもちゃんと即実践できるものがあってよかった
  • 個人的にポモドーロ計測をやっていた身なので、7ポモが出せるのはすごいという印象
  • デスク環境を整える話はkawasimaさんの話に通ずるものがあった

関連リンク


ノート PC に Linux 入れてみたけど結構良かった

感想

  • elementary OSを入れた話
  • かなりMacライクに使えそうなので、軽くてMacっぽくトラックパッド使いたい!って人にはよさそう
  • ただ登壇のときにはワタワタしそうという事例を目の当たりにしました

関連リンク


コミュニケーションをパスと捉えている話

感想

  • サッカーのパスになぞらえたコミュニケーションの話
  • 一休さんの橋の端のような)パスのパスの話みたいにもなったがうなづけるところは多かった
  • 相手の状況を把握するというのと、前段の発表の「勝手に諦めない」という話に通ずるものがあるなと聞いていた。

関連リンク


エンジニアリングじゃないエンジニアのお仕事

スライドは見つけたら貼ります、forteeはこちら

感想

  • エンジニアから技術広報や教育のほうにまわった事に関する話
  • スカウト送ったり送られたりは大変だよね…とは思いながら聞いてました。
  • 時間切れで教育の話は聞けなかったのでスライドが公開されたらちょっと見てみたいなと思いました。

関連リンク


あらゆる重大な選択の際に使えるアーキテクチャ思考

スライドは見つけたら貼ります、forteeはこちら

感想

  • 物事を考えるときは感情だけでなく論理と一緒に洗い出して評価していくと良いよねという話
  • 「全部の非機能要件を拾うのは無理」というのはたしかにそう
  • 現状のコンテキストに合わせて相対する軸を出してあげる考え方は大事。

関連リンク


ぼっちを避けて楽しむためのアノテコノテ

感想

  • コロナ禍によって失われたオフライン勉強会知見をコンパクトにまとめてくれたスライド
  • アイコンしかわからない、とかはかなり多いはずなのでわかるものがあると便利なのはそれはそう
  • ちなみにこのブログはfaviconをアイコンにしたことにより、「なんかみたことある…」が増えた気がします(定性評価)

関連リンク


大人の社会科見学 ~ NTT 技術史料館に行ってみよう!

感想

  • NTT技術資料館の行ってみたレポ&推せるときに推せトーク
  • 子どもの頃は知らないことを知るみたいな側面で好きだったんですが、ある程度大人になるとベースの知識との差分埋めみたいなのができて楽しいよなと思います。
  • ガイドさんもいるみたいなので行ってみたくなりました

関連リンク


僕はまだ見ぬ誰かを動かすために登壇をする。

感想

  • 幸福と登壇について、哲学的なアプローチから入る話
  • いわゆる「何者」かになれば幸福を捕まえることができるんじゃないかというところから、そうではなかったんだという話に入るところがとてもキレイに語られていました。
  • 勇気とは何かというのも深い問いだなと思いました。

関連リンク


全体を通しての感想

  • 10年の振り返りもあり、技術的な話もあり、若い層の経験談もあり、抽象的な設計の話もあり、バラエティに富んだ会だなと改めて思いました。
  • 最後に「続けていくことが大事」という話をされていましたが、つくづく自分自身もこのブログを続けていてそう思いました。
    • 自分自身も様々な場所の勉強会で刺激をもらいつつ、自分の記録と周りへの議事録共有のぐらいの気持ちでブログにしたためていますが、たまに誰かの役になったお声はいただくので細々とやりたいなと思っています。
  • 登壇したいなという気概が一段と高まったので、とりあえずYAPC函館とKaigi on Railsかな…とか思っています。
  • もっと本当は The One Person Framework で雑にシュッとつくることもやりたいのでそこもやりたいぞという気持ちに

関連リンク

『アナタはなぜ チェックリストを使わないのか?』を読み終わったよメモ

読んだ本

読むきっかけ

明確にどなたかのツイートかは覚えてないのですが、Twitterなどでオススメされていたのを見たのがきっかけ

本について

この書籍の著者であるアトゥール・ガワンデ氏は外科医かつ公衆衛生学者である。このガワンデ氏は2008年頃に「Safe surgery saves lives checklist」(安全な手術は命を救うチェックリスト)を作り上げたのだが、このチェックリストができあがるまでのエピソードと「チェックリスト」という考え方が汎用的に使えることをまとめた本となっている。

ミスが許されない医療の現場でいかに成功率を上げるかということにおいて、チェックリストが有用であることを様々な角度で語られている。

また、書籍の最後には「チェックリスト作成ためのチェックリスト」があり、普段の生活のチェックリストを作る際にも役立つものとなっている。

読後の感想

チェックリストの本質を見つめ直させる

この書籍ではガワンデ氏が建築業界、航空業界で使われているチェックリストの考え方を取り入れて医療業界に取り入れていくエピソードも紹介されている。その過程を通して「チェックリストが持つ本来の力を発揮するものはどのようなものであるべきなのか」ということもわかる内容となっている。

本質がどのようなもであるか?というのは書籍の最後にある「チェックリスト作成のためのチェックリスト」を見ていただければと思うのだが、この中のチェックリストを開発する際のチェック項目に以下のようなものがある

「各項目は見逃される可能性が高く、必須である」 - アナタはなぜ チェックリストを使わないのか? チェックリスト作成のためのチェックリスト より抜粋

個人的にはこの部分が非常に重要だと感じた。こちらに関しては書籍内で書かれている航空機のチェックリストの事例の話を見ると非常にわかりやすいので、抜粋して紹介する。

単発のセスナ機での飛行中に、エンジンが停止したときのためのチェックリストだ。(中略)このチェックリストには、エンジン再始動の方法が六つの手順に凝縮されている。燃料バルブを開く、予備燃料ポンプのスイッチをいれる、などだ。だが、一つ目の手順が最も興味深い。そこには「飛行機を飛ばせ」とだけ書いてあるのだ。パイロットは、エンジンの再始動や原因の分析に一所懸命になり、最も基本的なことを忘れてしまうことがある。「飛行機を飛ばせ」硬直した思考を溶きほぐし、生存の確率を少しでも上げるためにそう書いてあるのだ。 - アナタはなぜ チェックリストを使わないのか? 第八章 P203-204より抜粋

事故が発生して頭が真っ白になったら普段できていたこともできなくなる、というエピソードはどこでも聞く話ではあるが、それを加味して事故時の対応のチェックリストに盛り込まれている。

チェックリストはマニュアルでも教科書でもない

普段チェックリストを作っているとただの「手順書」となってしまう場合がある、言い換えればマニュアルになってしまう。このことに関して書籍内で「チェックリストはマニュアルでも教科書でもない」と書かれている。

航空機のチェックリストの事例のとおり、良いチェックリストは要点が凝縮されており、それ自体がなにかの手順を説明するものにはなっていない。そうしてしまうと利用者が使いにくくなってしまうし、純粋に手術や航空機の操縦などで細かく書かれた手順をこなすというのは、紙に対してペンでチェックをいれるようなことができないので難しい。

また、マニュアルではないという側面が強く感じられるのは各項目が簡潔に書くべきというところで、マニュアルや教科書は「何もわかっていない」人向けに書かれるものだが、チェックリストは「ちゃんとわかっている人がヌケモレせずやる」というためのものになっている。そのためこの書籍では「プロフェッショナルこそチェックリストを有効活用すべきである」という旨のことがかかれている。こあたりもマニュアルとは異なるというところを表しているなと感じた。

予想外のミスはコミュニケーションで軽減させる。

不確実性が高い事象を取り扱うことが多ければ多いほど、トラブルやミスが起きやすい。それらをカバーするために「チェックリスト作成のためのチェックリスト」には下記のような項目がある。

「チームメンバーのコミュニケーションを向上をさせるような項目を加えること」 - アナタはなぜ チェックリストを使わないのか? チェックリスト作成のためのチェックリスト より抜粋

これは、コミュニケーション不全が多い場所ではミスが起きやすいという話から記載がされている。

著書の中の例だと手術の話がある。手術の実施前に自己紹介や取り組むことに関しての話がされていない状態で挑んだ場合、なにか予想外のトラブルが起きたときに誰にどう頼むべきかもわからず混乱する。ただ少しばかりの自己紹介と簡単な作業の概要に関して手術の前に言葉を交えるだけでトラブルが起きたときに対処しやすい。また事前に喋るタイミングがあれば、不安に思っていることや心配事もお互いに告げやすい。

また、建設現場のエピソードでは以下のように書かれている。

建設を任された専門家たちは個人の能力を過信せず、二種類のチェックリストを使う。単純な手順の間違いを防ぐチェックリストと、話し合いをさせることで予想外の困難も確実にすべて解決させるためのチェックリストだ。 - アナタはなぜ チェックリストを使わないのか? 第三章 P82より抜粋

チェックリストの力を最大限につかう

この書籍を読むと、チェックリストは平時の事前確認や有事のトラブル対応など様々な場面で使うことができることがわかる。また無意味なチェックリストに関して意味のあるものへの変え方も見えてくるので、普段チェックリストに辟易してしまっている人ほど、一読する価値があるような本なのではないかなと思いました。

関連リンク

非機能要件の検討に困ったときに参考にすると良い資料『非機能要求グレード2018』

観点として何をおさえておくといいんだっけ?というときに役に立つのでメモ

対象ページ

システム構築の上流工程強化(非機能要求グレード)紹介ページ | アーカイブ | IPA 独立行政法人 情報処理推進機構

みどころ

「非機能要件って何を見ればいいんだっけ?」と思ったときに自分自身に馴染のある部分に関してはすぐ検討できるが、馴染のない部分は忘れがちになる。そういうときに「一般的にはどういう要素があるんだ?」ということをざっと紹介してくれている。また自分自身が扱うシステムがどの程度のレベルまで担保すればいいのだろうというときに具体的な指標も示してくれる。

メインの資料自体はExcel形式になっており、項目ごとに気にするべき観点とそれに対する対応度合いがレベルで表現されている。例えばシステムが稼働素べき時間を5段階で表しており、レベル3は「1日のうち1時間の停止は許容する」レベル5は「24時間無停止」というような形で項目ごとに守るべき段階を例示してくれている。また、モデルケース別にどのレベルまで担保すべきか?という例示もセットで用意されている。

とりあつかうもの次第で気にするべき非機能要件の要素は変わるが、そこに関しても上からなぞっていくと頭に浮かべておいたほうがいいポイントが見ることができるので、普段非機能要件を整理しない人にはもちろん、普段からやってきていた人もヌケモレチェック用途として利活用できそうな資料でした。

関連リンク