初探OWASP TOP10
OWASP TOP 1: Broken Access Control(失效的访问控制)
一、什么是访问控制和访问控制失效导致的问题
访问控制是一种策略；这种策略规定用户无法逾越预设好的权限边界
导致的问题：文件包含、目录遍历、未认证信息泄露、内部数据篡改、数据删除和水平越权操作和垂直越权操作、CSRF等
二、访问控制实现常见的攻击场景
1.通过修改 URL 地址、内部程序状态、HTML 页面，或者使用 Cyber 工具修改 API 请求的方式绕过访问控制:
用户轻松的修改URL的参数内容，从而轻而易举的访问到admin页面。一下是两个假设URL，第一个是普通用户，第二个是管理员用户页面，如果普通用户访问第二个页面成功，那就说明访问控制策略存在问题。
1 | https://example.com/app/getappInfo |
2.通过提供唯一ID的方式预览或者修改其他账户信息及数据:
由于实现过程中未对用户访问参数设置边界，导致了很多越权问题的发生，下方示例URL中，攻击者可以尝试修改 API 接口中的 order_id 参数，使其在程序接口上的输入合法，但是对于用户而言却是越权行为。
1 | https://example.com/order/?order_id=2021102617429999 |
3.未经过访问控制地通过 POST、PUT 和 DELETE 方法访问 API:
HTTP PUT 方法最早目的用于文件管理操作，可以对网站服务器中的文件实现更改删除的更新操作，该方法往往可以导致各种文件上传漏洞，造成严重的网站攻击事件，下方示例代码，在支持 PUT 方法的环境中，上传Webshell进行提权；在实际运用中，若必须启用该方法，则需要对该方法涉及文件资源做好严格的访问权限控制。
1 | put /root/Desktop/shell.php |
4.元数据操纵，比如重放或者修改JWT(JSON Web Token)访问控制令牌，或者通过操纵Cookie的方式进行提权:
Web应用将身份认证结果直接存储在Cookie中，并未施加额外的保护措施，下方示例中，攻击者通过web前端拦截cookie,实现对cookie的修改，从而达到未授权访问的效果：
1 | Cookie: role=user --> Cookie: role=admin |
5.CORS 误配置，可以导致来自未认证源的API访问：
有些开发者为了方便，直接在Access-Control-Allow-Origin中反射请求的Origin值。比如如下配置，意味着nginx相信任何网站，允许所有访问跨域读取器资源，造成隐私数据被窃取。
1 | add_header "Access-Control-Allow-Origin" $http_origin; |
6.目录穿越：
一种典型的社交网络应用代码，每个用户的配置文件都被存储在单独的文件中，所有文件被集中到一个目录里；当用户尝试访问我们的的配置文件的时候，会组成如下路径
1 | /users/example/prfiles/hunter |
但是这里并没有对我们的输入的访问文件名进行过滤，攻击者如果抓包修改访问文件问../../../../../../etc/password这样的文
件路径则会导致完成一个完整的路径;从而实现路径穿越
1 | /users/example/prfiles/../../../../../../etc/passwd -> /etc/passwd |
7.CSRF:可以查询我之前的博客https://hyggevv.github.io/2022/12/22/CSRF/
OWASP TOP 2:Cryptographic Failures(加密机制失效)
什么是加密机制和为什么会引发加密机制的失效
加密机制失败原本又称为敏感信息泄露；而我们需要知道是加密机制的失效导致了敏感信息的泄露。加密是一个数学问题，应用到了开发场景。事实上，加密函数就像一个黑盒，开发人员能够考虑的只有输入和输出，其中输出还是非常复杂的。加密是否成功，极大地影响着系统的安全性，但是很多开发人员，对加密却没有深入研究。所以开发人员在考虑加密的时候，并不验证起加密质量如何，往往只会在意他们的加密输出是否成功。
引发加密机制失效的场景
1.在数据的传输过程中以明文的方式进行传输
2.在代码中硬编码了密钥或者密码(硬编码即为将数据直接写入代码中)
3.数据传输过程中使用了已经被破解或者存在漏洞的加密算法(MD5/SHA1/RSA低加密指数攻击:RSA加密的文章我在前面也有写过：https://hyggevv.github.io/2023/01/09/RSA/)
4.使用了比较弱的密钥容易被破解或者重复使用该密钥或者该密钥的管理方法是否安全或者很久没有更换此密钥
5.使用了已经被废弃的安全协议(SSL)
6.加密机制的漏洞之厂商后门：厂商在设计组态工程文件加密机制的时候，会考虑到用户忘记密码这个需求，即用户在不输入密码的情况下绕过验证直接打开工程文件。用户只需要证明该组态工程文件属于自己，之后将组态工程文件发给厂商，厂商通过预留的后门（绕过密码）将用户的组态工程文件解密后再发回给用户。这样的设计虽然方便了用户，但是也为不法分子大开方便之门。攻击者只需要找到组态软件中的组态工程后门密码，也能在不输入密码的情况下编辑组态工程文件。
7.加密机制的漏洞之设计缺陷：在验证密码时，输入密码并没有参与组态工程文件的加密，只是简单的对比了密码的哈希值，这就导致了可以通过修改组态工程文件中的密码哈希或者通过补丁的方式将本来应该走向错误的处理分支修改为走向正确的处理分支。通过这类方式也可以在不知道组态工程文件密码的情况下强行绕过组态工程文件密码保护机制而编辑组态工程文件。
OWASP TOP 3:Injection(注入)
注入一之SQL注入
一、什么是SQL注入
SQL注入是用户恶意拼接了输入；并且数据库并未对用户的输入的数据的合法性没有判断和过滤导致用户恶意拼接；因为前端的输入参数是用户可控的所以此时我们可以任意的拼接SQL语句进行增删减查的操作；因为我们需要的数据是存放在数据库中的所以当数据库查询我们的输入时若是我们的输入中含有恶意拼接的内容则数据库便会带着我们的SQL语句的内容一起回显到页面之中比如最基础的
1 | $sql = "select*from users where id = '$id' LIMIT 0,1" |
改代码的原本意思是让用户输入id并且查询；此时我们可以拼接一个最基础的数据库名查询
1 | 0' union select 1,2,database()# |
此时的整个SQL语句在拼接之后就是
1 | $sql = "select * from users where id = '0' union select 1,2,database()#' LIMIT 0,1" |
此时id=0时数据库查询不到用户此时便执行联合查询的内容将数据库的名称爆出来
二、SQL注入的攻击场景
1.联合查询注入(union select):使用的前提是界面拥有显示位；显示位就是服务端执行SQL语句查询数据库中的数据，客户端将数据展示在页面中，这个展示数据的位置就叫显示位。此时需要注意的一点是若是在联合查询注入时SQL语句中包含了此字段没有的内容时；便会产生一个虚拟的表格来存放这个没有拥有的数据；这个虚拟表格在执行下一条查询语句之后便会被消除包括这个虚拟表格里面的内容；这个往往也是一个注入点；可以绕过一些过滤。
2.报错注入(updataxml/extractvalue)：可以看到上面两函数里都有xpath路径，而在xpath中，插入~（ASCII码是0x7e）和^（ASCII码是0x5e）等特殊字符是非法的，也就会产生报错，而这些特殊字符也恰好是报错注入的关键点，而当报错内容为SQL语句的时候，SQL那边的解析器会自动解析该SQL语句，就造成了SQL语句的任意执行
3.盲注：在无显示位无报错信息的情况下通常使用盲注来获取数据
4.二次注入：在数据处理时对敏感字符进行了转义的处理；但是在数据存放进行数据库时并没有进行转义处理而是直接存入；此时我们称这些数据为脏数据；而当后台查询的时候还是将这些脏数据原样取出；在取出数据即为数据库查询的过程中脏数据便发挥了作用；此时若是脏数据包含SQL语句数据库便会执行并且回显外带数据
5.双处理器的绕过：有时可能会设置两个服务器来防范SQL注入；而此时第一个服务器对我们的输入进行了严格的过滤但是第二个服务器并没有较为严格的对我们的数据进行过滤；此时我们可以构造第一个正常的输入参数来绕过第一个服务器的检测然后在第二个参数里面来构造SQL语句来进行我们的注入攻击
6.宽字节注入：宽字节注入是利用mysql的一个特性；PHP发送请求到mysql，mysql在使用GBK编码（GBK是宽字节，双字节）的时候，会认为两个字符是一个汉字（前一个ascii码要大于128，才到汉字的范围）；字符和转义的反斜杠组成了新的汉字，但是组成的新汉字又不是一个正常的汉字，就起到了注掉 \ 的作用；可以看出来是字符集不一致造成的宽字节注入
1 | 默认情况下： 1' --+ --> 1\' --+ |
此时便可以通过添加%df的方法来绕过添加转义字符对敏感字符’进行转义的过滤机制
7.叠堆注入：在SQL中，分号 ; 是用来表示一条sql语句的结束。当我们结束一个sql语句后继续构造下一条语句，会不会一起执行？因此这个想法也就造就了堆叠注入。此时需要区分一下叠堆注入和联合查询注入的不同点；叠堆注入不仅可以进行查询还可以对数据库执行增删减查的操作；而联合注入只能进行查询的功能
此时想补充点自己的思考；到底什么是SQL注入；SQL注入在我看来就是我们输入的参数会被带入数据库中进行查询；然后数据库会回显出查询的结果；此时我们便可以在参数中拼接SQL语句；而因为注入点的不同；此时可以存在很多的注入点；比如在请求包中的请求头的注入或者ORDER BY的注入等等；其实回归本质这个就是看查询语句的查询点；该查询点就是我们的注入点。
OWASP TOP 4:Insecure Design(不安全的设计)
什么是不安全的设计
不安全设计是一个广泛的范畴，代表不同的弱点，表现为“缺失或无效的控制设计”不安全设计并不是所有其他十大风险类别的根源。不安全的设计和不安全的实现是有区别的。我们区分设计缺陷和实现缺陷是有原因的，它们有不同的根源和补救措施。一个安全的设计仍然可能有导致漏洞被利用的实现缺陷。一个不安全的设计不可能被完美的实现所修复，因为根据定义，所需的安全控制从未被创建来抵御特定的攻击。导致不安全设计的因素之一是开发的软件或系统中缺乏固有的业务风险分析，因此无法确定需要何种级别的安全设计。
简单来说就是不安全的设计更多的是利用你的本身功能，只是说你的本身功能存在问题。
不安全的设计常见的攻击场景
1.业务逻辑漏洞:当开发者在设计一个 Web 应用时，没有进行充分的逻辑考虑，导致Web应用的逻辑设计不够充分，就容易导致业务逻辑漏洞的产生。这么说有点抽象，我们一起来看一个示例:
1 | POST /cart HTTP/1.1 |
此时我们若是可以对我们抓包的内容进行修改则可以证明存在业务逻辑漏洞；我们可以利用这个漏洞用极少的价钱购买极多的商品；
这就是应用开发者考虑不够充分导致的问题，他们可能认为只要前端页面无法修改单价就行，但是攻击者会有别的方式去修改，比如使用burpsuite进行抓包。
2.包含敏感信息的报错(信息泄露)
(1)robots.txt信息泄露：
在我们的网站根目录下，大多会有这样一个文件：robots.txt。这个文件主要是用来限制整个站点的搜索引擎访问情况，即设置哪些内容可以被访问，哪些内容不可以被访问。如果在这个文件中，包含了用户不可见目录的信息、结构以及内容，那么攻击者就可以访问这个文件来获取这些隐私信息。
(2)错误信息泄露：在我们学习SQL注入时已经了解了报错注入的方法和原理；就是在界面返回错误是顺带将我们包含在错误语句中的查询信息返回；此时我们看下图这个Web应用是通过GET方式上传参数productId。为了让页面显示出报错信息，我们将productId的值改为一个字符类型例如 App，这样页面就可能会出现参数类型错误。可以看到，页面确实爆出来了很多错误信息。
(3)备份文件的泄露：Web 应用管理者，在更新 Web 应用时，很可能会将网页内容进行备份。如果管理者出于方便考虑，直接将备份文件放到网站目录下，并且没有对它进行访问控制的设置，那么攻击者就可以直接访问这个文件名，来获取备份文件。此时我们可以利用后台扫描工具(dirsearch/御剑)进行扫描
3.OAuth 开放授权：我们在其他的平台进行登入账号时我们进行抓包处理
1 | POST /authenticate HTTP/1.1 |
此时可以看到我们被给予了一个token令牌；此时我们若是对请求包中的email进行修改然后发送请求包；若是结果可以登入我们修改之后邮箱则此时就存在授权漏洞；此时对于OAuth漏洞来的处理来说，可以让授权令牌仅仅可用一次，这样就能很好地避免授权令牌的重复使用。对于待授权的客户端应用来说，可以将授权令牌绑定发起授权请求的用户，这样就使得攻击者无法使用自己的授权令牌来登录其他用户的账户。