モナコインへの攻撃から、ブロックチェーンへの攻撃やマイニングを深掘りする - Gunosy Blockchain Blog
こんにちは。ブロックチェーンやマイニングについて研究している榎本 (@mosa_siru)です。 2018年5月15日に、Monacoinのチェーンが攻撃されたようです。 今回は、事件そのものというより、それを通じてPoWやその攻撃手法、マイニングについて改めて深堀りしようかと思います。 ブロックの承認数 確率的finalityとトレードオフ Block withholding attack Selfish miningの研究について マイニングの中央性とハッシュアルゴリズム 対策 終わりに 宣伝 手前味噌ですが、マイニングについての基本的な理解はこちらを御覧ください。 tech.gunosy.io ブロックの承認数 まずご理解いただきたいのは、今回は最長チェーンが変わっただけで、「バグを突かれた」「ブロックチェーンのデータが改竄された」という話はありません。また、「6ブロック承認で送金が
仮想通貨マイニング（Coinhive）で家宅捜索を受けた話 - Webを楽しもう「ドークツ」
表題の通り、お恥ずかしい限りではありますが、人生ではじめて警察（神奈川県警！）のお世話になる運びとなりました。 罪状としては「不正指令電磁的記録 取得・保管罪」、通称ウイルス罪とのことで、まさに青天の霹靂の思いです。 以下ではこの度起こったことを可能な範囲でありのまま共有できればと思います。 この記事の目的まず、この記事を公開した目的は「他のクリエイターの人に同じ経験をして欲しくない」という一点に尽きます。 手前味噌ではありますが、私はこれまで多くの尊敬するクリエイターの方々と同じように「良いクリエイターであろう」と腐心し、できうるかぎりの努力をしてきたつもりです。 今回の件に関しても決して私利私欲のためではなく、あくまでユーザーのためにできることを、と模索した結果でした。 それがこのような形で取り沙汰されることとなり、残念という他ありません。 忸怩たる思いではありますが、この件から何かし
ビザンチン将軍問題 - Wikipedia
ビザンチン将軍問題（ビザンチンしょうぐんもんだい、英語: Byzantine Generals Problem）とは、相互に通信しあう何らかのオブジェクト群において、通信および個々のオブジェクトが故障または故意によって偽の情報を伝達する可能性がある場合に、全体として正しい合意を形成できるかを問う問題である[1]。フォールトトレラントシステムでの多数決の妥当性や分散コンピューティングの処理の妥当性に関わる問題と言え、二人の将軍問題を一般化したものと言える。 ビザンチン将軍問題に帰結される故障や障害をビザンチン故障（Byzantine Failure、あるいはビザンチン障害）と呼ぶ。また、ビザンチン将軍問題が発生しても全体として正しく動作するシステムをビザンチン・フォールトトレラント性（Byzantine Fault Tolerance）があるという。 ビザンチン将軍問題は、東ローマ帝国（ビザ
CDNとの付き合い方 – cat /dev/random > /dev/null &
最近何かと話題なCDNですが、そもそもCDNってなんだろう・・・どんなことに使えるんだろう？的なことを書いてみようと思います。 一応先に言っておくと、私はCDN業者に所属したことないのであくまでも利用者として見た時の話を書きます。 また、私の考えであり、様々なワークロードがあるなかでこれがすべてではありませんので、こんな考えもあるんだなぁぐらいに思ってもらえると助かります。 そもそもCDNってなんだろうか そもそもCDNはContent Delivery Networkの略であってCache Delivery Networkの略ではありません。 要はコンテンツをクライアントに対して高速・効率的に配信するためのネットワークです。 良くCDNといえばその成り立ちからキャッシュというイメージはありますが、重要な要素の一つではあるもののCDNの全てではありません。 さらに言えばAkamaiのInt
Stop using JWT for sessions - joepie91's Ramblings
Update - June 19, 2016: A lot of people have been suggesting the same "solutions" to the problems below, but none of them are practical. I've published a new post with a slightly sarcastic flowchart - please have a look at it before suggesting a solution. Unfortunately, lately I've seen more and more people recommending to use JWT (JSON Web Tokens) for managing user sessions in their web applicati
DOM ベース XSS 対策チートシート - OWASP
クロスサイトスクリプティング (XSS) は、一般に次の 3 種類に分類されます。 反射型、格納型、および DOM ベースの XSS です。反射型 XSS と格納型 XSS については、XSS 対策チートシートで詳しく取り上げています。このチートシートでは、ドキュメントオブジェクトモデル (DOM) ベースの XSS について説明します。このチートシートは、XSS 対策チートシートの延長であり、その内容の理解を前提としています。 DOM ベースの XSS を理解するには、DOM ベースの XSS と反射型および格納型 XSS との基本的な違いを知る必要があります。最も大きな違いは、攻撃がどこでアプリケーションに挿入されるかです。反射型 XSS と格納型 XSS がサーバー側でのインジェクションの問題であるのに対し、DOM ベースの XSS はクライアント (ブラウザー) 側でのインジェクシ
クロスサイトスクリプティング (XSS) 対策チートシート - OWASP
この資料では、適切に出力のエスケープ / エンコードを使用した XSS 対策について、シンプルかつポジティブなモデルを紹介します。極めて多くの XSS 攻撃ベクトルがありますが、いくつかのシンプルなルールに従うことで、この重大な攻撃を完全に防ぐことができます。この資料では、XSS の技術的な影響、ビジネスへの影響は扱いません。XSS を使用すれば、攻撃者は、被害者がブラウザーを使用して実行可能なあらゆる行為を行うことができるとだけ、ここでは述べておきます。 反射型 XSS と格納型 XSS の両方ともに、サーバー側で適切な検証とエスケープを実行することで対応できます。DOM ベース XSS には、DOM ベース XSS 対策チートシートで説明する特殊なルールのサブセットにより対応できます。 XSS 関連の攻撃ベクトルについてのチートシートは、XSS フィルター回避チートシートを参照してくだ
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
「WebAPIのステートレスなCSRF対策」という2011-12-04の記事がありました。 ここで説明されているCSRF対策は、 GET、HEAD、OPTIONSメソッドのHTTPリクエストはCSRF保護の対象外 HTTPリクエストにX-Requested-Byヘッダがなければエラーにする という非常にシンプルなものです。 そして、この対策の原理として以下の説明がありました。 form, iframe, imageなどからのリクエストではHTTPリクエストに独自のヘッダを付与することができません。独自のヘッダをつけるにはXMLHttpRequestを使うしかないわけです。そしてXMLHttpRequestを使う場合にはSame Origin Policyが適用されるため攻撃者のドメインからHTTPリクエストがくることはない、ということのようです。 ここで、 XMLHttpRequestを使
HTTPヘッダ・インジェクション - Wikipedia
HTTPヘッダ・インジェクション（HTTP header injection）とは、HTTPを使って通信するシステムにおいて、動的にHTTPヘッダを生成する機能の不備を突いてヘッダ行を挿入することで不正な動作を行なわせる攻撃手法のこと。また、その攻撃を可能とする脆弱性のこと。 原理[編集] SQLインジェクションなどと同様に、入力値を出力に用いている箇所において、文法上特殊な意味を持つ文字をエスケープせずに展開することで発生する。 HTTPヘッダにおける特殊文字とは、改行コードである。各HTTPヘッダ行は改行で終了し、それ以降は新たなヘッダ行として処理される。この結果、HTTPヘッダの値として改行コードを挿入することができれば、本来の通信内容には含まれないヘッダを挿入することができる。 また、HTTPは空行によってヘッダとボディを区切っている。連続する改行を挿入すればHTTPヘッダの終了を
XSS フィルター回避チートシート - OWASP
この資料は、アプリケーションのセキュリティテストを行う技術者に、クロスサイトスクリプティングのテストを支援するガイドを提供することに重点を置いています。この資料の初期版は、RSnake から OWASP に寄付されたもので、彼のセミナーの XSS チートシートが元になっています(http://ha.ckers.org/xss.html)。現在このサイトにアクセスすると、この新しいサイトにリダイレクトされるようになっており、今後はここで保守や強化が行われる予定です。最初に作成された OWASP 対策チートシート、XSS (クロスサイトスクリプティング) 対策チートシートは、RSnake の XSS チートシートをベースにしています。彼に謝意を表します。私たちは、攻撃に関する複雑なチートシートにあらゆる巧妙なトリックを列挙して、とにかくこれらを防ぐアプリケーションを構築せよと開発者に言うのでは
フロントエンド開発のためのセキュリティ | 第1回 XSSの傾向と対策
フロントエンド開発のためのセキュリティ 第1回 XSSの傾向と対策 本シリーズではフロントエンドの開発に関係するセキュリティについて、理解を深めます。第1回目はXSS（クロスサイトスクリプティング）です。実装失敗例を挙げつつ、対策のポイントを解説します。 セキュリティはサーバーサイドの問題？ セキュリティに関わるミスは「知らなかった」ではすまされない場合が、往々にしてあります。 ちょっとしたミスでプログラムにバグを作ってしまい、サービスが一部動かなくなったとしても程度にもよりますが、すぐに修正すれば一部のユーザーに少し不便をかけてしまう程度ですむでしょう*。 *注：サービス運営 この記事ではセキュリティの技術的な側面を扱います。ユーザーに不便をかけてしまったことに対するサービス提供側の倫理的問題についてはそのつど言及はしませんが、これらの側面を軽視すべきでないことはいうまでもありません。
Home - Broadcom Community - Discussion Forums, Technical Docs, Ideas and Blogs
VMware Explore Registration Is Open Map your next move at the industry’s essential cloud event in Las Vegas August 26 – 29. Register Now Welcome VMware Members We are pleased to announce that VMware Communities, Carbon Black Community, Pivotal Community, and the Developer Sample Exchange will go live on Monday, 5/6. Stay tuned for updates. Read More Welcome VMware Members We are pleased to annou
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IPA-安全なウェブサイトの作り方2021年改訂第7版.pdf
ウェブ健康診断仕様
Browser's XSS Filter Bypass Cheat Sheet
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
