Web脆弱性スキャナーをAIの力を借りて作って脆弱性を見つけてIPAに報告した

はじめに 起先

こんにちは。 你好。

最近、業務で脆弱性診断はほぼ行っておらず、プライベートでもバグバウンティしていない。微妙な脆弱性なのか判断しづらいものを報告したりはしているのだが、反応はない。
最近，我在工作中几乎没有做过漏洞评估，私生活中也没有做过任何 bug 赏金。 我报告了一些难以判断为微妙漏洞的事情，但没有得到回应。

何もしてないように見えるのも良くない気がしてきたので、プライベートで受理されやすそうな脆弱性を探して、IPAに報告しようかと思ったのだが、普通に探すのも面白くない。同じようなことをやる気はなかなか起きないのだ。
我觉得看起来什么都不做不是一个好主意，所以我想寻找私下里很容易接受的漏洞并向 IPA 报告它们，但正常寻找它们并不有趣。 很难有动力去做同样的事情。

何か目先を変えるべく、脆弱性スキャナーを使って探すことにした。Burp Proを使えばいいのだが、プライベートの一円にもならないもののために貴重な金は一円たりとも使いたくない。毎年のように報奨金をもらったお金でBurpのライセンスを買うと言ってたものの、結局一度も買わずじまいだ。
为了改变我的观点，我决定使用漏洞扫描程序来找到它。 我希望我可以使用 Burp Pro，但我不想把我宝贵的钱一分钱花在甚至连我的私生活一分钱都赚不掉的事情上。 他说他会用每年收到的钱买一个 Burp 许可证，但他从来没有这样做。

ということで、脆弱性を探すのに脆弱性スキャナーを自作してみることにした。車輪の再生産だ。すでにChatGPTに課金していたのでこれに働いてもらうことにする。
因此，我决定制作自己的漏洞扫描程序来查找漏洞。 它是轮子的复制品。 我已经给 ChatGPT 充值了，所以我要让它工作。

理由まとめ 原因总结

• Burpのライセンス高いじゃん Burp 的驾照很贵。
• nucleiはちょっと使いにくいしfuzzingが限定的にしかできないし改行挟んだ検知にバグがあるし（将来的にはこれでよくなる未来が来ると思うけど）
  Nuclei 有点难以使用，模糊测试有限，并且在检测换行符方面存在错误（尽管我认为这将在未来会变得更好）。
• ChatGPT頭良くなってきたじゃん ChatGPT 越来越聪明了，不是吗？
• できたら楽しそうじゃん 如果我能做到，那就太有趣了。

脆弱性スキャナーのターゲットとなる脆弱性と環境 漏洞扫描程序所针对的漏洞和环境

環境 环境

汎用性を求めるなら言語やサーバーに合わせたペイロードを書く必要があるが、とりあえず手元のテスト環境に合わせる。
如果你想要多功能性，你需要为语言和服务器编写有效负载，但暂时要根据手头的测试环境进行调整。

• Windows/Linux Windows/Linux 操作系统
• MySQL MySQL （MySQL的
• php 菲律宾语

脆弱性

機械的にレスポンスの解析で検出できるインジェクション系をターゲットにする。ターゲットは以下の通り。変なリクエストを送ると30xが返ることは意外と多いのでオープンリダイレクトって判定が意外と面倒な気がする。
机械地定位可通过响应分析检测到的注射系统。 目标如下。 如果你发送一个奇怪的请求，返回 30x 是出乎意料的普遍情况，所以我觉得判断开放重定向出奇的麻烦。

• XSS XSS （XSS）
• SQLi
• パストラバーサル 路径遍历
• RCE
• SSTI

大まかなスキャナーの設計 高级扫描仪设计

• ぼくのかんがえた Burp Proのスキャナー（とRepeaterとIntruder）の代替
  Burp Pro Scanner（以及 Repeater 和 Intruder）的替代品
• 今のところプロキシ機能は実装しない 我们暂时不会实现代理功能

アプリケーションのイメージ 应用程序图像

• Webアプリとして作る 创建为 Web 应用程序

アプリとして作る方がパフォーマンスはよさそうだけど、好みの問題
如果你把它做成一个应用程序，它似乎有更好的性能，但这是一个品味问题

動作の流れ 操作流程

• Webページからテストしたいリクエストを入力して、ボタンをクリックすると検査
  从网页输入要测试的请求，然后单击按钮进行检查
• htmlページのJavaScriptからWebAPIを叩く
  从 html 页面上的 JavaScript 点击 WebAPI
• WebAPIの言語は何でもいい  WebAPI 的语言可以是任何内容
  • とりあえずnodejsで実装してみる 让我们暂时尝试在 nodejs 中实现它

脆弱性の見つけ方のイメージ 如何查找漏洞的图像

• リクエストを送信して、レスポンスから脆弱性が疑われる挙動を見つける
  发送请求并在响应中查找可疑的易受攻击行为
  • レスポンスの内容（入力値が反射されているかとか） 响应的内容（例如，是否反映输入值）
  • レスポンスにかかる時間がどうかとか（遅延の発生） 回复（延迟）需要多长时间？
  • 状態遷移を見てるような面倒なアプリのことは今のところ気にしない
    我现在不关心麻烦的应用程序，比如观看状态转换。
  • 今のところペイロードに凝るよりは雑に検出して最後は手動で確認する仕様
    目前，它不是关注有效载荷，而是一个规范，可以粗略地检测它并在最后手动确认它
    • 本当に何かしたいならSQLMapとか使えばいいじゃん
      如果你真的想做点什么，你可以使用 SQLMap 什么的。

その他実現したいこと 我们想要实现的其他目标

• リクエスト/レスポンスの保存と再現ができるようにする
  允许保存和复制请求/响应
  • 思い出したときに再現確認したい 我想在我想起它时重现它。

これくらい。 就这么多了。

スキャナーの実装 扫描仪实现

早速実装する。 立即实施。

ChatGPTを使った実装 使用 ChatGPT 实现

私立文系卒のプログラマーでもないおじさんよりはChatGPTの方がよっぽどいいコードを書けるポテンシャルがあるので（常に書けるとは言ってない）、がんばってChatGPTに書いてもらうことにする。記載されたコードに間違いがあっても責任は取れない（動いてはいる）。だいたいのコードで使用したモデルはChatGPT 4oだが、アップデートされた後は一部o1を使っている。o1の方がいいものを高い確率で出してくる気がする。テストは手動。
ChatGPT 有可能写出比我叔叔更好的代码，他不是拥有私人文科学位的程序员（我并不是说它总是可以写的），所以我会尽我所能让 ChatGPT 写它。 我们不对代码中的任何错误负责（尽管它有效）。 大部分代码使用的模型是 ChatGPT 4o，但更新后，部分使用了 o1。 我觉得 O1 很有可能推出更好的。 测试是手动的。

前述の通り htmlページからWeb APIを呼び出す形式を取る。まずは、フロントのイメージをしつつAPI側を作成する。
如上所述，它采用从 html 页面调用 Web API 的形式。 首先，在创建 front 的镜像时创建 API 端。

リクエストとレスポンスに関連するAPI 与请求和响应相关的 API

基本となるリクエストの送受信と保存を行うAPI群を作る。変な改変が行われず、思った通りのリクエストを送信してレスポンスを受信することを目標とする。
创建一组用于发送、接收和存储基本请求的 API。 目标是按预期发送请求和接收响应，而无需任何奇怪的修改。

リクエストとレスポンスを行うAPI（/api/request）
用于发出请求和响应的 API （/api/request）

まず基本として http/httpsのリクエストを送受信するAPIを作る。作るとは書いているが、いいものができるように祈りつつ作ってもらう（以下全て同じ）。ヘッダ、ボディを全て含むHTTPリクエストを丸ごと送って、レスポンスを受け取るAPIだ。
首先，创建一个 API 来发送和接收 http/https 请求。 我写下我会成功，但我会请求你成功，同时祈祷它会好起来（下面都一样）。 它是一个 API，用于发送整个 HTTP 请求（包括所有标头和正文）并接收响应。

当初、nodejsで実装していたが、簡単に使えるhttp系のライブラリではクエリストリングの値がURLエンコードされるので断念。Pythonを使うことに。もう少し低レイヤーを直接触ればいいみたいだが、そこまでnodejsにこだわる理由もない。フレームワークにはflaskとflask_sqlalchemyを使っているが、ChatGPTに従ったまでだ。
最初，它是在 nodejs 中实现的，但已被放弃，因为查询字符串的值在易于使用的 http 库中进行了 URL 编码。 我决定使用 Python。 更直接地接触较低层会很好，但没有理由如此坚持 nodejs。 它使用 flask 和 flask_sqlalchemy 作为其框架，但甚至遵循 ChatGPT。

conn = http.client.HTTPSConnection(host, context=context)

Pythonだとhttp.client.HTTPSConnectionを使って普通に接続するだけでURLエンコードされず送信される。
在 Python 中，只需使用 http.client.HTTPSConnection 正常连接即可发送，无需 URL 编码。

オプション 选择

• プロキシ経由するオプション 选择通过代理
• 保存オプション 保存选项

プロキシ経由でのアクセスの場合は 要通过代理进行访问，请使用

conn = socket.create_connection((proxy_host, proxy_port))
target_port = 443 if protocol == "https" else 80  # Determine port based on protocol
conn.sendall(f"CONNECT {host}:{target_port} HTTP/1.1\r\nHost: {host}\r\n\r\n".encode())

みたいにCONNECTメソッドを叩く必要がある。テストで使っただけなのでバグが残存しているかもしれないが、結局デバッグ以外でアップストリームのプロキシを通することはないのであまりプロキシを通す機能は必要ないかもしれない。面倒なので接続先は 127.0.0.1:8080 固定にしている。
您需要像那样点击 CONNECT 方法。 由于我只是用它来测试的，所以可能会留下一些 bug，但最后除了调试之外，我不会经过上游的 proxy，所以我可能不需要那么多通过 proxy 的能力。 由于比较麻烦，连接目的地固定为 127.0.0.1：8080。

保存オプションは作らず、別のAPIを作った（後述）。
我没有创建保存选项，而是创建了一个单独的 API（见下文）。

その他の機能 其他功能

• Content-Length の再計算

POSTリクエストのbodyを変更した際、Content-Lengthを合わせる必要があるが、今のところリクエストを変形させる方のAPIで再計算を行っている。API側で再計算させるオプションがあった方がいいかもしれない。
当 POST 请求的正文发生更改时，必须匹配 Content-Length，但现在它由转换请求的 API 重新计算。 在 API 端有一个重新计算的选项可能会很好。

• gzip圧縮の展開 扩展 gzip 压缩

一応実装した。 我暂时实现了它。

ここまで書いて何ではあるが、リクエスト/レスポンス部分はわざわざ自力でがんばらなくても、実績のあるcurlとか使えばいいような気がする、まあ、いいじゃない。
我不知道到目前为止我写了什么，但我觉得我可以使用经过验证的 curl 或类似的东西，即使我懒得自己做请求/响应部分，嗯，这很好。

リクエストとレスポンスを保存するAPI（/api/save）
用于保存请求和响应的 API （/api/save）

リクエストAPIに保存オプションを付ければ良かっただけのような気がするけど、動作確認のときわかりやすくしたかったので分割した。パフォーマンスを考えるとお勧めはしない。
我觉得我应该在请求 API 中添加一个保存选项，但我想在检查操作时更容易理解，所以我把它分开了。 考虑到性能，我不推荐它。

機能としては /api/requestのリクエストとレスポンスと実行時間を保存して、UUIDを返す。リクエストにすでにあるUUIDを含めると上書き保存するようにしている。これによって編集もできることになりいろいろ便利になった気がする。
该函数是保存 /api/request 的请求、响应和执行时间，并返回 UUID。 如果您在请求中包含现有 UUID，它将被覆盖。 这使得编辑成为可能，这使其在许多方面更加方便。

実際はJavaScriptによって、画面の保存オプションにチェックが入っている場合だけ、保存APIにアクセスすることになる。
事实上，只有在选中 save screen 选项时，JavaScript 才会访问保存 API。

保存されたリクエスト/レスポンスを取得する（/api/load/uuid/）
获取存储的请求/响应 （/api/load/uuid/）

/api/save APIで保存したリクエストを呼び出すAPI。リクエストとレスポンスと実行時間が返る。
/api/save 中 一个 API，用于调用 API 保存的请求。 返回 Request、response 和 execution time。

別途、全リクエストを取得する /api/load/all APIも作っているがデバッグ用で実際には使ってはいない。
另外，我创建了 /api/load/all API 来获取所有请求，但它用于调试，并未实际使用。

この3つを実装したことでrepeaterの実現が可能になる。
通过实现这三个，可以实现中继器。

Intruder 侵入者

フロントのJavaScriptをがんばって書けばIntruderの実装も可能だが（軽く実装はした）、これだけではいろいろ面倒だったのでとりあえず先送りにした。それっぽいAPIを作ったので（後述）そっちを使った方が手堅いと思う。
如果你尽最大努力编写前面的 JavaScript，你可以实现 Intruder（我轻描淡写地实现了它），但光是这个就很麻烦，所以我暂时推迟了。 我已经创建了一个这样的 API（见下文），所以我认为使用它更可靠。

複数のリクエストをひとまとめにして扱うためのAPI
用于一次处理多个请求的 API

今回行いたい脆弱性スキャンのためには、元のリクエストからさまざまな改変を行ったリクエストを送信する必要がある。
为了执行我们这次想要进行的漏洞扫描，我们需要发送一个请求，其中包含对原始请求的各种修改。

元のリクエストが 如果原始请求是

http://localhost/test.php?key=value

だとすると 如果是

http://localhost/test.php?key="><s>
http://localhost/test.php?key='||'

のようなリクエストを作成し、その結果を取得し、結果について考察するという流れになる。
流程是创建这样的请求，获取结果，然后考虑结果。

毎回作成して送信してもいいのだが、途中で止めることや、再送することを考えるとちょっとそれはやりたくない。
你可以每次都创建并发送它，但我不想这样做，因为我考虑在中间停止它或重新发送它。

ということで、この元のリクエストとペイロードを付与したリクエストをリクエストリストとしてひとまとめにして扱えるようにしたい。偉そうに書いてるが、まとめるだけだ。
因此，我希望能够将这个原始请求和带有有效负载的请求作为一个请求列表来处理。 我写得很宏大，但我只是想总结一下。

ここからはそのような複数リクエストをリストとして扱うためのAPIを作成する。
从这里，我们将创建一个 API 来处理列表形式的多个请求。

リクエストを作成されたリストに追加するAPI （/api/request-list/add）
用于将请求添加到已创建列表的 API （/api/request-list/add）

まず、リクエストを指定されたリストに追加するAPIを作成する。リクエストを保存した際にUUIDが付与されているが、そのUUIDとリスト名を指定すると、リクエストがリストに追加されていく。
首先，创建一个 API，将请求添加到指定列表。 保存请求时会分配 UUID，但如果指定了 UUID 和列表名称，则请求将被添加到列表中。

追加だけでなく、以下のAPIもそれぞれ実装した。偉そうに書いてるけど、やってることはUUIDを追加編集削除してるだけだ。
除了添加之外，还实施了以下 API。 这听起来不错，但我所做的只是添加、编辑和删除 UUID。

• リストに追加されたリクエスト一覧の取得（/api/request-list/<list_name>）
  获取添加到列表中的请求列表 （/api/request-list/<list_name>）
• リクエストの編集（/api/request-list/edit/<uuid>）
  编辑请求 （/api/request-list/edit/<uuid>）
• 削除（/api/request-list/delete/<uuid>）

モデルは以下のようになっている。 模型如下。

class RequestList(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    uuid = db.Column(db.String(36), unique=True, nullable=False, default=str(uuid4()))
    list_name = db.Column(db.String(100), nullable=False )
    requests = db.relationship('SavedRequest', backref='request_list', lazy=True)
    created_at = db.Column(db.DateTime, default=datetime.utcnow)
    modified_at = db.Column(db.DateTime, default=datetime.utcnow)

これで、脆弱性を探すためのリクエストを格納できるようになった。
现在，您可以存储请求以查找漏洞。

リクエストに脆弱性を見つけるためのペイロードを貼り付けるためのAPI群
用于粘贴有效负载以查找请求中的漏洞的 API

1つのリストに複数のリクエストを格納できるようになったが、今のところ1つのリクエストしか扱っていない。
现在可以将多个请求存储在单个列表中，但到目前为止它只处理一个请求。
ここからはこの1つのリクエストに対して、脆弱性を検出するためのペイロードをさまざまな場所に付与するAPIを作成する。
从这里开始，我们将创建一个 API，该 API 提供有效负载来检测此请求在不同位置的漏洞。

http://localhost/test.php?key=value&key2=value

を

http://localhost/test.php?key="><s>1</s>&key2=value
http://localhost/test.php?key=value&key2="><s>1</s>
http://localhost/test.php?key="+"&key2=value
http://localhost/test.php?key=value&key2="+"

のように複数のリクエストに最終的には増殖させるイメージだ。
这是一个最终将成倍增加为多个请求的映像。

リクエストにマークを付けるAPI（/api/mark-request-list）
标记请求的 API （/api/mark-request-list）

まずは、ペイロードを付与する場所を自動で決めるAPIを作る。
首先，创建一个 API 来自动确定将有效负载附加到何处。

BurpのIntruderでAuto§ボタンをクリックすると
当您单击 Burp’s Intruder 中的 Auto§ 按钮时

GET /xsssample/xss-showcase-001.php?word=§test§ HTTP/2

のようにマークが付けられるが、同じことを実現する。具体的には、リクエストの =を探して値の方に§§を付ける処理を行う。保存されたUUIDが返る。のでそれを参照すると元にリクエストに§§が付いたリクエストが見えることになる。
但实现同样的目标。 具体来说，它在请求中搜索 = 并将 §§ 添加到值中。 返回保存的 UUID。 因此，如果您引用它，您将在原始请求中看到带有 §§ 的请求。

マークをペイロードに置き換えるAPI（/api/replace-marks）
用于将标记替换为有效负载的 API （/api/replace-marks）

次に、この§§マークが付いた箇所を脆弱性検出用のペイロードに置き換えるAPIを実装する。
接下来，实施一个 API，将此 §§ 标记替换为用于漏洞检测的有效负载。

http://localhost/test.php?key=§value§

を

http://localhost/test.php?key="><s>1</s>
http://localhost/test.php?key="+"

のように機械的に置き換えるだけだ。 只需机械地更换它。

置き換えたいリクエストのUUIDを指定すると、置き換えたリクエストを指定されたリストに保存する。リストの指定がない場合は新規に作成される。ペイロードとなる文字列は指定した辞書ファイルから読み込ませている。
当指定了需要替换的请求的 UUID 时，被替换的请求将保存在指定的列表中。 如果未指定列表，则会创建一个新列表。 成为有效负载的字符串是从指定的字典文件中读取的。

bodyは普通のapplication/x-www-form-urlencodedだけでなくmultipart/form-dataとapplication/jsonにも対応しているはず。
正文不仅 application/x-www-form-urlencoded 应支持 normal，还应支持 multipart/form-data 和 application/json。

この2つのAPIで、脆弱性を探すためのリクエストを作成することが可能となる。
使用这两个 API，可以发出请求以查找漏洞。
実際にはJavaScriptで、フォームに入力してボタンをクリックすると連続してAPIが呼び出されて、脆弱性を探すリクエストが準備されるようになっている。
事实上，它是 JavaScript，当您填写表单并单击按钮时，将连续调用 API 以准备查找漏洞的请求。

これによりIntruder的なことも可能になるはず。
这应该可以做类似 Intruder 的事情。

脆弱性を判定するためのAPI群 用于确定漏洞的 API

脆弱性を見つけるためのリクエストを作成したので、このレスポンスから脆弱性を見つけるための処理を行うAPIを作成する。
由于已创建查找漏洞的请求，因此会创建一个 API，该 API 执行一个过程以从此响应中查找漏洞。

以下の2つを作った。他の判定が必要になったら随時追加する。
我做了以下两个。 将根据需要添加其他判断。

リクエストの内容に検索語が含まれているかチェック（/api/check-response-words）
检查请求内容是否包含搜索词 （/api/check-response-words）

このAPIではXSSの判定のように送信したワードがそのままレスポンスに表示されるような、レスポンスから機械的に判定できるものを想定している。単純にレスポンスに辞書のワードが含まれていたり、passwdファイルの中身のような文字列があったり、計算結果と思しき数字があったりすると脆弱性の疑いありという報告を行う。
在这个 API 中，假设发送的单词在 Response 中原样显示，就像 XSS 判断一样，可以从 Response 中机械地确定。 如果响应仅包含字典单词、类似于 passwd 文件内容的字符串或似乎是计算结果的数字，则会将其报告为可疑漏洞。

実行時間を比較するAPI（/api/compare-executiontime）

UUIDを2つ入力すると、それぞれの実行時間を比較してくれる。差があれば脆弱性の疑いがあるという見立てだ。RCEやSQLインジェクションを雑にタイムベースで検出することにしたのでこれを使う。
如果您输入两个 UUID，它们将比较每个 UUID 的执行时间。 如果存在差异，则怀疑存在漏洞。 我决定在粗略的时基上检测 RCE 和 SQL 注入，因此我将使用它。

リクエストリストをひとまとめにしてプロジェクトとして扱うAPI群
对请求列表进行分组并将其视为项目的 API

ここまでで1つのリクエストに対して、脆弱性を検出するためのペイロードを付与した複数のリクエストを作成し、指定のリストに保存する処理を行うことができるようになった。
ここからはその複数リクエストリストをプロジェクトとしてひとまとめにするAPIを作る。

先ほどは

http://localhost/test.php?key=value

のような1つのリクエストにペイロードを展開したものをひとまとめにしたが、ここでは

http://localhost/test.php?key=value
http://localhost/test/test.php?key=value
http://localhost/user?id=1

のような複数の別のURL（とペイロードを展開したもの）をひとまとめにするイメージだ。これで1アプリのURL一覧を1プロジェクトとして縦断的にまとめるようなことを期待している。別に制限してないのでどんなドメインでもいいんだけど。
它是多个不同 URL（和有效负载）组合在一起的映像。 我希望这将是一个应用程序的 URL 列表作为一个项目的纵向编译。 我没有任何限制，所以任何域都可以。

構造としてはこんなかんじで非常にシンプル。 结构非常简单，像这样。

class Project(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100), unique=True, nullable=False)
    requests = db.relationship('ProjectRequest', backref='project', lazy=True)
    created_at = db.Column(db.DateTime, default=datetime.utcnow)
    modified_at = db.Column(db.DateTime, default=datetime.utcnow)

ここでは 这里

• プロジェクト作成API（/api/project）
  项目创建 API （/api/project）

• プロジェクトの情報を更新するAPI（/api/project/update_request_id）
  用于更新项目信息的 API （ /api/project/update_request_id ）

• プロジェクトに入っているリクエストリストを取得するAPI（/api/project/<project_name>）
  用于获取项目中请求列表的 API （/api/project/<project_name>）

• プロジェクトからリクエストリストを削除するAPI（/api/project/remove_request）
  移除项目请求列表的 API （/api/project/remove_request）

を作成した。 创建。

これを組み合わせることで複数のリクエストに対し、脆弱性を見つけるペイロードを貼り付けたリクエストを準備して、実行し、その結果を取得することが可能となった。
通过组合此操作，可以准备并执行粘贴了有效负载的请求，以查找多个请求的漏洞，并获得结果。

将来的な展開としては、ここで集めたリクエストに対して横断的に何かするみたいなことも考えてはいる。
至于未来的发展，我们正在考虑做一些跨部门的事情来回应这里收集的请求。

そういえばまだ認証とかセッション管理とかしてないが、一人で使うものなので必要ないか。
仔细想想，我还没有做过身份验证或会话管理，但因为它是针对一个人的，所以我不需要它。

フロントの作成 创建 Front

最後にこれらのAPIを使うためのフロントエンドのことを書く。時系列としてはAPIを作っているときに同時に作って追加修正を繰り返しているが、最終的にできあがったものについて書く。htmlとjavascriptを使っている。デザインするのが面倒なのでフレームワークにbootstrapを使っている。そしてjQueryが使われているが、これはモーダルダイアログのためにChatGPTが勝手に使っていた。今のところ画面は以下の通り。3つしかない。シンプルだ。どのAPIを使っているのかは、上の文章を見て想像してほしい。
最后，我们将介绍使用这些 API 的前端。 按照时间顺序，我在创建 API 的同时创建了它并重复了额外的修改，但我会写关于最终产品的文章。 它使用 HTML 和 JavaScript。 设计起来很麻烦，所以我使用 bootstrap 作为框架。 并使用 jQuery，ChatGPT 将其用于模态对话框。 目前，屏幕如下所示。 只有三个。 这很简单。 您可以通过查看上面的文本来想象您正在使用哪个 API。

プロジェクトの管理ページ（project） 项目管理页面 （project）

プロジェクト名でプロジェクトの情報を呼び出すか新規に作成するページ。基本ここから開くのでindexにすればよかった。
按项目名称调用项目信息或创建新项目的页面。 基本上，它从这里打开，所以我应该将其设置为 index。

ボタンをクリックするとモーダルダイアログが開き、1つずつURLかリクエストを入力してボタンをクリックすると、脆弱性検出用のペイロードが付与され展開され保存され、タイルとして表示される。読み込む辞書も指定はできるようになっている。
单击该按钮时，将打开一个模式对话框，当您逐个输入 URL 或请求并单击该按钮时，将提供、展开、保存并显示为磁贴的漏洞检测有效负载。 您还可以指定要加载的词典。

画面はこのようになっている 屏幕如下所示

追加された後はこんなかんじ。各タイルをクリックするとリクエストの内容が読める。リクエストを修正して保存することもできる。
添加后，它看起来像这样。 单击每个磁贴以阅读请求的内容。 您还可以修改并保存请求。

脆弱性を探すページ（list） 搜索漏洞 （列表）

テストボタンをクリックすると、脆弱性を探すページが開く。やってることはペイロードが付与されたリクエストを順番に並べている。「Execute Request」ボタンをクリックするとリクエストが送受信される。デフォルトでは1秒ごとに送信され、終わるとボタンの色が変わる。
单击 test 按钮将打开一个查找漏洞的页面。 我们正在做的是用有效负载对请求进行排序。 点击 “执行请求” 按钮以发送和接收请求。 默认情况下，它每 1 秒发送一次，按钮的颜色在结束时会发生变化。

ボタンをクリックするとリクエストとレスポンスの詳細が表示される
单击 按钮可查看请求和响应详细信息

脆弱性が見つかると、ここに表示される。 如果发现漏洞，它们将在此处显示。

リクエストの送受信を行う （repeater） 发送和接收请求 （repeater）

list画面の各リクエストにあるrepeaterリンクをクリックするとリクエストを再送できるrepeater画面が開く。
单击列表屏幕上每个请求中的转发器链接以打开转发器屏幕，您可以在其中重新发送请求。
別のページだが、リクエストを追加する画面と基本的に違いはない。入力欄に入ったリクエストを実行して、リクエストとレスポンスと実行時間を表示する。
这是一个不同的页面，但它基本上与用于添加请求的屏幕相同。 在输入字段中执行请求，并显示请求、响应和执行时间。

脆弱性の発見と報告 漏洞发现和报告

自分のXSS再現ページなどで動作確認してXSSを検出することができたので、当初の目的である、オープンソースのWebアプリケーションの脆弱性を探すことにする。
由于我能够通过检查我的 XSS 复制页面上的操作等来检测 XSS，因此我决定在开源 Web 应用程序中寻找漏洞，这就是最初的目的。

初手として、去年脆弱性を見つけてIPA経由で報告し、すでに修正が行われたWebアプリケーションがあるのでこれを動作確認も兼ねてテストすることにした。
作为第一步，我去年发现了一个漏洞并通过 IPA 报告了它，由于我已经有一个已修复的 Web 应用程序，因此我决定对其进行测试并检查操作。

ツールはわりと予想通りに動いており、ちゃんと動いて良かったなあと思いつついくつかのURLをテストしていると、怪しいパラメーターを持つURLがある。ツールを実行すると、早速脆弱性が見つかってしまった。単純な脆弱性だったので、単純なペイロードで見つかった。
该工具按预期工作，在测试一些 URL 的同时认为它工作正常时，存在参数可疑的 URL。 当我运行该工具时，我立即发现了一个漏洞。 由于它是一个简单的漏洞，因此它是通过一个简单的有效负载发现的。

作るのはわりと時間がかかっているのに、あっさり見つかってしまい拍子抜けしてしまった。
花了很长时间才完成，但我很容易被找到，我被震撼了。

とりあえずIPAに報告すると、一昨日受理された連絡が来た。修正されるとIPAのページで公表されるので、詳細はそれまで待ってほしい。
无论如何，当我向 IPA 报告时，我收到了一条通知，说它在前天已被接受。 修复后，将在 IPA 页面上公布，因此请等待那时了解详细信息。

あっさり終わって良くなかったようなモヤモヤとした気持ちはあるが、ひとまずこれについては終了。少し休憩して、やる気が復活すれば機能を追加したり、改良したりするかもしれない。
我有一种令人沮丧的感觉，这么容易就结束并不好，但我暂时已经受够了。 短暂休息后，如果动力恢复，我们可能会添加或改进这些功能。

今後拡張するには 将来如何扩展？

今のところ手を動かす気力が湧かないが、このへんあったら便利かもなあということを書く。
我现在没有精力移动我的手，但我会写下来，如果我有这个可能会有用。

プロキシ機能 代理功能

burpの代替といいつつ設定する元のリクエストをburpから取得しているという根本的な問題があるので、リクエストを取得する手段を実装する必要がある。
由于存在一个根本问题，即要设置的原始请求是从 burp 获得的，同时是 burp 的替代品，因此有必要实现一种检索请求的方法。

• Chromeの拡張  Chrome 扩展程序
  • そんなに難しくはないのでやる気の問題 这并不难，所以这是一个动力问题
• pythonで実装  用 Python 实现
  • mitmproxyをimportすれば超簡単 如果你导入 mitmproxy，那就超级容易了
• mitmproxyを使う  使用 mitmproxy
  • これでいいのでは or ZAP使う 这不是可以的还是使用 ZAP

入力の拡充 输入增强

• ヘッダを追加する 添加标头

X-Forwarded-Host ヘッダとか追記して送信することで脆弱性を見つける方法もある。フロントエンドで対応可能だけどAPI作ってもいいかも。
还有一种方法可以通过添加 X-Forwarded-Host 标头并发送来查找漏洞。 它可以由前端处理，但创建 API 可能没问题。

• パラメーター側もにペイロード 参数端也在 payload 中

parama=dataでdata側にしかペイロードを貼り付けてないのでパラメーター側に追記するとかパラメータを配列にするとかもできた方がいい
由于 payload 只是用 parama=data 在数据侧粘贴的，所以最好将其添加到 parameter 端或者将参数做成数组。

• Mass Assigment 大众分配

プロジェクトで送信パラメーターを全部覚えてて、追加するとかはできそう
看来可以记住工程中的所有传输参数并添加

脆弱性検出のロジック拡充 扩展的漏洞检测逻辑

今のところ単純なペイロードと単純な検出ロジックしか書いてないので、見つかる脆弱性も限定されている。世の中で見つかる脆弱性の多くはこのような単純なペイロードでも見つかるものだとは思うが、もう少し踏み込む必要はある。
到目前为止，我们只编写了一个简单的 payload 和简单的检测逻辑，这限制了我们发现的漏洞。 我敢肯定，世界上发现的许多漏洞都可以通过如此简单的有效负载找到，但我们需要更进一步。

• 今のところオープンリダイレクトすら見つけられない 到目前为止，我什至找不到开放的重定向
• 埋めこみXSSとかセカンドオーダーSQLインジェクションとか入力と発現が異なるケースはまったくダメ
  输入和表达式不同的情况，例如嵌入式 XSS 或二阶 SQL 注入，根本不好。
  • 前後のリクエストの比較やステップを踏む必要があるものに対応する必要
    请求前后比较，需要响应需要采取的步骤
• MySQL以外のSQLサーバーに対応していない 它不支持 MySQL 以外的 SQL 服务器。

ここを深掘りするのがプロっぽい気がするが、仕事じゃないのでモチベーションが全く湧かない
我觉得在这里深入挖掘很专业，但这不是我的工作，所以我根本没有任何动力

まとめ 总结

作成に3ヵ月かかって、一瞬で脆弱性が見つかった。一応形にはなったのでよかったが、ターゲットの選定を間違ったとも言える。もうちょっと探す方でも試行錯誤したかった。
创建耗时三个月，瞬间发现了漏洞。 我很高兴它暂时成型，但可以说目标的选择是错误的。 我想多做一点试错，即使我正在寻找它。

結局のところプライベートでスキャナーを使ってゴリゴリ脆弱性を探すような習慣がないので、1つ脆弱性を見つけると満足してしまった。作ってる過程が楽しかったのでいいか。
毕竟我没有私下用扫描程序找漏洞的习惯，所以发现一个漏洞就很满足。 我喜欢制作它的过程，所以没关系。

SNSによると、コードはプロンプトを書くだけでAIが作ってくれるらしいので、誰でも簡単にこれと同じような脆弱性スキャナーを作れると思う。なのでここではコードは公表しない。
根据 SNS 的说法，代码是由 AI 通过编写提示创建的，所以我认为任何人都可以轻松创建这样的漏洞扫描程序。 因此，我不会在此处发布代码。

業務とは全く関係ない個人的な取り組みなので、会社に問い合わせたりするのは本当に勘弁してほしい（二回目）。
这是与工作无关的个人倡议，所以我真的希望你小心联系公司（第二次）。
個人的に問い合わせていただくのは大歓迎だが、電話には出ない。
欢迎您亲自与我们联系，但不要接听电话。