元祖 濱せっく#2
-
hori_yuta1118
- 3615
- 11
- 1
- 169
-
- いいね！169
rita
@hori_yuta1118
投稿間に合わないからその他ツールのURLを貼るからgithub勝手にみて！ github.com/jobertabma/rel… github.com/GerbenJavado/L… github.com/nahamsec/JSPar… Google Dorks #hamasec
2019-02-23 13:51:31
kusuwada
@kusuwada
ツール紹介 Sublist3r: とりあえずかけてみたりするやつ。サブドメインのリストを取得・一気にいろいろ調査してくれる。 tools.kali.org/information-ga… dirsearch: 見えちゃいけないディレクトリが見えてないかなど relative-url-extractor: jsにかかれている見つけづらいendpointなどの発見 #HamaSec
2019-02-23 13:52:54
kusuwada
@kusuwada
LinkFinder: 上記と似ている。ドメインに対して実施。相対パス・パラメータなどを列挙 JSParser: ほぼLinkFinderとおなじ。発見したendpointのjsの行を表示してくれるので便利 Google Dorks: Google検索時の検索演算子を使用することができる。domain, filetypeなどの指定に役立つ #hamasec
2019-02-23 13:53:16
rita
@hori_yuta1118
脆弱性診断されたあとのページとかがバグバウンティの対象になってることが多いので、簡単なXSSがみつかることは少ない。 #hamasec
2019-02-23 14:03:41
kusuwada
@kusuwada
本当は見つけたバグのwrite-upをしたかったが、企業から許可が降りなかったので今日は例をいくつか紹介。 最初はOpen Redirectの例。リダイレクト先を書き換えるやつ。 CTFやっていると派手な脆弱性や難しい脆弱性しかないんじゃないかと思ったりしたが、割と簡単な脆弱性もあったりする。 #HamaSec
2019-02-23 14:03:48
rita
@hori_yuta1118
ずっとツイッターしてるからCTFはこんな感じ #hamasec pic.twitter.com/dmzOGuNUKV
2019-02-23 14:06:01
拡大
8ayac
@8ayac
Writeupを制限するプログラム開催側の考え方もわかるけど、発見したバグのWriteupに協力的であるかどうかは、自分がバグバウンティに取り組む上で、重視したいポイントだなあ。 #HamaSec
2019-02-23 14:07:40
rita
@hori_yuta1118
バグバウンティのレポートはセキュリティ技術者が読むとは限らないので、セキュリティを知らない技術者でもわかるような内容にするべし #hamasec
2019-02-23 14:07:45
kusuwada
@kusuwada
次はXSS。工数不足で評価しきれていないこともあるので、DOM Based XSSなどを狙っていく。 今回はSSRFの例を紹介。エラーメッセージにDaemonのバナー情報が取れたり、メッセージの差異によってポートスキャンが成功しているか確認することもできる。 #HamaSec
2019-02-23 14:08:33
kusuwada
@kusuwada
バグバウンティの報告について、気をつけること。 ・自分が接されたい態度で接する ・報告したレポートがどのように感じられるか考える ・リスペクトが大切 ・開発者に向けて書く。読む人がセキュリティ技術者とは限らない #HamaSec
2019-02-23 14:09:22
rita
@hori_yuta1118
報告書例 1。Description ・どんな機能？ ・どういった脆弱性？ 2.Setp to REproduce ・1操作1手順がわかりやくす書く 3.Impact ・この脆弱性によって何が新開されるのかを説明する #hamasec
2019-02-23 14:12:03