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
ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
しゃおの雑記帳 - 携帯サイト開発者のためのセキュリティ再入門
通勤電車で周囲を見渡せば大抵数台のスマートフォンを見つけられるようなご時世ですが、現実は日本の伝統的な携帯電話が多数派です。今もそんなガラケー向けWebサイトの開発案件は衰えることありません。 そんなガラケーサイトの開発者の間で話題になっている「セキュリティ対策」について、ガラケー界の現状をふまえた上でまとめてみます。 携帯電話のIPからのアクセスであることを前提としたセキュリティ対策はすでに無駄 ソフトバンク3Gのプロクシ情報は検索すればすぐに出てきます イー・モバイルのEMnetに至っては公開情報です サイトのソースもFlashのswfも画像もPCから丸見えだと思うべきです 危険な「かんたんログイン」 かんたんログインで使う契約者IDはあなたのサイトにも他のサイトにも同じものが送出されてます 悪意をもった人が他人の契約者IDをヘッダに乗せてかんたんログインのアクションを呼び出したらどう
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
ガラパゴスに支えられる携帯サイトのセキュリティ | 水無月ばけらのえび日記
公開: 2010年3月6日14時20分頃 モバツイ (www.movatwi.jp)作者のえふしんさんが、こんなつぶやきを。 携帯サイトは、閉じられた環境であることを前提として作られている場合があります。すなわち、以下のような前提です。 利用者が自由にHTTPリクエストをしたり、リクエストパラメータを改変することはできないこれはPCサイトでは全く通用しない話です。通常のインターネットからの接続では、telnetなどで好きなデータを送信できますので、通信内容はいくらでも改変できてしまいます。 PCサイトの場合は、それでも問題ありません。攻撃者はリクエストを改竄できますが、ターゲットになりすますためには、ターゲットの識別情報を入手する必要があります。PCサイトで標準的に使われる識別方法は、Cookieを発行することで端末(ブラウザ)を識別するという方法です。Cookieは発行したサイトにしか送
中古ドメインでGoogleAppsを使ったら - y-kawazの日記
最近あるドメインを取得したんだが、実はこのドメインは僕が最初に取得したものではなく、前のドメイン所有者が管理放棄したか期限切れになったモノを僕が取得したもののようだ。普通は中古のドメインだからといっても困ることはそうは無いもんだが、今回は珍しいケースに当たったのでネタにしてみる。 中古ドメインだったんだなーと気付いたのはGoogleAppsにドメインを登録しようと、ドメイン名を入力したときだ。 ↓こんなメッセージが出て登録できなかった。 このドメインは既に Google Apps に登録されています。 このドメインで Google Apps を使用する手順については、ドメイン管理者にお問い合わせください。 なんと既に登録されてるとな？すぐに前のドメイン所有者がAppsを使ってたんだなと思い至ったんだがさてどうしたらいいんだろう？ GoogleAppsの管理アカウントを取り戻す手順 既に存在
本当は怖い文字コードの話 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須
(Last Updated On: 2016年3月3日)最近PostgreSQL、MySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考：セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQL、MySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト～6バイト必要なのか
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
Twitterのハッカーとのコンタクトに成功―攻撃手口の詳細が判明した
The tech layoff wave is still going strong in 2024. Following significant workforce reductions in 2022 and 2023, this year has already seen 60,000 job cuts across 254 companies, according to independent layoffs tracker Layoffs.fyi. Companies like Tesla, Amazon, Google, TikTok, Snap and Microsoft have conducted sizable layoffs in the…
ケータイの流儀を常識と思いこむのは危険 | 水無月ばけらのえび日記
公開: 2009年8月6日14時10分頃 「やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 (takagi-hiromitsu.jp)」。 iPhone・iPod Touch用の「ニコニコ動画」アプリのサーバ側実装が脆弱だったというお話。iPhoneやiPod Touchの端末製造番号 (UDID) は秘密情報ではない上に詐称可能なのですが、そのUDIDに依存した認証を行っていたため、他人のUDIDが分かると、その人の非公開マイリストなどが見られてしまう……ということのようで。現在は修正されているようです。 脆弱性の話としては、認証方法の不備という単純な話なのですが、むしろ周辺の反応が興味深いですね。いちばん面白いと思ったのがこのブックマークコメント。 ツッコミがたくさん入っていますが、「流儀が違う」というのは、実は全くその通りなのですね。端末固有IDによる
i-mode2.0セキュリティの検討: 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 - 徳丸浩の日記(2009-08-05)
_携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。 実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止
高木浩光＠自宅の日記 - やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合
■ やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 一年前、「退化してゆく日本のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。 iPhoneに契約者固有ID送信機能が搭載される日 （略）こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。 （略）iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 （略）契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなけれ
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
アルパカ牧場 那須ビッグファーム: FirefoxアドオンのNoScriptの仕様の罪をはてブックマークレットに擦り付けるのはお止めなさい
参考資料 http://b.hatena.ne.jp/entry/http://takagi-hiromitsu.jp/diary/20081125.html%23p01 なんか阿呆なこと書いている人がいるので言及しておく。 noscript入れてると（信頼してるサイト以外では）動かない？/ひとまず旧バージョン使ってます。 はてなブックマーク - 高木浩光＠自宅の日記 - 新はてなブックマークの登録ブックマークレットは使ってはいけない 火狐でNoScript使ってると、どっちにしろ旧ブックマークレットしか使い物にならないんだよね はてなブックマーク - 高木浩光＠自宅の日記 - 新はてなブックマークの登録ブックマークレットは使ってはいけない 残念、新旧どちらも動きません。 ブックマークレットはそのページのドメイン上で動きます。そのページを信頼するものとしない限り、ブックマークレットは動きま
高木浩光＠自宅の日記 - 新はてなブックマークの登録ブックマークレットは使ってはいけない
はてなブックマーク（以下「はてブ」）がリニューアルされ、ブラウザからブックマークレットでブックマーク登録（以下「ブクマ登録」）しようとすると、図1の画面が現れるようになった。「こちらから再設定をお願いします」と指示されているが、この指示に従ってはいけない。ここで提供されている新型ブックマークレットは使ってはいけない。（この指示には従わなくてもブクマ登録はできる。） 新型ブックマークレットを使用すると図2の画面となる。ブクマ登録しようとしているWebサイト（通常、はてな以外のサイト）上に、はてブの画面のウィンドウが現れている。これは、Ajaxと共に近年よく使われるようになった「ページ内JavaScriptウィンドウ」である。（ポップアップウィンドウとは違い、ウィンドウをドラッグしてもブラウザの外に出すことはできず、あくまでも表示中のページ上のコンテンツであることがわかる。）
ITproのセキュリティ検定がヤバイ | 水無月ばけらのえび日記
更新: 2008年11月7日1時55分頃 こんなのがあったのですね。「ITpro EXPO検定---全11分野で，あなたのIT理解度はいかに？ (itpro.nikkeibp.co.jp)」。 セキュリティ検定の解説もあったので見てみましたが、超難問が3問ほどあったので、独自に解説してみます。 Webブラウザを狙うクロスサイト・スクリプティングは，どのような問題点によって起こるでしょうか。 A） クライアントOSの弱点（ぜい弱性） B） Webブラウザを使うユーザーの油断 C） Webブラウザの弱点（ぜい弱性） D） Webサーバーの弱点（ぜい弱性） 以上、セキュリティ検定の解説【問題2】 より 「WebサーバやWebブラウザにもクロスサイトスクリプティング脆弱性がある」という知識を問う問題ですね。XSSというと普通はWebアプリケーションの問題ですが、WebブラウザやWebサーバに問題が
Ruby on Railsのセキュリティガイドブックが公開 | OSDN Magazine
ドイツのWebアプリケーションセキュリティコンサル企業らが設立したRuby on Rails Security Projectは11月4日、Ruby on Rails（RoR）のセキュリティガイド「Ruby on Rails Security guide」を公開した。HTMLページまたはeブック形式で無料で閲覧できる。 RoRアプリケーションを安全にするためのガイドブックで、ドイツ在住の開発者で同プロジェクトのオーナーでもあるHeiko Webers氏が作成した。セッション、クロスサイトリファレンス偽造（CSRF）、アカウントハイジャックやCAPTCHAsなどのユーザー管理、SQLインジェクションやクロスサイトスクリプティングなどのインジェクションなどの項目について、説明や具体的なアドバイスを綴っている。 Webers氏は、RoRのようなWebアプリケーションフレームワークは正しく利用すれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
