noteの独自ドメインセッションの脆弱性について報告した件
note_vuln.md noteの独自ドメインセッションの脆弱性について報告した件 文責: mala 前置き note.com (以下note) に2020年に報告した脆弱性(現在は修正済み)を解説する 個人の活動として行っており所属組織とは関係がない 自分がnote社に対して、問題があると指摘していたのは主に広報対応についてですが、この記事は技術的な知見を共有することを目的とするため、技術的な解説を中心にします。 公開にあたってはnote社に対して確認の上で行っています。note社による修正対応は2021年までに実施されていますが、その修正内容が適切であるかどうかについて保証するものではありません。(網羅的な確認や追加の検証をしていません) note社のサービスに他の脆弱性が無いことを保証するものではありません。 経緯 2020年9月30日に公開されたnote社の記事で https:/
Smoozサービス終了に寄せて
202012_smooz.md Smoozサービス終了に寄せて 前置き この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。 一方で私は、企業が閲覧履歴を収集して何をしたいのか、所属してる企業や他社事例について、ある程度詳しい当事者でもあります。 一般論として書けることは書けるが、(業務上知り得た知識で開示されてないものなど)個別具体的なことは書けないこともあり、また観測範囲に偏りがある可能性もあります。 Smoozに報告した脆弱性2件 最近、Smoozというスマホ向けのブラウザアプリに2件脆弱性の報告をした。 この記事を書いている時点で、Smoozの配布が停止されていて、修正バージョンの入手が出来ない。 2件目についてはまだ返事が来ていない。 脆弱性情報の開示にあたって特段の許可は得ていないが、開発元からも利用停止す
Rails の CVE-2019-5418 は RCE (Remote code execution) です
CVE-2019-5418_is_RCE.md Rails の CVE-2019-5418 は RCE (Remote code execution) です 2019-03-23 更新 Remote Code Executionとして、Advisoryが更新された。 https://groups.google.com/d/msg/rubyonrails-security/zRNVOUhKHrg/GmmcVXcmAAAJ Thanks to @sorah @tenderlove 前置き これは休日に書いた記事で所属している組織とは一切の関係がない。 概要 CVE-2019-5418 は実際のところ高確率でRCEなのだが File Content Disclosure という聞き慣れない名前で公表されて、CVE-2019-5419 で DoSが出来るという内容になっている やあ、脆弱性の開示方
次世代Webカンファレンス 2019 振り返り
nwc.md 次世代Webカンファレンス 2019 振り返り この文章に関しても所属組織とは関係のない個人の見解です 所感など 本当に全く打ち合わせをしていないので、話題が分散しがちだったかもしれない。 せっかくの所属組織とは無関係のレギュレーションなので、具体名を上げてガンガン治安の悪いことを言うつもりだったのだけど、直前に「具体的な企業名は避けましょう」と言われて若干遠慮した。 マズいことをガンガンしゃべる覚悟で来たので、防刃ベストを着ているが、特に出番は無かった。トイレにも行った。 本当は話す予定だったトピックについて、いくつかは、別途private gistに書く。 話した話題の参考情報 CDN設定の話、request collapsing という名前の機能 https://tech.mercari.com/entry/2017/06/22/204500 http://www.it
Orarioについての雑感
o.md 調べたこと 通信をキャプチャして調べた。似たようなことをしている人が既にいて仕組みについてはサービス提供者側が説明されているとおりだった。 http://www.orario.jp/system/ https://twitter.com/mage_1868/status/853992239369830404 https://twitter.com/mage_1868/status/854028454081159169 IDパスワードはネイティブUIで表示して、html中のどこに入力するかなどはリモートから受信するjsで定義している。特に難読化や独自の暗号化などがされているわけではない。 "例のアプリの方式、運営がその気になったらこっそり(アプリのアップデートを必要とせず)情報収集が可能な上、apiサーバがpwnされたら終わりという点でリスクはサーバ側で大学アカウント保持するのと大
暮らしに役立つITコラム ChromeやSafariの自動入力機能が、なぜ「悪いデザイン」なのか
autofill_ui.md 見た目の上で、隠されているフィールドに対しても自動入力してしまうという問題が話題になっている(2017年1月) https://github.com/anttiviljami/browser-autofill-phishing のだけれど、この問題の歴史はとても古い。自分も調査したり問題を報告したりしているので、振り返ってみる。 2012年の話 2012年4月のShibuya.XSS #1 https://atnd.org/events/25689 で、Hamachiya2が発表した http://hamachiya.com/junk/x-autocompletetype.php この問題に関連して「手の込んだクリックジャッキング」を使って情報を盗み出すデモを作った。 https://plus.google.com/112675818324417081103/
Chrome ExtensionのLive HTTP Headersの調査(CoolBar.Pro導入 Extensionが何を行うかの調査)
a.md Chrome ExtensionのLive HTTP Headersを調査した。Firefox用のものではない。Firefox用のものではない。 https://chrome.google.com/webstore/detail/live-http-headers/iaiioopjkcekapmldfgbebdclcnpgnlo 11/7追記 類似 or 同様の方法で難読化scriptを埋め込んでいる拡張機能が大量にあったため、Googleに報告済み。 https://twitter.com/bulkneets/status/795260268221636608 English version: https://translate.google.com/translate?sl=ja&tl=en&js=y&prev=_t&hl=ja&ie=UTF-8&u=https%3A%2F%
Firefox 22のCookieに関するポリシー変更(予定)についての意見書
http://security.slashdot.jp/story/13/02/24/0858210/ Firefox 22のCookieに関するポリシー変更(予定)で具体的にどういう悪影響が懸念されるのかについて書きます。 この変更は「サードパーティCookieをデフォルトでブロック」と言われて想像するものと少し違います。 正確には既にCookieが保存されているドメインであれば3rd party cookieの読み書きを緩和して、新規での3rd party cookieの保存をブロックするというものです。Safariの現行のポリシーとほぼ同じものです。 自分は直接的な不利益を受ける立場ではない。 自分の所属している企業のWebサイトの多くは広告収益に依存しているが、この変更があっても「巨大な」インパクトは恐らくない。 常用している全てのブラウザで3rd party cookieをブロッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について
Yahoo広告配信用 s.yimg.jp ドメインでのXSSの解説
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
TwitterのOAuthの問題まとめ