はてなブックマーク

English ver: https://gist.github.com/motoyasu-saburi/1b19ef18e96776fe90ba1b9f910fa714#file-lack_escape_content-disposition_filename-md TL;DR 1つのブラウザ、1つのプログラミング言語、15個の { Web Framework, HTTP Client ライブラリ, Email ライブラリ / Web Service 等} で脆弱性を見つけました。 見つけた脆弱性は、全て 1つの観点で発見した (多分 50-80 くらいのプロダクトの調査をした)。 RFC の記載では、（かなりわかりにくく）この問題に対する要件が記載されており、WHATWG > HTML Spec の方はしっかりと書かれているといった状況にある。 この問題は、 Content-Dispo

はじめに こん〜！ 今回は、いつかやろうと思っていた Meta(Facebook) 広告上でばら撒かれまくっている悪性広告を自動検出する試みについて、 うまくいったこと・いかなかったこと・考察等をまとめていこうと思います。 先にまとめ Facebook の GraphQL API だと、検索できる広告タイプが限られており、 Graph API を用いた自動化は（現在は）できない 広告ライブラリAPI という Web Page 機能 からの API サーチだと広告の検索が可能であり、悪性広告を検索可能 広告ライブラリAPI からの検索は、（多分）全文検索だと思われるので、特定のキーワード・ドメインをキーワードとした検索が可能 作成したカスタムクエリの一つは、検索結果の２０件が全て悪性広告であった 広告の先が悪性なECサイトであるかを判定する方法として、robots.txt を参照する方法を考

GitHub の Reverse Proxy 型フィッシングサイトの発見と報告 こんにちは、でじこだにょ 今回は GitHub を狙った Reverse Proxy 型のフィッシングサイトを探していこうと思います。 （長いので、Reverse Proxy 型のことをプロキシ型と略しちゃいます） 結論から書くと、２４件のフィッシングサイトを新規に発見して報告しました。 今回はそれらのフィッシングサイトの探し方のほか、フィッシングサイトの検出方法や、 セーフブラウジングなどの話をしつつ、 今回見つけたフィッシングドメインに対して、簡単ではありますが、調査と考察を行ってみたいと思います。 探そうとしたきっかけ 数日前、 Twitter を見ていたところ、こちらのツイートが流れてきました。 あっぶね GitHubだと思ったら全然違ったわ pic.twitter.com/SRtHUu3XDM— ./

はじめに 画像は記事に全く関係ないカニのフィギュアです👋 近年、善良なパッケージを騙ったマルウェアが配布されているケースが増えてきています。 これらのマルウェアはパッケージマネージャ上で配布され、開発者端末やそれをビルトインしたシステムを利用するユーザー端末で悪事を働きます。 これは俗にいうサプライチェーン型攻撃で、 これらの関連ニュースを目にする機会が増えてきていることを、多くの開発者が体感されていると思います。 ただ、これらのサプライチェーン型攻撃の記事は、 どうしてもエンドユーザー（パッケージを利用する開発者側・それらを組み込んだアプリを実行するユーザー側）の対策に焦点が当てられたものが殆どのように感じています。 そこで本記事では、このエンドユーザー側の対策だけではなく、 パッケージマネージャメンテナーたちがどう対策しているのかも含めて、 「パッケージマネージャ上で行われるマルウェ

GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話 ​ Githubが OSS Security Foundation に入りましたね。 大変興味深くて 関連するドキュメント なりについて会社のチームで雑談していたところ、 GitHubの「DependaBot」が何を狙い、どういう「大きな課題」を解決するのか？ という話において、点と点が結びついた感じがあるので言語化してみます。 「この大きな課題」を説明する前に Dependency Hell について国内で言及してる記事がそれほどないので その辺りをまずは書いていきます。 ここのあたりが国内の開発者の中でも認識が広まっていくと、より一歩先のステージにいくのかなと思うので、 比較的ラフな感じで書いていきます。 ​ ちなみに、このブログ記事は所属組織とかに関係なく個人で執筆しています。 なので1デベロッパーとして、

※ 2020/5/22 一部加筆 SASTとIterativeな開発の相性の悪さ 若干煽り気味なタイトルですが、チーム内で話していてなぜセキュリティ静的コード解析（Static Application Security Testing: SAST）と言ったセキュリティアプローチがDevOpsで回りにくいのかが言語化できた。 そもそも静的コード解析というアプローチによるセキュリティ担保は基本的に「教科書的なウォーターフォール型」において有効で、 理由としては「人月・工数」のみで考えられた「誰でもその作業ができ、セキュリティの知識がなくても良い」みたいな作業者の能力を考慮しないアプローチが基本だからである。 そう言ったアプローチだと「SASTのアラート全部直してくれな！そしたらセキュアだから！」という形に落とし込むことにより、 問題をある程度封じ込めれると。 ただ、これをDevOps、というよ

はじめに 本記事では、前回の記事（https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805）にてあまり触れられなかったWebアプリケーションにおけるDevSecOpsの所感や考え方、動向を個人的思想でまとめた記事になります。 本記事は個人の感想が多分に含まれているため、どこかしらで（何かしらに）寄った意見や 知識不足から来る誤った解釈などが含まれているかもしれません。 もし本記事で誤った箇所や違ったポリシー、事業のフェーズによって違う考え方を持たれている方がいらっしゃいましたら、是非コメントやリプライなどで意見をください。 というか、私自身が迷っている部分も多くあるため、そういった知見を頂けるのであればこの記事を書いた甲斐があるというものなので、是非是非フィードバックを・・・！ 本記事は章組をした段階であまりにもデカくになってしま

はじめに SAML関連で診断をすることになったが、やんわりとした知識しかないため、 SAMLの攻撃事例を読んでそれをざっくりまとめる。 認証フローなどはネットに軽い奴がまとまっているのでそれらを参考に読むと良いのかも？ ※2018/11/22 事例を1つ追加 ( XMLのコメントアウトを利用した認証バイパス の章) 思いつく攻撃 XMLをアップロードするのでそこでXML外部エンティティ参照とかがあるのかも？ あとはアプリケーション自体がXMLファイルからidP(Identity provider、所謂認証サーバ？)へ認証リクエストを送るから そこを利用してSSRFなどのイントラネットへのリクエストが送れるかも？ 上記２つはどちらかというと認証に対する攻撃とは別なので、認証部分の攻撃については 後述する事例で見ていく。 事例とざっくりまとめ SAML + HackerOne とかでググって引

セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか 自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。 新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。 ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。 本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になる