tl;dr Many SQL query builders written in Perl do not provide mitigation against JSON SQL injection vulnerability. Developers should not forget to either type-check the input values taken from JSON (or any other hierarchical data structure) before passing them to the query builders, or should better consider migrating to query builders that provide API immune to such vulnerability. Note: 問題の発見者による日
スマートフォンのセキュリティについて ma.la 自己紹介 http://ma.la https://twitter.com/bulkneets LINE株式会社 livedoor方面の人です 仕事 JavaScript, Perl 元々の専門領域はUI, フロントエンド Webアプリ全般 認証認可周り セキュリティに関する業務 自社サービスのリリース前にチェックしたりとか 何か新しい攻撃手法見つかったら調査 他社サービスの問題見つけて報告したり オープンソースプロダクトのバグ報告したり そもそも何でJavaScriptを書いてた人間が セキュリティに関することをやっているのか あらゆるデバイスでHTML + JavaScriptが使われている どこまで悪用できるのか、どうやって修正すべきなのか 社内でもっとも詳しい 基本的にはWebの人 iOS / Android アプリ開発あまり詳しく
http://corner.squareup.com/2013/12/securing-rubygems-with-tuf-part-3.html1 comment | 0 points その1はこちら。 6) Timeliness RubyGemsのサーバのアクセス権を得た悪意の侵入者は、クライアントからのアップデートができないようにするのは簡単にできるが、クライアント側もエラーを受け取るのですぐにわかる。 もっと気づきづらい攻撃は、セキュリティの脆弱性のあるgemを参照しているtargetsのファイル（targets.txtやverified.txtなど）のバージョンを配ること。tragetsファイルはオフラインキーでサインされてるため、任意のコンテンツに変えることはできないが、古いものを再利用することはできる。クライアント側では受取る情報が古いかどうかは知る由もない。 TUFはこの攻
http://corner.squareup.com/2013/12/securing-rubygems-with-tuf-part-1.html1 comment | 0 points Squareの開発チームが、年初のようにRubyGemsの脆弱性が万一また見つかり問題になることを未然に防ぐために、The Update Framework (TUF)をRubyGemsに導入した取組みを紹介しています。 RubyGemsはファイルサーバであるので、まず最新のバージョンを確認するためにindex（/latest_specs.4.8.gz）を取得して、それから、実際にgem（/gems/somegem-0.0.1.gem）をダウンロードするURLを用意する。もし悪意のあるユーザがサーバにアクセスできるようになると、ファイルを修正して悪意のあるコードを仕込むことができる。それに対して、TUFは
既報のとおり、はてなブックマークの「マイブックマーク全文検索API」に仕様と実装上の問題が発見されました。そこで、2013年12月3日 16:00 以降、本APIへのリクエストの際に「ユーザー認証にCookie認証を使用していて、かつJSONPのcallbackパラメータを指定している場合に限り、常に空の検索結果に相当するレスポンスが返る」という仕様に変更しました。また、同条件でのAPIのリクエストは2014年1月8日以降、HTTPエラー (403 Forbidden) が返るようになります。 本APIを該当する方法でご利用の開発者様は、大変お手数をおかけし申し訳ありませんが、OAuth認証またはWSSE認証を用いた実装に変更いただきますよう、よろしくお願いいたします。 「マイブックマーク全文検索API」は、ユーザー認証をおこなった上で、ユーザーのブックマークを外部のアプリケーションから全
自分が作るウェブアプリケーションでは基本的に以下のような規則を守るようにしている GET だけで副作用 (DB書きこみなど) を伴う処理をしないこと POST 時には自動的に CSRF 防止用トークンをチェックすること これだけで単純な CSRF はまず防げくことができるからだ (実際は CSRF 防止用トークンの生成方法が多少問題になるが、作るウェブアプリケーションによって、どれほど厳密にすべきかが違うため、そのたび考えてやりかたを変えてる) このような設計をした場合、全ての POST するフォームに input type="hidden" とかで CSRF 防止用トークンを埋めこむ必要がある。ウェブアプリケーションフレームワークによっては、防止用トークンを埋めこむところも自動的にやってしまうものもあるが、外部サーバへ POST するフォームなんかを作ったとき (ASP型の外部サービスと
合わせて読んでください：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
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
WebSocketを使ってゴニョゴニョしているのだが、handshakeの失敗時のエラーをどう扱うべきなのか、よくわからない。WebSocket Protocol の仕様と WebSocket API の仕様で書いてあることが違う。 protocol仕様を読む限り、サーバーはhandshakeを拒否する場合適切なHTTPエラーコードを返さなくてはいけない、と書いてある。が、クライアント側のウェブブラウザ上のjavascriptでそれを期待しているとエラーイベントからはHTTPエラーコードは受け取れない。WebSocketの異常終了コード1006が固定でセットされている。 そこでAPI仕様を読むと、これらを行わない理由が赤字で大きく書いてある。 オープンリダイレクタが設置されたサイトで脆弱性になるので、handshakeのレスポンスはHTTPとして扱わない。悪意あるスクリプトに攻撃の準備とし
[1]http://d.hatena.ne.jp/ockeghem/20110907/p1[2]http://www.atmarkit.co.jp/fcoding/articles/webapp/05/webapp05a.html[3] http://msdn.microsoft.com/ja-jp/asp.net/ff713315[4] http://labs.cybozu.co.jp/blog/kazuho/archives/2007/01/cross-site_including.phpあたりをよんで、JSON とセキュリティについてかんがえてみた。 ここで、有効とされている対策のうち while(1); を先頭に付与するPOST ですべて処理するといったあたりは、RESTful でないし、BK 感がひどいというか本質的ではないのでできるだけやりたくない。 また、Amon2 では互換
特定のバージョンのMySQLおよびMariaDBにおいて、「256分の1の確率で、パスワードが間違っていたとしてもパスワード認証を突破できてしまうう」バグが発見された（SecLists.Org、SecManiac）。 このバグを使用すると、300回程度のアクセスを試みるだけでrootを含む任意のユーザーでのログインが可能であり、事実上パスワード認証が意味を成さなくなってしまうとのこと。 ただしこれらの影響を受けるビルドは少なく、多くの公式ベンダが提供するビルドでは問題はないそうだ。 対象となるMariaDBおよびMySQLのバージョンは5.1.61、5.2.11、5.3.5、5.5.2。こただしこの問題が発生するか否かはmemcmpの実装によって異なり、GCCビルトインのものやBSDのlibcのものについては安全だが、LinuxのSSE最適版glibcに含まれるmemcmpについては安全で
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
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 脆弱性とは何か、
2012/02/15、 JVN から JVN#35256978: cforms II におけるクロスサイトスクリプティングの脆弱性 が公開されました。これはクレジットされているとおり、海老原と、同僚の渡辺優也君が勤務中に発見した脆弱性です。 脆弱性自体はどこにでもあるような普通の XSS ですが、実はこの脆弱性、 2010 年 10 月に exploit コードが公開され、それから 1 年 4 ヶ月後の 2012 年 2 月まで修正版が提供されていなかったものです。 このような危険な状態が長期間続いていたのには、様々な理由があります。ここでは、その説明と、どうすれば事態が防げたかということについて検討したいと思います。 脆弱性の概要 本題に入る前に、主に cforms II のユーザ向けに脆弱性自体の概要についてざっくり説明します。前述のとおり、未修正の状態で exploit コードが公開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
