サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
gist.github.com/mala
202012_smooz.md Smoozサービス終了に寄せて 前置き この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。 一方で私は、企業が閲覧履歴を収集して何をしたいのか、所属してる企業や他社事例について、ある程度詳しい当事者でもあります。 一般論として書けることは書けるが、(業務上知り得た知識で開示されてないものなど)個別具体的なことは書けないこともあり、また観測範囲に偏りがある可能性もあります。 Smoozに報告した脆弱性2件 最近、Smoozというスマホ向けのブラウザアプリに2件脆弱性の報告をした。 この記事を書いている時点で、Smoozの配布が停止されていて、修正バージョンの入手が出来ない。 2件目についてはまだ返事が来ていない。 脆弱性情報の開示にあたって特段の許可は得ていないが、開発元からも利用停止す
covid19-twitter-research_01.md 生活と意見: ソーシャルディスタンスなどと称してユーザー名や文章にスペースを挟む行為についての苦情 更新履歴 2020-05-13 追記 継続して観測していて、対応が行われたアカウントの記録などを残している https://twitter.com/bulkneets/status/1259419102851903490 FAQとして「機械が人間の都合に合わせろ」に対する反論を取り急ぎ置いておく 走り書きで書いた https://twitter.com/bulkneets/status/1260524434256879617 https://twitter.com/voqn/status/1259515760986095617 記事下部に、フィードバックなどを追記した。 はじめに この文章は mala (twitter: @bul
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
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/
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
note_vuln.md noteとインシデントハンドリングと広報の仕事 前提 この文章はmalaが書いています。個人の見解であり所属している企業とは関係ありません。 noteには知り合いが何人かいるし、中の人と直接コンタクトも取っているし相談もされているが、(10月2日時点で)正規の仕事としては請け負っていない。 10月2日追記 正規の仕事として請け負う可能性もありますが、自身の主張や脆弱性情報の公開に制限が掛かるのであれば引き受けないつもりです。 脆弱性の指摘や修正方法以外にも意見を伝えることがありますが、公表されている文章については、あくまでnote社内で検討されて発信されているものであり、必ずしも自分の意見が反映されたものではありません。(事前に確認などはしてません) 重要 この記事には、9月30日付けと、10月1日付けでnoteに報告した脆弱性についての解説を後ほど追記します。誠
nwc.md 次世代Webカンファレンス 2019 振り返り この文章に関しても所属組織とは関係のない個人の見解です 所感など 本当に全く打ち合わせをしていないので、話題が分散しがちだったかもしれない。 せっかくの所属組織とは無関係のレギュレーションなので、具体名を上げてガンガン治安の悪いことを言うつもりだったのだけど、直前に「具体的な企業名は避けましょう」と言われて若干遠慮した。 マズいことをガンガンしゃべる覚悟で来たので、防刃ベストを着ているが、特に出番は無かった。トイレにも行った。 本当は話す予定だったトピックについて、いくつかは、別途private gistに書く。 話した話題の参考情報 CDN設定の話、request collapsing という名前の機能 https://tech.mercari.com/entry/2017/06/22/204500 http://www.it
note_vuln.md noteの独自ドメインセッションの脆弱性について報告した件 文責: mala 前置き note.com (以下note) に2020年に報告した脆弱性(現在は修正済み)を解説する 個人の活動として行っており所属組織とは関係がない 自分がnote社に対して、問題があると指摘していたのは主に広報対応についてですが、この記事は技術的な知見を共有することを目的とするため、技術的な解説を中心にします。 公開にあたってはnote社に対して確認の上で行っています。note社による修正対応は2021年までに実施されていますが、その修正内容が適切であるかどうかについて保証するものではありません。(網羅的な確認や追加の検証をしていません) note社のサービスに他の脆弱性が無いことを保証するものではありません。 経緯 2020年9月30日に公開されたnote社の記事で https:/
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%
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が出来るという内容になっている やあ、脆弱性の開示方
CVE-2018-0691.md CVE-2018-0691 プラスメッセージにおける証明書検証不備について https://jvn.jp/jp/JVN37288228/ 平日の業務時間内に見つけた問題である関係で(自分ルールで)所属を入れていますが、他社サービスに対する調査や報告は業務とは一切関係のない個人の活動として行っています。 文責はmala個人にあります。お問い合わせなどありましたら個人宛にどうぞ。TwitterのDMや任意の文字列 @ma.la 概要 2018-06-21 に脆弱性の報告を行い 2018-06-27 に修正版が公開されたプラスメッセージについて、2018-09-27 に情報開示が行われているので、経緯について書きます。 タイムライン 2018-06-21 11:44 プラスメッセージのiOS版が公開されたと聞いてインストールする 2018-06-21 12:54
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されたら終わりという点でリスクはサーバ側で大学アカウント保持するのと大
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をブロッ
0_medium_vuln_en.md Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature Author: mala Introduction This article describes a vulnerability in a web service called Medium that allows you to steal visitors' e-mail addresses by using custom domain plan of Medium. This is done as my personal activity and is not related to my organization.
meety_vuln.md Meety脆弱性 2022-11 文責 mala 経緯: Meety退会しようと思ったがアカウントがなかったので、退会するためにアカウントを作ることにした。 免責: 気になった範囲ですぐに見つかったもののうち、悪用可能なものを記載しています。 好ましくないが仕様だろうというものは書いていません。 他の脆弱性が無いことを保証するものではないです。 これはsecret gistです 11/24 時点で未修正の脆弱性情報が含まれています。修正されたらpublicに変更する予定です。 近しい人向けの注意喚起と、開発元への報告を兼ねて書いています。 悪用を教唆したり、悪用しそうな人に情報を共有することは避けてください。 自分の所有していないアカウントの情報を書き換えると法に触れるので、そのような行為は絶対にやめてください。 11/25 Publicにしました 以下 1-4
2021_browser_mitm_vuln.md LunascapeとSleipnirに報告した脆弱性の話(スマホアプリではとにかくHTTPSを使え2021) 前置き この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。 執筆時点で未修正の不具合や、過去に修正済みで運営元が開示していない脆弱性情報なども含みますが、公益を意図しています。 概要 2020年の年末に、スマホ向けのLunascapeとSleipnirに対して、以下の問題を脆弱性として報告した。 入力途中も含む検索キーワードが、平文で開発元または検索サービスのサーバーに送られる。 利用者が閲覧しようとしたURLが、平文で開発元または検索サービスのサーバーに送られる経路がある。(閲覧URL全部送られたりするわけではない) 2021年の1月に修正されて、修正内容
スマートフォンのセキュリティについて ma.la 自己紹介 http://ma.la https://twitter.com/bulkneets LINE株式会社 livedoor方面の人です 仕事 JavaScript, Perl 元々の専門領域はUI, フロントエンド Webアプリ全般 認証認可周り セキュリティに関する業務 自社サービスのリリース前にチェックしたりとか 何か新しい攻撃手法見つかったら調査 他社サービスの問題見つけて報告したり オープンソースプロダクトのバグ報告したり そもそも何でJavaScriptを書いてた人間が セキュリティに関することをやっているのか あらゆるデバイスでHTML + JavaScriptが使われている どこまで悪用できるのか、どうやって修正すべきなのか 社内でもっとも詳しい 基本的にはWebの人 iOS / Android アプリ開発あまり詳しく
https://gist.github.com/mala/5062931 の続き。 Twitterの人に色々と問題点は伝えたんだけど、これからOAuthのサーバー書く人や、クライアント書く人が似たような問題を起こさないようにするために、どうすればいいのかについて簡単に書きます。既存の実装真似して作るとうっかりひどい目にあう。 自分は意図的に「Twitterの脆弱性」という表現を使わないように気を使っていて、それはクライアントアプリ側の責任もあるからなのだけれども、安全に実装するための方法がわかりにくかったり誤解を招きやすかったり、Twitterに買収されているTweetDeckにも問題があったりしたので、それはやっぱりTwitter側の責任の比重が大きいとは思う。とはいっても別に責任を追求したかったり◯◯はクソだといったことを言いたいわけではなく、誰が悪いとか言う以前に、複合的な要因によっ
yapcjapan2016_lt.md 5分でわかる Perl and web security ma.la CSRFとかXSSとか CSRF: フレームワークの機能使って下さい XSS: Xslateとか自動エスケープして下さい、jsの動的生成はするな 終わり 本題 YAPCなのでPerl固有の問題について解説します。 Webアプリケーションの一般的な流れ パラメータ受け取る(フォームとかJSONとか) 何らかの処理をする レスポンスを返す(HTMLとかJSONとか) フォームやJSONを安全に受け取るには paramはscalarで受け取りましょう Why $params = { name => $r->param("name"), value => $r->param("value"), } これをやると ?name=hoge&name=fuga で壊せる。 list context
e.md もう5年も前の話になっていたのだけど、Echofon(Twitterクライアントの一つ)の件を今更だけど書かねばならない。 https://subtech.g.hatena.ne.jp/mala/20120214/1329199851 https://subtech.g.hatena.ne.jp/mala/20120305/1330961228 https://twitter.com/bulkneets/status/176658152882831360 当時、Echofonのプッシュ通知を管理するサーバーの認証機能に欠陥があり(というか認証が無く) 他のEchofon利用者に対して送られるpush通知(DMやreplyなど)を横取りすることが出来た。 このセキュリティホール自体は素早く修正されたのだけど、この件をきっかけに、クライアント/サーバーの境界線が曖昧になっている、とい
gistfile1.md CVE-2016-7401 https://www.djangoproject.com/weblog/2016/sep/26/security-releases/ https://hackerone.com/reports/26647 pythonのcookie parserが ; 以外もpairsの区切り文字として解釈するので、google analyticsのreferrer経由でsetされるcookieを使ってCSRF tokenを上書き可能だったという問題。 django側でcookie parser自前で実装、python本体は直ってないようだ https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a 多くのcookie parserは、pairsの区
Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. アクセシビリティとオープンデータについて オープンデータや機械可読性こそがアクセシビリティやユーザビリティの向上につながるのだという話 概要 実際の事例を元にして、アクセシビリティとオープンデータについて述べる。 書きかけ、80%ぐらい。 前置き:「ことでん」へのツッコミとその後の対応 先週から書いているあれこれに関連して「ことでん」という鉄道会社に対してツッコミを入れた。対応がされたので、時系列での整理と、それに対する自分の見解を簡単に書く。 先週から書いてるあれこれ: https://gist.github.com/mala/08fdbc680d84bb1b2305688282f26cea 突然の社長への突撃に対
次のページ
このページを最初にブックマークしてみませんか?
『mala’s gists』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く