こんにちは。技術部の国分 (@k0kubun) です。 3/28にクラウドワークスさんで行なわれたRails Upgrade Casual Talksで、Railsアップグレードの際にクックパッドが行なっている工夫について紹介しました。 影響範囲の予測が難しいRailsのアップグレードを安全に行なうための動作確認のやり方について参考になればということで、本記事でも改めて紹介いたします。 CookpadのRailsアップグレードの流れ Rails 4.1から4.2にアップグレードした際の例を紹介します。 CIにRails 4.2用ジョブを用意 まずはRails 4.2にアップグレードするためのrails42ブランチでテストを通します。リリースするまでこのブランチはmasterからrebaseし続けるので、リリースまでテストを通る状態を保つため、CIにrails42ブランチ用のジョブを用意しま
ぼくはまちちゃん！
はてなダイアリー (メインブログです！) → ぼくはまちちゃん！ (Hatena) はまちや２のツイッターです！ 気軽にフォローしてみてくださいね！ → Twitter / はまちや２ はてなブックマーク → Hamachiya2のブックマーク タンブラーです！ かわいい絵をあつめたりしています！ → [tumblr] hmcy ゲームの動画をあげて、ぼくもモテモテユーチューバーになるつもりです！ → はまちや２(Hamachiya2)のYouTube (以下は過去の記事など) きみのライフを可視化するよ！ → [JavaScript] ライフカウンター 空から女の子が…！ → 空から女の子が降ってくる AIRアプリの簡単な作り方 → [AIR][JavaScript] JavaScriptでかんたんAIRアプリに挑戦 つくってみました！ → ドリームメーカー : ブラウザで簡単にノベルゲ
書籍「気づけばプロ並みPHP」のサンプルスクリプトにリモートスクリプト実行の脆弱性があるので報告します。 はじめに Yahoo!知恵袋の質問を読んでいたら、以下の質問がありました。 気づけばプロ並みPHP （著）谷藤賢一 （発行）リックテレコムP１１２の画像をアップロードする機能でエラーがでます。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11119835496 より引用 質問に対しては回答が既についてクローズされていましたが、引用されているソースを見て任意のファイルを任意のファイル名で、Web公開ディレクトリにアップロードできることに気づきました（下記）。 <?php // 略 $pro_gazou=$_FILES['gazou']; // 略 if($pro_gazou['size']>0) { if ($pro_
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
12月10日にPC版がスタートしたサイバーエージェントのミニブログサービス「Amebaなう」で、あるURLをクリックすると、「こんにちは こんにちは!!」というフレーズとクリックしたURL文字列が自動で投稿され、「はまちや2」さんのアカウントを自動でフォローしてしまうという現象が広がった。 URLをクリックしたユーザーが意図しない機能を実行させられるWebアプリの脆弱性の一種・クロスサイトリクエストフォージェリ（CSRF）を突いたもの。同社は10日夜、URLをクリックしないようユーザーに告知。誤ってクリックした場合は投稿を削除し、はまちや2さんのフォローを外すよう呼び掛けた。11日朝までに脆弱性も修正したという。 mixiでも2005年、あるURLをクリックすると「ぼくはまちちゃん！」という日記が勝手に投稿されるという、CSRFを利用したスパムが流通したことがあった。コミュニティーサイト構
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP
JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった | mah365
JMeter使うのだるいなーと思ってたらruby-jmeterというRubyでテストプランを書けるツールがあった。知らなかった（迫真）。 典型的なRailsアプリのテストプラン そういう訳で典型的なRailsアプリのテストプランを書いてみたのがこちら。 ユーザーログインページでCSRFトークンを取得し、常にHTTPヘッダにつけるようにする ユーザーログイン情報をクッキーに保存 といった典型的な処理を盛り込んでいます。あとはREADME.mdを読んでもらえれば大体の書き方が把握できるかと思います。 ちなみに、# Debugというコメントの下2行をコメントアウトしてもらうと、JMeter上でデバッグ用の出力を表示することができます。テストプランが上手く動かないときに、リクエストヘッダやレスポンスを確認するのに便利です。 で、これをコマンドラインで ruby sample.jmx.rb && j
東京Node学園2017にて発表しました。
VALUE-DOMAIN に存在していた2種類のドメインハイジャック脆弱性について - debiruはてなメモ
2022年3月2日に確認した VALUE-DOMAIN でのサブドメインハイジャックが可能な脆弱性について経緯を説明します。 ついでに2016年の記事「VALUE-DOMAIN に存在していたアカウント乗っ取り可能な CSRF 脆弱性について」の続報も含めて、この記事で2022年現在の VALUE-DOMAIN の状況についてお伝えします。 脆弱性を2つ発見しました 第一：子ゾーン作成によるサブドメインハイジャック 第一の脆弱性の攻撃の原理 VALUE-DOMAIN のネームサーバについて 第一の脆弱性 発見後の経緯 サブドメインハイジャック攻撃を受けた場合の影響 第二：CSRF 攻撃によるドメインハイジャック ドメインハイジャック攻撃を受けた場合の影響 CSRF 攻撃によるドメインハイジャックの対策状況 VALUE-DOMAIN ユーザの方へ 脆弱性を2つ発見しました （第一）子ゾーン作
twitterに学ぶなりすまし投稿対策
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
teratailに以下のような投稿がありました。 PHPでメールフォームを作成したので、脆弱性がないかアドバイスいただけないでしょうか。 エンジニアでもなければ、PHPもろくに書けない雑魚ですが、「php メールフォーム 作り方」でググって表示されるサイトを見ると、「んんんんん？？？」と思うところがあります。 これらを参考にしたり、コピペする方は、記述されているコードの良し悪しは判断できないかと思います。 そのような方々が参考にできるメールフォームを作りたいという思いで、調べて作りました。 周りに書いたコードを確認してもらえる人もいないので、皆様からのアドバイスがほしいです((_ _ (´ω｀ )ﾍﾟｺ 【PHP】作成したメールフォームに脆弱性がないか、アドバイスもらえないでしょうかより引用 どれどれ…と確認すると、トークンのチェックが入っているにも関わらずクロスサイト・リクエストフォージ
Webアプリケーションのセキュリティの分野で「新しい攻撃手法」は実はそれほど多くないのですが、比較的新しく対応が求められているものとしてクリックジャッキングがあります。クリックジャッキングは、CSRFと同じように「Webアプリケーションのサーバー側機能」を利用者（被害者）に実行させる手法です。CSRFは、当該機能を実行するHTTPリクエストを送信させる罠を使いますが、クリックジャッキングの方は、iframe等に当該機能を呼び出す画面を表示しておき、利用者（被害者）に実行ボタンを押させる（=クリックジャック）手法です。クリックジャッキングに関しては従来詳しい解説がありませんでしたが、この3月26日にIPAから「クリックジャッキング」に関するレポートが公開されました。 このレポートから、クリックジャッキングのイメージを示す図4を引用します。 サイトAが攻撃対象のサイト、悪意のあるページは罠にな
こんにちはこんにちは！！ 招待された覚えがないのに、なぜかはてなブログを使えているHamachiya2です！こんにちは！ 新しいはてなブログではJavaScriptが自由に使わせてもらえるので、とりいそぎ新機能の活用ということで、開いただけで自動的にはてなスターがつく便利日記ができました。 ついたスターの確認はこちら → http://s.hatena.ne.jp/mobile/entry?uri=http://hamachiya2.hatenablog.jp/entry/2011/11/07/183544
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Speeeエンジニアの西岡（@nisshieeorg）です。 去る7/5(水)、Speeeでは社内の全エンジニア向けに、セキュリティ研修を実施しました。本研修では、株式会社リクルートテクノロジーズの西村宗晃様に講師としてお越しいただきました。この場を借りてお礼申し上げます。 研修の目的 Webを主戦場にして戦う私達エンジニアは、自分たちのサービスそのものや、ユーザー、顧客を守るために、より安全なWebアプリケーションを構築する知識・技術を求められます。もちろんSpeeeでも、このような知識を身につけることは必須とした上で、日々の開発ではソースコードレビューや各種脆弱性診断ツールを用いて、私達が構築するアプリケーションの安全性を高めるよう努めています。しかし一方これまでSpeeeでは、「セキュリティに関する体系的な知識の学習法が会社から提示されていないため、個人の学習に依存している」「小さな
CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
VALUE-DOMAIN に存在していたアカウント乗っ取り可能な CSRF 脆弱性について - debiruはてなメモ
2015年12月に私が発見した VALUE-DOMAIN での CSRF 脆弱性について、その脆弱性の報告と修正までの経緯を記しておきます。 きっかけ アカウント削除ページの作り アカウント削除ページの問題点 VALUE-DOMAIN への報告 CSRF 攻撃によるアカウント乗っ取りの問題 IPA への届出 余談：IPA への届出の仕方について IPA へ届出した後の状況 VALUE-DOMAIN ユーザの方へ きっかけ 数年前に VALUE-DOMAIN を利用していましたが最近は使っていないのでアカウントを削除しようとしたところ、アカウント削除操作を行うページの作りが「不自然である」ことに気付きました。更に調べたところ CSRF 攻撃によってアカウント乗っ取りが可能な状況であることが分かりました。 アカウント乗っ取りが可能な CSRF 脆弱性は2015年12月22日にIPAに報告し、2
個人だから甘いのかな - ぼくはまちちゃん！
あらあら予告inがXSSやられちゃったらしいですね！ 使い古された手法？ いまどきエスケープ処理すらしてなくてダサい？ 関連の記事に対して、はてなブックマークでも色々言われていたり、 http://b.hatena.ne.jp/t/%E4%BA%88%E5%91%8A.in?threshold=1 ニュースサイトでも、こんな煽り記事を書かれていたりするけれど… 今回の件についてIT企業に勤めるエンジニアに聞いてみると、 「これは初歩中の初歩。XSSコード書いた方も10分も掛かってないよ。それを事前に対策してなかった予告inにはもっとビックリだけど、、、素人なの？」 と語る。 予告inセキュリティ脆弱性を狙ったコード!? 「予告in開発者は素人」 http://news.livedoor.com/article/detail/3759632/ それってどうだろうね。 GoogleやAmazo
ふと気になって調べたことの備忘メモです ✍ （2022/11/3追記）ご指摘頂いた内容を踏まえて加筆修正をおこないました なぜ調べたか Webアプリケーションの開発に携わっていると CSRF という脆弱性への対処を求められますが、多くの場合利用しているフレームワークが設定追加だけで対応してくれたり、既に前任者によって適切な処置がされていたりなど、実務上で目を向ける機会はその重要性と比較して少ないのでないかと思います また、Webブラウザの実装やHTTP周辺の関連仕様の変化から陳腐化している情報も多く、現代において全体感と具体的な対処法を理解するには少しばかりハードルが高いように感じていました ですので、自身の現時点での認識を明文化して残しておくことにしました なお、私はWebセキュリティの専門家でなく、一介の開発者のため、誤りが多分に含まれる可能性があります ご指摘を頂ければ修正したいと思
Production (セキュリティ編)ということで疎かになりがちなセキュリティの話
2007年11月29日07:15 カテゴリ書評/画評/品評 Immortal Session の恐怖 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 荒らし発言は消してしまったが、にぽたんがlogを残してくれている。 nipotumblr - Dan the cracked man 一部で言われているように、本当にパスワードが抜かれたかどうかまでは解らない。が、状況としてはnowaがベータテスト段階で持っていたCSRF脆弱性をついた荒らしにそっくりだった。 にぽたん無料案内所 - こんにちはこんにちは！！ この時も、私のnowaのメッセージに荒らしが入った。パスワードを変更しても暫く荒らしが続いていた点も似ている。 ここでの問題は、 bulkneets@twitter曰く(直接リンクは避けます) 問題は本人が気付いてもパスワード変えてもセッション残
基本 普通にcookie使えばいいと思います。 loginリクエストもajaxで投げればcookie返ってくるので、何も考えることないかなと。 Cookie 動作イメージは以下の形です。 == サーバ → UA == Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com == UA → サーバ == Cookie: SID=31d4d96e407aad42 (from https://triple-underscore.github.io/RFC6265-ja.html) ブラウザの状態管理のためのもの。 もちろん主要ブラウザはどこも付いてます。 railsでもplayでもとりあえずこれでセッション管理されています。 secure属性があると、httpsのときだけやりとりされます。 HttpOnly属性があると、jsから読
RailsのCSRF対策の仕組みについて - （2015年までの）odaillyjp blog
先日、Rails で開発しているときに意図しない InvalidAuthenticityToken エラーが発生して、すごくハマってしまいました。そのときに Rails のCSRF対策の仕組みについて調べてみましたので、ブログに残しておきます。 Rails のCSRF対策 Rails が生成した ApplicationController には以下の記述があります。 class ApplicationController < ActionController::Base # Prevent CSRF attacks by raising an exception. # For APIs, you may want to use :null_session instead. protect_from_forgery with: :exception end protect_from_forg
サマリ PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。 はじめに 古庄親方の以下のツイートを見て驚きました。 CSRF用のトークンの作成 ＄token = password_hash(mt_rand(), PASSWORD_DEFAULT); ってのを書籍で見た………もンのすンげぇなぁ(苦笑 書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。 — がる (@gallu) July 17, 2019 CSRFトークンの生成に、password_hash関数を使うですと? 親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PH
HTML5 Security Cheatsheet
HTML5 Security CheatsheetWhat your browser does when you look away...
近年では多くの分野でWebアプリケーションが使われるようになり、大量の個人情報や重要な秘密情報を扱うようなアプリケーションも少なくない。そのため、Webアプリケーションも攻撃対象として狙われやすくなっている。今回はWebアプリケーションのセキュリティ対策として、Googleが公開しているセキュリティ調査ツール「skipfish」を使ったセキュリティスキャンを紹介する。 Webアプリケーションに特化したセキュリティ調査ツール「skipfish」 今日では、Webブラウザ経由でさまざまな操作を行えるWebアプリケーションが広く浸透している。Webブラウザは最近のほぼすべてのPCにインストールされており、専用のクライアントを用意せずにアプリケーションを操作できるというのがその浸透の理由の1つだ。しかし、Webアプリケーションでは簡単にその一部（HTMLやJavaScript）のソースコードを閲覧
なぜGoogleはJSONの先頭に while(1); をつけるのか #JavaScript #HTML #Ajax #StackOverflow - Qiita これはクロスサイト・リクエスト・フォージェリ対策。違うよ！全然違うよ！ 攻撃者の作成した罠ページにてJSONを<script src="target.json">みたいに読み込んで、ゴニョゴニョやることでJSON内の機密情報に攻撃者がアクセス可能というのは合ってるけど、それを「クロスサイト・リクエスト・フォージェリ」とは言わない。無理に何か名前をつけて呼ぶとすれば、「JSON Hijacking」という俗称や、あるいは単純にクロスサイトでの情報漏えい、程度ですかね。 ちなみに、ArrayコンストラクタやObjectでのアクセサを定義してJSONをJSとして読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古
SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - Flatt Security Blog
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
2010/11/13 に出たらしい http://bakery.cakephp.org/articles/markstory/2010/11/13/cakephp_1_3_6_and_1_2_9_released を読んでびっくりしたんですが、 Twitter を軽く検索した限りだと CakePHP ユーザでない僕が気づいているのに (日本の) CakePHP ユーザさんたちがどうも気づいていないっぽいのでわかりやすくまとめてみることにしました！ CakePHP には任意の PHP コードが実行できる致命的な脆弱性があります！ 影響のあるサイト結構ありそうですが悪用厳禁です！ ※通常リリースの告知のなかにこんな致命的な脆弱性に関する情報を思いっきりわかりにくく書いちゃうのはひどいなあと思うので、ユーザの方は CakePHP に文句を言うといいと思います。僕は CakePHP ユーザじゃない
攻撃から学ぶCSRF対策 - Qiita
はじめに WEBエンジニアとして成長するために、セキュリティ対策は避けては通れない道ですよね。 僕も含め 「なんとなく知ってる」 という方は多いのではないでしょうか。 大切なWEBサイトを守るためにも、WEBエンジニアとしての基礎を固める為にも、しっかりと学んで一緒にレベルアップしていきましょう。 また、本記事の内容は様々な文献をもとに自身で調べ、試したものをまとめています。 至らぬ点や、間違いがありましたら、コメントにてご指摘をお願いします。 他にも様々な攻撃手法についてまとめているので、興味のある方は読んでみてください。 攻撃から学ぶXSS対策 攻撃から学ぶSQLインジェクション対策 CSRFって何？ CSRF（Cross-Site Request Forgery）とは、サービスの利用者に意図しないHTTPリクエストを送信させ、意図しない処理を実行させる攻撃手法です。 これだけでは分か
『まあぶっちゃけ』
Amebaのセキュリティ対策について｜スタッフブログアメブロまわりを数分程度ざざっと眺めただけでも、 いたるところでCSRFの対策が入ってないようなんだけど、 この規模のサービスなら、いちおうそれなりにやっておいた方が…。 たぶん現状だと脆弱性をひとつひとつどこかに報告するとかっていうレベルじゃないです…。 (これらをセキュリティホールと呼ぶのか仕様と呼ぶのかは知らないけど…) [» この日記のブックマークコメントを見る/書く ]
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
cybozu developer network
３万社*1の業務課題を サイボウズのソリューションで解決しよう API ドキュメント、設計・開発・運用のノウハウや、イベント情報など、 エンジニアの成果を最大化する技術情報を発信しています。 *1 2024年5月時点でのkintone導入社数
UXとか難しいことはよくわかんないですが こんにちわ！@ampersand_xyzです。UXとかUIデザインとか、かしこさが低いので小難しいことはわからないですが、個人的にかつ主観バリバリで「イヤだな」って思うことはわかる！ 飛行機やホテルの予約などで、ちょいちょいお問い合わせフォームや予約フォームを使うのだけど、その時に思わずイラッとしちゃうようなフォームの要素を思い出してまとめてみました。 （1）要件的に適切でなさそうな必須項目が多い 名前や返信先などの情報が必須になるのはそれはもちろん構わないけれども、 所属部署名、とか、業種、とかそういうのが必須の場合。 もちろん、問い合わせる先やその内容によって、 例えば、保険等に関する問い合わせだと業種によって契約の内容が違ってきたりするので必須になるのは頷けるけれども、これが食べ物の通販の問い合わせフォームとかで必須だったら「？」って感じる。
クロスサイトリクエストフォージェリ (cross-site request forgery) は、Webアプリケーションの脆弱性の一つ[1]もしくはそれを利用した攻撃。略称はCSRF（シーサーフ (sea-surf) と読まれる事もある[2][3]）、またはXSRF。リクエスト強要[4]、セッションライディング (session riding[3]) とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていた[要出典]。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証 (CWE-345) による脆弱性のひとつとして分類している (CWE-352)[5]。 なおCSRFの正式名称はクロスサイトスクリプティング (XSS) と似ているが、XSSは不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類されており[5]、全く異なる種類の
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安心してRailsアップグレードを行うための工夫 - クックパッド開発者ブログ
書籍「気づけばプロ並みPHP」にリモートスクリプト実行の脆弱性
［はまちちゃんのセキュリティ講座］ここがキミの脆弱なところ…！ 記事一覧 | gihyo.jp
URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
【PHP】作成したメールフォームに脆弱性がないか、アドバイスもらえないでしょうか。
高木浩光＠自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに
今さら聞けないSPAのCORS対策の話
teratailに投稿されたメールフォームにCSRF脆弱性が残存した理由 | 徳丸浩の日記
IPAから「クリックジャッキング」に関するレポート出ました
開いただけで自動的にスターがつく便利日記 - ぼくはまちちゃん！
CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
猶予8時間！脆弱性だらけのサービスを堅牢化する実践型研修 - Speee DEVELOPER BLOG
CSRF(Cross-Site Request Forgery)攻撃について
Node.js のセキュリティの話
Immortal Session の恐怖 : 404 Blog Not Found
SPAでのセッション管理とセキュリティ - Qiita
PHPサーバーサイドプログラミングパーフェクトマスターのCSRF対策に脆弱性
Webアプリケーション向けのセキュリティスキャナ「skipfish」を使う | OSDN Magazine
GoogleのJSON(モドキ)の先頭にwhile(1); がつく理由 - 葉っぱ日記
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CakePHP の PHP コード実行の脆弱性を使って CakePHP を焦がす - co3k.org
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
やってられるか！！蹴りたいフォームの１２要素 - WP-E (仮)
クロスサイトリクエストフォージェリ - Wikipedia