Understanding DNS with ActionDispatch::HostAuthorization2020 年 10 月 3 日開催の、Kaigi on Rails で発表した内容です。（発表時間 20 分） ## 2020/10/12 追記 このスライドの説明だけですと攻撃の特性がわかりづらかったので、個人ブログの以下の記事にて追加の説明を行いました。 https://yucao24hours.me/blog/2020/10/12/dns-rebindig-basics-revised/
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
Rubyで安全な文字列リテラルかどうかを判別したい - かみぽわーる
Rails 5.2からRails SQL Injection ExamplesにあるようなSQLインジェクションを防ぐ仕組みが導入されて、Post.order(params[:order])みたいなコードは心温まる正規表現によるチェックをパスしないと危険とみなされるようになって、お前が安全やと思うんやったらPost.order(Arel.sql(params[:order]))しろってことになった(rails/rails#27947)。 これはRails 5.0のときにparamsがHashのサブクラスじゃなくなったときに比べればマシだけど、明らか安全やと思ってるリテラルもRailsに危険とみなされて既存のアプリケーションによったら非常にわずらわしい。たとえばDiscourseというRailsアプリは5.2に上げるときにこれの影響をモロに受けるんやけどっていうお気持ちを表明しています(ra
RailsのPOSTでCSRF TokenがVerifyできないときに確認したいこと - Qiita
前提条件 nginxがSSL Terminationをするリバースプロキシである Railsのバージョンが5の状態でrails newをしている 発生する問題 formのPOST時にCan't verify CSRF token authenticity.というエラーが発生する 確認するところ CSRF Tokenがページ内に埋まっているか？ nginxにおけるリパースプロキシの設定は間違っていないか？ CSRF Tokenがページ内に埋まっているか？ Railsで入力フォームを作成するときは、おそらくform_forかform_tagを使うことになると思います。その場合、普通はauthenticity_tokenというhidden fieldが追加されています。 たとえばこれはQiitaの意見を送信するフォームにauthenticity_tokenが埋め込まれている様子です。 またAja
パスワードはハッシュ化して保存していても簡単に見えちゃう問題と対策用Gemのblinkersについて
freeeのkakkunpakkun(略してkp)といいます。マイクロサービスおじさんです。 freeeではモバイルバーサーカーとかフロントエンド革命家など、独自の名前が多いですが、私は「分割おじさん」「認証おじさん」「rspecおじさん」などと呼ばれたりしてきました。 バーサーカーや革命家と比べてかっこ良くないのがなんだか気になる今日このごろです。 今日はおじさんらしく細かくて面倒な話をして、その対策としてfreeeで使ってるgemを公開したのでその説明をしようと思います。 パスワードはDBでハッシュ化していても簡単に見えてしまう 「パスワードが見えてしまう」というのはすごい不安になる言葉ですが、あまり考えずにサービスを開発していると簡単に起こる事象です。 ではどこでそういうことが起こりやすいのでしょうか。 DBにハッシュ化したパスワードを保存するのはかなり一般的になり、各種ライブラリも
Rails SQL Injection Examplesの紹介
モノタロウの1900万商品を検索する Elasticsearch構築運用事例（2022-10-26 第50回Elasticsearch 勉強会発表資料）
Rails 3.2.18, 4.0.5 and 4.1.1 have been released!
Hi everyone! Rails 3.2.18, 4.0.5 and 4.1.1 have been released! These three releases contain important security fix, so please upgrade as soon as possible! In order to make upgrading as smooth as possible, we’ve only included commits directly related to each security issue. The security fixes is: CVE-2014-0130 The commits for 3.2.18 can be found here, the commits for 4.0.5 can be found here, and th
Rack::Session::Abstract::IDのsecureオプションをリクエストごとに変えられるようにしてみた
a2ikm/rack-dynamic_session_secure RailsのセッションストアではRack::Session::Abstract::IDに渡される:secureオプションの値によってCookieのsecure属性を付けたり外したりできるんだけど、基本的にベタの値*1しか受け付けていない。 これをリクエストによって切り替えられると嬉しい場面が出てきたので、Procを渡して動的に評価されるよう書いてみた。Railsだとこんな感じ: # Gemfile gem 'rack-dynamic_session_secure', github: 'a2ikm/rack-dynamic_session_secure' # config/initializers/session_store.rb secure = ->(env) { !!(Rack::Request.new(env).pa
Rails 本体で特定のパスに IP アドレス制限をかける方法 - present
RailsAdmin で Web サービスの管理ページを実装しているんだけど、公開するにあたって、管理ページに誰でもアクセスできるのはマズイ。そこでまず考えるのは、管理ページに IP アドレスの制限をかけること。 ただ、今回は Heroku を使っているので、Apache や Nginx で制限する方法は使えない。Heroku では Rail 本体でやるしかない。ならば Rack ミドルウェアで制限してやればいいと思い、Rack::Access を使うことにした。 Rack::Access は rack-contrib に含まれているので、まず Gemfile に gem "rack-contrib", require: "rack/contrib" を記述して bundle でインストール。 あとは、config/application.rb で Rack::Access を使うように指
Ruby on Railsのfind_by_*メソッドにSQLインジェクション脆弱性(CVE-2012-5664) | 徳丸浩の日記
Ruby on Rails(3.2.9, 3.1.8, 3.0.17以前)のfind_by_*メソッドにSQLインジェクション脆弱性が見つかりました(CVE-2012-5664)。このエントリではその概要と対策について説明します。 概要 Ruby on Railsのfind_by_*メソッドの引数としてハッシュを指定することで、任意のSELECT文を実行できる脆弱性があります。 検証 Ruby on Rails3.2.9の環境を用意して、以下の2つのモデルを用意しました。 $ rails g scaffold user name:string email:string $ rails g scaffold book author:string title:string モデルUserは個人情報を保持しており、自分自身の情報のみが閲覧できるという想定です。モデルBookは書誌データベースであ
Rails4.0に含まれる strong_parameters について - おもしろwebサービス開発日記
注意 このエントリは急いで書いたので間違いが含まれている可能性が高いです。気づいた方はご指摘ください。 序文 strong_parameters とは、mass assignment で余計なパラメータをモデルの属性にセットさせないための新しい仕組みです。Rails 4.0 からはこれが標準になります。Rails2.x と 3.x はattr_accessibleやattr_protectedなどで似たような機能が提供されていましたが、これだと管理が煩雑になるケースがありました。 今年の３月くらいにGitHub が mass assignment の脆弱性を突かれたことで 、この問題をどうにかしようという流れが起き、最終的に strong_parameters が作られるという経緯を辿りました。 mass assignment とは Rails ではこんなコードをよく見ると思います。 de
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
github の mass assignment 脆弱性が突かれた件
Github に脆弱性。やった人は Rails に有りがちな脆弱性を issue に挙げていたが相手にされず、実際にそれを突いてきた。一見 childish だが、それだけ簡単に脆弱な実装がなされてしまうということだ。週明けの今日、Rubyist はまず関連情報に一読を。 — Yuki Nishijima (@yuki24) March 4, 2012 気になって調べたのでメモ。自分も気をつけないとなー。 Public Key Security Vulnerability and Mitigation - github.com/blog/ github に脆弱性があってそれが突かれたらしい。 Rails アプリにありがちな脆弱性の一つ、Mass assignment とかいうタイプの脆弱性である。 mass assignment 脆弱性とは mass assignment 脆弱性とは何か、
Rails 3.0.4と2.3.11からXHRリクエストの際もCSRFトークンの検証が必須になったので注意 - YomuKaku Memo
Rails 3.0.4と2.3.11がリリースされました。重要なセキュリティ対策のリリースのようです。 最も大きな変更点はCSRF対策強化で、この結果として、AJAXのために従来使用していたJavaScriptのコードでは、get以外のメソッドの部分が動作しなくなるため、当該箇所の修正が必要になります。 RailsではCSRFの防止にトークンが用いられています。Rails 3.0.3以前はAjaxのXHRリクエストではCSRFが起こりえないという前提でトークンの検証を行わないようになっていましたが、FlashやJava appletを利用した場合にcsrfが起こる可能性があるとのことで、Rails 3.0.4（およびRails 2系のRails 2.3.11）ではXHRリクエストの場合もトークンの検証を行うように変更されたようです。 したがって、Rails 3.0.4（およびRails 2
Securing Rails Applications — Ruby on Rails Guides
This manual describes common security problems in web applications and how to avoid them with Rails. After reading this guide, you will know: All countermeasures that are highlighted. The concept of sessions in Rails, what to put in there and popular attack methods. How just visiting a site can be a security problem (with CSRF). What you have to pay attention to when working with files or providin
Railsでのhttp/https切り換えはには実行環境に依存する部分もある - yuumi3のお仕事日記
現在、開発しているWebアプリではプライバシーを扱う一部のページのみ httpsで実行し、それ以外の大部分のページは httpなので、httpからhttpsへの遷移や httpsからhttpへの遷移があります。 Ruby on Railsでは http から https へ遷移する リンクやは下のように <% link_to :action => 'login', :controller => 'members', :only_path => false, :protocol => 'https' %> また、https から http へ遷移は <% link_to :action => 'logout', :controller => 'members', :only_path => false, :protocol => 'http' %> と書きます。form_for でも同様です
Rails 2系すべてのブランチに脆弱性、Ruby 1.9ユーザはアップグレード注意 | エンタープライズ | マイコミジャーナル
Ruby on Rails 4日(米国時間)、Ruby on Railsの2系すべてのバージョンにXSSの脆弱性があることがRiding Rails: XSS Vulnerability in Ruby on Railsにおいて発表された。特定のUnicode文字列を使ってチェックをくぐり抜け、任意のHTMLを送り込まれる危険性がある。なおRuby 1.9系で動作しているアプリケーションはこの影響を受けない。それぞれのバージョンに対するパッチは次のとおり。 2-0-CVE-2009-3009.patch - Patch for 2.0 series 2-1-CVE-2009-3009.patch - Patch for 2.1 series 2-2-CVE-2009-3009.patch - Patch for 2.2 series 2-3-CVE-2009-3009.patch - Pa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsエンジニアのためのウェブセキュリティ入門
Login Form from Scratch.
Blog
