webgoat靶场攻关

A（5） Broken Access Control

Insecure Direct Object References

直接对象引用
直接对象引用是指应用程序使用客户端提供的输入来访问数据和对象。

例子
使用 GET 方法的直接对象引用示例可能如下所示

https://some.company.tld/dor?id=12345

https://some.company.tld/images?img=12345

https://some.company.tld/dor/12345

其他方法
POST、PUT、DELETE 或其他方法也可能容易受到影响，主要仅在方法和潜在有效载荷上有所不同。

不安全的直接对象引用
当引用未得到正确处理时，这些被认为是不安全的，并允许授权绕过或披露可用于 执行用户不应能够执行或访问的操作或访问数据。 假设作为用户，您去查看您的个人资料，URL 如下所示：

https://some.company.tld/app/user/23398

…您可以在那里查看您的个人资料。如果导航到以下位置，会发生什么情况：

https://some.company.tld/app/user/23399…​或在末尾使用另一个数字。如果您可以操作数字（用户 ID）并查看他人的配置文件，则对象引用是不安全的。 当然，这可以检查或扩展到 GET 方法之外，以查看数据，也可以操作数据。

更多好读物
在我们继续练习之前，这里有一些关于不安全的直接对象引用的好读物：

https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_（OTG-AUTHZ-004）

https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control

https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

http://cwe.mitre.org/data/definitions/639.html

先进行身份验证，后滥用授权
许多访问控制问题容易受到经过身份验证但未经授权的用户的攻击

0x02

直接使用tom cat登录

0x03

页面上没显示的属性是role和userid

0x04

填写为WebGoat/IDOR/profile/2342384 提交，意思是直接使用userid就可以查询该id的信息。
如果知道了其他用户的id，那就也可以查询信息了。
在restful风格中，提供使用同样的url，不同的方法来进行处理，可以利用这样的模式，比如修改方法，传body，看能否对某些属性做出修改。

安全的對象引用

1、要有权限控制文档。
2、水平和垂直权限控制，通常我们使用角色来进行权限控制，但是同样角色的用户，也可能获取到其他用户的信息，这就是水平权限，也需要进行控制。
3、审计。权限控制规则应该包括哪些操作应该被记录下来，如超级用户或者管理员修改了其他人的信息，应该有日志记录。
另外试图破坏权限控制机制的操作也应该记录下来。
4、使用间接引用。这个的方法用的比较少，可以hash，编码或者其他的方法，使客户端看到的id不是真实的引用对象，
这会降低一些处理效率，但是也容易被猜测，暴力破解，或者反编译。
5、权限控制API 如 JSON Web Tokens (https://jwt.io和Secure Token Binding

Missing Function Level Access Control

0x02

这节告诉我们，不要在html中隐藏不用的功能，可能会被利用。

A(7)

0x07

直接点击提交，发现页面显示了credit card，说明可能存在注入。
在credit card输入框输入 ，点击purchase，显示了alert。

A（8）不安全的反序列化

反序列化是将已序列化的数据还原回对象的过程。然而，如果反序列化是不安全的，那么恶意攻击者可以在序列化的数据中夹带恶意代码，从而在反序列化时执行这些代码。这种攻击被称为反序列化漏洞。

反序列化漏洞可能会导致许多问题，例如执行恶意代码、绕过身份验证、读取敏感数据等。因此，编写和使用安全的序列化和反序列化代码非常重要。

为了避免反序列化漏洞，应该尽可能使用基于文本的格式，例如 JSON 和 XML，而不是二进制格式。 对于二进制格式，应该在反序列化时验证输入，仅接受预期的数据，并对输入进行严格的检查和限制。 另外，最好使用现有的安全的序列化库来保证实现的正确性。

A（9）易受攻击的组件

我们的软件中包含了开源软件，这些开源软件可能存在漏洞！也就是漏洞不一定存在于我们自己写的代码中。
组件无处不在，webgoat就用了数百个组件，开发人员应该如何在数百个组件中跟踪这些信息？

了解OSS“物料清单”是起点

现代应用程序由自定义代码和许多开源部分组成。开发人员通常非常了解他们的自定义代码，但不太熟悉他们使用的库/组件的潜在风险。将物料清单视为配方中的成分列表。

我们应该知道答案的问题：
我们如何知道我们的应用程序中有哪些开源组件？

我们如何知道我们正在使用什么版本的开源组件？

我们如何定义开源组件的风险？

我们如何发现开源组件的风险？

我们如何将特定风险与开源组件的特定版本相关联？

我们如何知道组件何时发布新版本？

我们如何知道是否在以前的“良好”组件上发现了新的漏洞？

我们如何知道我们是否在使用开源组件的真实版本？

可以使用工具来生成组件清单。

0x12

关于漏洞 CVE-2013-7285

总结

现代应用程序中的开源消费有所增加。
开源是从许多具有不同质量标准的不同存储库中获得的。
有关漏洞的安全信息散落在各处。
许可证信息通常难以验证。
大多数团队没有组件升级策略。
开源组件是新的攻击媒介。

应采取的措施

生成 OSS 物料清单。
使用自动化工具 http://lmgtfy.com/?q=OSS+bill+of+materials
组织中的开源使用基线。
制定开源组件风险管理策略，以减轻当前风险并降低未来风险（华为对开源组件都会进行统一管理）

(A8:2013) Request Forgeries

Cross-Site Request Forgeries

跨站请求伪造，又称一键攻击或会话骑乘，简称CSRF （有时发音为 sea-surf）或 XSRF，是一种恶意利用网站，其中传输未经授权的命令 来自网站信任的用户。与跨站点脚本 （XSS） 不同，XSS 利用用户对特定站点的信任，CSRF 利用网站对用户浏览器的信任。
这是最简单的 CSRF 攻击。例如，您会收到一封电子邮件，其中包含以下内容：

View my Pictures!

如果用户仍然登录到 bank.com 的网站，这个简单的GET请求会将资金从一个账户转移到另一个账户。 当然，在大多数情况下，网站可能很多控制来限制这样的请求

框架支持xsrf

大多数框架现在都默认支持防止 CSRF。例如，在 Angular 中，默认情况下，拦截器会从 cookie 中读取 XSRF-TOKEN，并将其设置为 HTTP 头 X-XSRF-TOKEN。由于只有运行在您的域上的代码才能读取 cookie，因此后端可以确定 HTTP 请求来自您的客户端应用程序，而不是攻击者。

为了实现此功能，后端服务器在cookie中设置令牌。由于cookie的值应该由Angular（JavaScript）读取，因此此cookie不应标记为http-only标志。在每次向服务器发出请求时，Angular会将令牌作为HTTP标头放入X-XSRF-TOKEN中。服务器可以验证这两个令牌是否匹配，这将确保服务器上的请求运行在相同的域上。
（服务端给请求发token，并将token存放在cookie上，客户端请求时需要带上token，攻击者不知道token，当然就无法请求。）

custom header是不安全的

另一种防御措施是在每次调用中添加自定义请求标头。如果与服务器进行的所有交互都是用JavaScript执行的，这将起作用。在服务器端，您只需检查是否存在此标头，如果不存在，则拒绝请求。一些框架默认提供此实现，但研究人员Alex Infuhr发现，此实现也可以被绕过。

0x03

点击提交按钮，看到接口，修改请求头中的referer字段（相当于从其他网站向目标请求发送请求），发送请求，获得flag。

0x07

<form name="attack" enctype="text/plain" action="http://10.100.33.188:8080/WebGoat/csrf/feedback/message" METHOD="POST">
<input type="hidden" name='{"name": "Testf", "email": "[e-mail]", "subject": "service", "message":"' value='dsaffd"}'>
</form>
<script>document.attack.submit();</script>

新建文件a.html如上，提交到wold中，然后访问wolf该文件对应的url。


原理是请求wolf返回的html，向webgoat发送了请求提交了表单。该请求的origin和referer都是wolf的地址，所以实现了跨域请求。

Login CSRF attack

攻击者使用自己的账户，让用户登录，然后收集用户在网站上操作的活动。

0x08

注册个csrf-开头的用户，比如我的用户名为tntaxin，然后我再注册一个csrf-tntaxin,然后登录csrf-tntaxin访问这道题目，点击solved就过了，当然这题的真实目的是希望你构建一个csrf 恶意链接，然后访问这个链接就会自动登录csrf-tntaxin这个账户，这样受害者的访问记录你就都知道了。

CSRF 影响

影响仅受登录用户可以执行的操作的限制（如果站点/功能/操作未得到适当保护）。 真正容易受到 CSRF 攻击的领域是物联网设备和“智能”设备。可悲的是，许多消费级路由器 也被证明容易受到 CSRF 的影响。

CSRF解决方案

• cookie的Same site属性
  这是现代浏览器支持的新扩展，它限制了 cookie 的范围，使其仅 如果这些请求是“同一站点”，则附加到请求 例如，如果请求是从 发起的，则请求将附加同一站点 cookie。 有两种模式，严格和宽松。第一个不允许跨站点请求，
  SameSite的Strict和Lax选项在处理跨站点请求时具有不同的行为。

SameSite的Strict选项是最严格的设置，它禁止在任何跨站点请求上发送cookie。这意味着，如果黑客从他的网站去访问你网站的资源，如果你的网站的某些Cookie设置了SameSite = Strict，那么在黑客网站上的Cookie是不会发送到你的网站上的，只有你从你的站点去请求你站点的资源，才会带上这些Cookie。

相比之下，SameSite的Lax选项相对宽松。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交Get方式的表单这两种方式都会携带Cookie。但如果使用Post方法或在第三方站点中使用img、iframe等标签加载的URL，这些场景都不会携带Cookie。

总结来说，SameSite的Strict和Lax选项在处理跨站点请求时具有不同的规则，都旨在增强网站的安全性。

• 其他保护措施
  幸运的是，许多（Web）应用程序框架现在都内置了处理CSRF攻击的支持。例如，Spring 和 默认情况下，Tomcat 会启用此功能。只要你不关闭它（就像在 WebGoat 中一样），你应该不会受到 CSRF 攻击。

有关 CSRF 保护的更多信息，请参阅以下内容：

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html（预防/防御）

https://owasp.org/www-community/attacks/csrf（攻击）

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Prevention_Filter / https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter （Tomcat）

https://docs.spring.io/spring-security/site/docs/current/reference/html5/#csrf

Server-Side Request Forgery

概念
在服务器端请求伪造 （SSRF） 攻击中，攻击者可以滥用服务器上的功能来读取或更新内部资源。攻击者可以提供或修改服务器上运行的代码将读取或提交数据的 URL。而且，通过仔细选择 URL，攻击者可能能够读取服务器配置（如 AWS 元数据）、连接到内部服务（如启用了 HTTP 的数据库）或对内部服务执行 POST 请求，而这些服务并不打算公开。

目标
在接下来的几页的练习中，您需要检查浏览器向服务器发送的内容，以及如何调整请求以从服务器获取其他内容。

SSRF 操作方法
https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF

0x02

抓包，修改url为url=images%2Fjerry.png，发送请求。

0x03

抓包，修改url为http://ifconfig.pro

如何防止SSRF？

• 使用允许的域、资源和协议的白名单，Web 服务器可以从中获取资源。

• 如果从用户接受的任何输入与预期的正面规范不匹配，则应进行验证和拒绝。

• 如果可能，请不要在控制 Web 服务器获取资源的位置的函数中接受用户输入。

client side

Bypass front-end restrictions

用户对 Web 应用程序的前端有很大程度的控制权。 它们可以更改 HTML 代码，有时也可以更改脚本。这就是为什么 需要特定输入格式的应用也应在服务器端进行验证，而不是只在前端做限制。

0x02

先提交请求，burpsuite拦截后，修改每个字段的值，发送请求即可。

0x03

burp抓包 绕过前端正则即可

client side filtering

只向客户发送他们应该发送的信息始终是一种很好的做法 以访问。在本课中，向客户端发送了太多信息，从而产生了 严重的访问控制问题

0x03

随便输入一个code，单击提交，发现调用了一个接口来校验这个code对不对，而直接请求这个接口，返回了所有code。

HTML tampering

0x02

抓包，修改数量后提交，同样价格买了10台。

在这个简单示例中，价格是在客户端计算并发送到服务器的。服务器 接受给定的输入，并且没有再次计算价格。在这种情况下，缓解措施之一是查找 数据库中电视的价格，然后再次计算总价。

在实际应用程序中，永远不应依赖客户端验证。验证所有输入非常重要 由客户端发送。永远记住：永远不要相信客户端发送的输入。

引用
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html