hvv蓝初面试常见漏洞问题(上)

Posted Nuy0ah

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了hvv蓝初面试常见漏洞问题(上)相关的知识,希望对你有一定的参考价值。

1.SQL注入

漏洞成因:

  1. 可控变量
  2. 变量会带入数据库查询
  3. 变量不存在过滤或者变量过滤不严格

注入流程

  1. 判断是否有注入点
  2. order by 判断字段数量
  3. union select 报错查看注入点
  4. 使用函数查看数据库相关信息

注入分类:

  • 注入类型:报错、联合、盲注(布尔,时间)、堆叠
  • 注入提交方式:get,post,cookie,文件头

堆叠注入判断

"id=1"正常
试试"id=1a",假设报错,说明数据没有被强转
在试试"id=1;"假设没有报错,说明";"没有被代入查询,而是当做了sql语句的结束符
那可能存在堆叠

sql注入写shell条件

知道web服务器的绝对路径
数据库具有root权限
secure_file_priv函数没有具体值

为null时,表示不允许导出导入,无法提权
为/tmp/时,限制导入导出只能在/tmp目录下,无法提权
没有具体值,不限制导入导出

提高盲注速率

  1. 提高sqlmap线程数:--threads
  2. 使用python盲注脚本
  3. 若盲注主机为window,且dns服务器配置有问题,可以使用dnslog注入

如何突破注入时字符被转义

  1. 宽字节注入
  2. hex编码绕过

盲注:

判断是否存在盲注

  1. 查看返回数据包字节长度大小判断
  2. 借助sleep函数判断

布尔盲注--逻辑判断

常用函数:regexp,like,ascii,left,ord,mid,substr
substr()函数是截取字符串的函数
regexp从左至右进行匹配,如果匹配成功则返回1,匹配失败则返回0
like函数:匹配字符串,与regexp相似

时间盲注--延时判断

常用函数:if,sleep
if(expr1,expr2,expr3);表达式
如果expr1判断为真,则返回expr2值,否则expr3的值
sleep被禁用可以使用benchmark()函数

宽字节注入

产生原因:

数据库使用了宽字符集(如GBK)但web没有考虑,例如在web层0x3f27是两个字符(?\')当php中开启addslash时,会对0x27转义,因此变成0x3f5c27,数据进入数据库,由于0x3f5c是其他字符,所以转义字符就会被带走,从而单引号实现逃逸

根本原因:

客户端和连接层使用字符集不同,转换函数使用不当(iconv等)

解决方案:

统一使用字符集,对数据进行正确转义,如 mysql_real_escape_string+mysql_set_charset 的使用

报错注入:

定义:

报错注入就是利用了数据库的某些机制,人为地制造错误条件,使得查询结果能够出现在错误信息中。

常用函数:

  1. updatexml:利用插入不符合函数格式的语句并拼接查询语句从而通过函数报错达到我们查询内容的目的;
  2. extractvalue:利用插入不符合函数格式的语句并拼接查询语句从而通过函数报错达到我们查询内容的目的;

以~,#开头的内容不是xml格式的语法,就会报错,但是会显示无法识别的内容是什么

  1. floor:是一个取整函数,原理:group by在向统计表插入数据时,由于rand()多次计算导致插入统计表时主键重复,从而报错

mysql的网站注入5.0以上和5.0以下有什么区别?

  1. mysql5.0以下没有information_schema库,不能列表名,只能暴力跑表名
  2. mysql5.0以下是多用户单操作
  3. mysql5.0以上是多用户多操作

udf提权

原理:

获取webshell是一个低权限用户,然后UDF提权就是利用MySql允许扩展自定义函数的特性,将webshell的权限变成和mysql运行权限一致

利用

利用root高权限,创建一个可以调用cmd的udf.dll动态链接库,导出文件后可以直接命令框使用cmd
sqlmap udf 提权:--udf-inject

MOF提权

原理:

mof的作用是每隔五秒监控一次进程的创建和死亡,因此可以在mof中写入恶意代码,进行提权
利用条件:

  1. 操作系统版本低于 win2008
  2. 可以通过mysql导出文件%SystemRoot%\\System32\\Wbem\\MOF 文件夹下的MOF文件中,即需要mysql root权限以及secure_file_priv的值为空或者是%SystemRoot%\\System32\\Wbem\\MOF路径

过程

将mof上传至任意可读可写目录下
然后使用sql语句将系统当中默认的nullevt.mof给替换掉。进而让系统执行我们这个恶意的mof文件。

mof编译方法:

  1. 将MOF文件执行为命令行参数及Mofcomp.exe文件
  2. 使用IMofCompiler接口和$CompileFile方法
  3. 拖放到 %SystemRoot%\\System32\\Wbem\\MOF 文件夹下的MOF文件中

MSsql提权

利用xp_cmdshell提权

原理:

xp_cmdshell允许在数据库服务器上执行操作系统级别的命令。当具有足够权限的用户在 SQL Server 中执行 xp_cmdshell 时,它会调用操作系统的命令解释器(例如,Windows 上的 cmd.exe)并执行指定的命令。通常用于执行一些与操作系统相关的任务,例如运行外部程序、执行文件操作、管理文件系统等。

提权过程

xp_cmdshell 默认在 mssql2000 中是开启的,在 mssql2005 之后的版本中则默认禁止。如果用户拥有管理员 sa 权限则可以用 sp_configure 重新开启它。

EXEC sp_configure \'show advanced options\', 1
RECONFIGURE;
EXEC sp_configure \'xp_cmdshell\', 1;//若为零则为关闭
RECONFIGURE;

调用xp_cmdshell执行系统权限
EXEC master.dbo.xp_cmdshell \'命令\'

利用sp_oacreate提权

原理

当xp_cmdshell被删除时,可以利用sp_oacreate(奥普瑞特)提权,他是用于在sql中创建和实例化com对象的存储过程中,利用创建的com对象中存在的漏洞或特权操作,就能获取更高权限
默认也是关闭状态

EXEC sp_configure \'show advanced options\', 1;
RECONFIGURE WITH OVERRIDE;
EXEC sp_configure \'Ole Automation Procedures\', 1;//若为零则为关闭
RECONFIGURE WITH OVERRIDE;

sp_oacreate执行命令是无回显的,使用dnslog平台进行判断

sql注入绕waf

  1. 注入空白字符:攻击者可以在注入语句中使用空格、Tab键、换行符等空白字符,从而绕过WAF的检测。
  2. URL编码:攻击者可以使用URL编码技术,将语句中的特殊字符进行编码,从而绕过WAF的检测。例如,将单引号编码为%27,将双引号编码为%22等。
  3. Unicode编码:攻击者可以使用Unicode编码技术,将注入语句中的特殊字符进行编码,从而绕过WAF的检测。例如,将单引号编码为%u0027,将双引号编码为%u0022等。
  4. 拆分注入:攻击者可以将注入语句拆分为多个短语或子句,从而绕过WAF的检测。例如,将SELECT关键字分成两个部分,使用空白字符分隔,如SEL ECT等。
  5. 盲注:攻击者可以使用盲注技术,通过检查应用程序的响应来获取有关注入结果的信息,从而绕过WAF的检测。盲注技术可以分为布尔盲注和时间盲注两种。

sql预编译

原理:将sql语句中的值用占位符替代,可以视为将sql语句模板化或者说参数化。一次编译、多次运行,省去了解析优化等过程。

sql注入防范:

  1. 参数化查询:使用参数化的SQL查询,而不是动态拼接SQL查询字符串。这可以防止攻击者注入恶意代码,因为参数值会被视为数据而不是代码。
  2. 数据校验:对于输入数据,应该对其进行校验和过滤。例如,对于数字字段,应该只接受数字输入;对于字符串字段,应该过滤掉特殊字符和SQL关键字。
  3. 最小权限原则:应该使用最小权限原则来限制应用程序的访问权限。这样,即使攻击者成功地注入恶意代码,他们也只能访问应用程序有权访问的数据。
  4. 数据加密:对于敏感数据,应该使用数据加密来保护其安全性。这可以防止攻击者通过窃取数据库中的数据来获取敏感信息。
  5. 定期更新:应该定期更新数据库软件和应用程序代码,以修复已知的安全漏洞并增强系统的安全性。

2.文件包含

造成原理

文件包含的代码文件被写成了一个变量,且这个变量可以由前端用户传进来,这种情况下,如果没有做足够的安全考虑,则可能会引发文件包含漏洞。 攻击者会指定一个“意想不到”的文件让包含函数去执行,从而造成恶意操作。

php相应函数

  1. include():找不到包含文件就产生告警,继续运行
  2. require():找不到包含文件就停止运行
  3. include_once():与include类似,但只会包含一次
  4. require_once():与require类似,但只会包含一次

php伪协议

  1. file:// 用于访问本地文件系统
  2. php://filter 读取文件源码
    常用于读取文件源码,使用文件包含函数包含文件时,文件中的代码会被执行,如果想要读取文件源码,可以使用base64对文件内容进行编码,编码后的文件内容不会被执行,而是展示在页面中,我们将页面中的内容使用base64解码,就可以获取文件的源码了
  3. php://input 任意代码执行
    php://input 可以访问请求的原始数据,配合文件包含漏洞可以将post请求体中的内容当做文件内容执行,从而实现任意代码执行
  4. data://text/plain 任意代码执行
    协议格式: data:资源类型;编码,内容
    data://协议通过执行资源类型,使后面的内容当做文件内容来执行,从而造成任意代码执行
  5. zip:// 配合文件上传开启后门
    zip://协议用来读取压缩包中的文件,可以配合文件上传开启后门,获取webshell将shell.txt压缩成zip,再将后缀名改为jpg上传至服务器,再通过zip伪协议访问压缩包里的文件,从而链接木马

文件包含分类

  1. 本地包含:仅能够对服务器本地的文件进行包含,主要可以用与读取本地敏感信息
  2. 远程包含:能够通过url地址对远程的文件进行包含

系统的敏感信息

Linux

/etc/passwd:包含本地用户的账户信息。
/etc/group:包含用户组的信息。
/etc/shadow:保存本地用户密码哈希值的文件。
/etc/sudoers:保存 sudo 命令权限的文件。
/proc/net/tcp:包含当前正在运行的 TCP 连接信息。
/var/log/auth.log:包含系统中用户认证和授权的日志信息。
应用程序配置文件:攻击者可能会尝试读取应用程序的配置文件,以获取数据库连接字符串等信息。

Windows

C:\\Windows\\system32\\config\\SAM:包含本地账户的哈希密码值。
C:\\Windows\\system32\\config\\SYSTEM:包含系统的配置信息。
C:\\inetpub\\wwwroot\\web.config:包含 IIS 网站的配置信息。
C:\\Program Files (x86)\\MySQL\\MySQL Server 5.7\\my.ini:包含 MySQL 数据库的配置信息。

3.文件上传

漏洞成因

  1. 没有对上传的文件进行足够的验证和过滤。没有对上传的文件类型、大小、名称和内容进行严格的验证和过滤,从而允许攻击者上传任意类型、任意大小和任意内容的文件
  2. 没有对上传文件的保存路径和文件名进行控制。将上传的文件保存在与Web根目录相同的目录下,或者将上传的文件名保存为原始的文件名,从而允许攻击者通过上传包含恶意代码的脚本文件或具有危险文件名的文件来执行攻击。
  3. 没有对上传文件的访问权限进行限制。允许上传的文件在上传后具有完全的访问权限,从而允许攻击者通过访问上传的文件来获取或修改敏感数据。

绕过方法:

  1. 禁用js绕过
  2. 修改文件类型绕过
  3. 大小写,双写绕过
  4. 文件头绕过
  5. 二次渲染绕过
  6. 条件竞争绕过
  7. 00截断绕过:条件:php版本要小于5.3,魔术引号关闭(白)
  8. 配合解析漏洞绕过(白)
  9. 配合文件包含漏洞(白)

文件上传相关日志

  1. 文件上传日志:Web 服务器或应用服务器上的访问日志中可能包含上传文件的信息,例如上传时间、上传文件名称、上传文件大小等。
  2. 访问控制日志:如果应用程序实现了文件上传的访问控制机制,记录访问控制的日志可能包含了上传文件的信息,例如上传人员、上传时间、上传 IP 地址等。
  3. 安全审计日志:如果使用了安全审计工具,可以记录文件上传操作的详细信息,例如上传文件的路径、上传文件的内容等。

防护方法

  1. 文件类型和大小限制:在服务器端对上传的文件进行检查,确保上传的文件类型、大小和数量符合预期。可以使用白名单方式进行限制,只允许上传特定类型的文件。
  2. 检查文件内容:在服务器端对上传的文件进行检查,确保它们不包含恶意代码或病毒等危险内容。可以使用杀毒软件或安全扫描工具来帮助检查上传的文件。
  3. 重命名文件:将上传的文件保存在一个新的随机生成的文件名下,而不是使用用户提供的文件名。这样可以避免攻击者通过伪造文件名来欺骗用户。
  4. 存储位置:将上传的文件保存在与网站主目录分离的位置上,以避免攻击者上传Webshell等恶意脚本,并能够防止攻击者直接访问上传的文件。
  5. WAF防护产品

4.XSS

原理:

攻击者通过注入恶意脚本代码,将攻击者的代码注入到网站的页面中,当用户访问被攻击的页面时,就会执行这些恶意代码,从而导致攻击者获取用户的敏感信息

分类

  1. 反射型XSS:恶意脚本被注入到URL参数中,经后端程序处理后直接输出(使用短网址)
  2. 存储型XSS:恶意脚本被注入到数据库中,经后端程序处理后保存
  3. dom型XSS:攻击者通过修改页面的DOM节点,从而实现攻击的目的(不经过服务器,前端代码的利用)

xss利用

  1. 窃取用户cookie,从而获取用户信息
  2. 网页挂马:通过xss插入恶意js脚本(例如键盘记录功能)用户访问页面就同时执行恶意js
  3. 强制弹出广告页面
    dom树标签

绕过方法

  1. 大小写绕过
  2. 双写绕过
  3. 关键字绕过
  4. 转换编码

xss常出现的地方

  1. 富文本编辑器
  2. 站点内用户之间私信
  3. 个人资料编辑
  4. 客服对话窗口
  5. 订单流程

防御:

  1. 输入过滤
    a. 输入是否仅仅包含合法的字符
    b. 输入字符串是否超过最大长度限制
    c. 输入如果为数字,数字是否在指定的范围
    d. 输入是否符合特殊的格式要求,如E-mail地址、IP地址等
  2. 输出转码:将HTML实体化编码
  3. 黑白名单
  4. 设置http-only(限制cookie劫持)php版本大于5.2

5.csrf

跨站请求伪造:利用用户在已登录的情况下访问恶意网站时,绕过同源策略,以用户身份执行未经授权的操作
同源:协议,ip,端口一致
同源策略浏览器在执行脚本前,会判断脚本是否与打开的网页是同源的,判断协议、域名、端口是否都相同,相同则表示同源。其中一项不相同就表示跨域访问

原理:

攻击者通过跨站请求(利用url短网站诱导点击),利用尚未失效的身份认证信息,以合法的用户身份进非法操作,简单来说盗用你的身份信息,向第三方网站发送恶意请求,包括利用你的身份发邮件,发短信,交易转账等。

类型

  1. GET类型的CSRF:通过构造一个包含受害网站的请求参数的URL,然后将这个URL发送给用户进行访问,当用户在浏览器中点击该链接时,浏览器会自动发出带有参数的GET请求
  2. POST类型的CSRF:构造一个包含受害网站的请求参数的表单,然后将这个表单发送给用户进行填写,当用户在浏览器中提交表单时,浏览器会自动发出带有参数的POST请求

挖掘

  1. 抓取正常请求数据包,查看是否存在referer字段或者token
  2. 如果有referer字段,删除再提交,若提交有效,则存在referer字段
  3. 使用相对应的检测工具,例如:CSRFTester

防御

  1. 验证HTTP Referer字段
  2. 在请求地址中添加token并验证
  3. 在HTTP头中加入自定义属性并验证
  4. 增加二次验证机制

与xss的区别

  1. CSRF需要用户先登录网站A,获取cookie; XSS不需要登录
  2. CSRF是利用网站A本身的漏洞,去请求网站A的api; XSS是向网站A注入JS代码,然后执行JS里的代码,篡改网站A的内容。
  3. XSS是利用合法用户获取其信息,而CSRF是伪造成合法用户发起请求

ES 常见面试问题

参考技术A

1 增大内存: es性能优化的杀手锏: filesystem cache(OS cache): 也就是说 尽量让内存可以容纳所有的索引数据文件,那么搜索的时候就基本都是走内存的,性能会非常高。磁盘和OS cache扫描速度相差近一个数量级,可能一个是1到几百毫秒,另一个是秒。最佳的情况下,就是单机机器的内存,至少可以容纳单机数据量的一半。另一个方面就是写数据的时候,仅仅写入要用来检索的少数几个字段就可以了,其余的数据放到hbase或者mysql上
2 数据预热
假设机器内存达到上面的要求,比如 内存是100G,数据是200G。那么有一半的数据存放在磁盘上,那么这个时候可以设计一个 数据预热子系统, 就是对热数据每隔一段时间,就提前访问一下,让热数据进入 filesystem cache 里面去。这样下次别人访问的时候,性能一定会好很多。
3 document 模型设计
document 模型设计是非常重要的,很多操作,不要在搜索的时候才想去执行各种复杂的乱七八糟的操作,尽量存放单纯的数据放到ES上去,不要考虑用 es 做一些它不好操作的事情,比如 join/nested/parent-child 搜索都要尽量避免,性能都很差的。
4 分页性能优化
分页性能差的原因: https://www.jianshu.com/p/e4da06b55e63
解决方案1:跟产品经理说,你系统不允许翻那么深的页,默认翻的越深,性能就越差。
解决方案2:类似于 app 里的推荐商品不断下拉出来一页一页的
就像淘宝商品一样,一页一页往下刷,不能从第一页跳到100页,从100页跳到50页,不能这样操作。
可以使用 scroll api 来实现,scroll 会一次性给你生成所有数据的一个快照,然后每次滑动向后翻页就是通过游标 scroll_id 移动,获取下一页下一页这样子,性能会比上面说的那种分页性能要高很多很多,基本上都是毫秒级的。
初始化时必须指定 scroll 参数,告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时,否则可能因为超时而失败。
除了用 scroll api,你也可以用 search_after 来做,search_after 的思想是使用前一页的结果来帮助检索下一页的数据,显然,这种方式也不允许你随意翻页,你只能一页页往后翻。初始化时,需要使用一个唯一值的字段作为 sort 字段。参考: https://www.cnblogs.com/hello-shf/p/11543453.html#4527510

见 https://www.jianshu.com/p/a5c1ec91c92e

先写入内存 buffer,在 buffer 里的时候数据是搜索不到的;同时将数据写入 translog 日志文件。

如果 buffer 快满了,或者到一定时间,就会将内存 buffer 数据 refresh 到一个新的 segment file 中,但是此时数据不是直接进入 segment file 磁盘文件,而是先进入 os cache 。这个过程就是 refresh。只要数据进入了OS cache那么就可以被访问到了。

每隔 1 秒钟,es 将 buffer 中的数据写入一个新的 segment file (如果 buffer 里面此时没有数据,那当然不会执行 refresh 操作) ,每秒钟会产生一个新的磁盘文件 segment file,这个 segment file 中就存储最近 1 秒内 buffer 中写入的数据。

这里就解释了为什么叫 es 是 准实时 的? NRT,全称 near real-time。默认是每隔 1 秒 refresh 一次的,所以 es 是准实时的,因为写入的数据 1 秒之后才能被看到。可以通过 es 的 restful api 或者 java api,手动执行一次 refresh 操作,就是手动将 buffer 中的数据刷入 os cache中(但是这样会影响ES批量插入数据的效率),让数据立马就可以被搜索到。只要数据被输入 os cache 中,buffer 就会被清空了,因为不需要保留 buffer 了,数据在 translog 里面已经持久化到磁盘去一份了。

重复上面的步骤,新的数据不断进入 buffer 和 translog,不断将 buffer 数据写入一个又一个新的 segment file 中去,每次 refresh 完 buffer 清空,translog 保留。随着这个过程推进,translog 会变得越来越大。当 translog 达到一定长度的时候,就会触发 commit 操作。

commit 操作发生第一步,就是将 buffer 中现有数据 refresh 到 os cache 中去,清空 buffer。然后,将一个 commit point 写入磁盘文件,里面标识着这个 commit point 对应的所有 segment file,同时强行将 os cache 中目前所有的数据都 fsync 到磁盘文件中去。最后清空 现有 translog 日志文件,重启一个 translog,此时 commit 操作完成。

这个 commit 操作叫做 flush。默认 30 分钟自动执行一次 flush,但如果 translog 过大,也会触发 flush。flush 操作就对应着 commit 的全过程,我们可以通过 es api,手动执行 flush 操作,手动将 os cache 中的数据 fsync 强刷到磁盘上去。

translog 日志文件的作用是什么?你执行 commit 操作之前,数据要么是停留在 buffer 中,要么是停留在 os cache 中,无论是 buffer 还是 os cache 都是内存,一旦这台机器死了,内存中的数据就全丢了。所以需要将数据对应的操作写入一个专门的日志文件 translog 中,一旦此时机器宕机,再次重启的时候,es 会自动读取 translog 日志文件中的数据,恢复到内存 buffer 和 os cache 中去 这里和Redis持久化机制是类似的

translog 其实也是先写入 os cache 的,默认每隔 5 秒刷一次到磁盘中去,所以默认情况下,可能有 5 秒的数据会仅仅停留在 buffer 或者 translog 文件的 os cache 中,如果此时机器挂了,会丢失 5 秒钟的数据。但是这样性能比较好,最多丢 5 秒的数据。也可以将 translog 设置成每次写操作必须是直接 fsync 到磁盘,但是性能会差很多。

总结一下,数据先写入内存 buffer,然后每隔 1s,将数据 refresh 到 os cache,到了 os cache 数据就能被搜索到(所以我们才说 es 从写入到能被搜索到,中间有 1s 的延迟)。每隔 5s,将数据写入 translog 文件(磁盘里面)(这样如果机器宕机,内存数据全没,最多会有 5s 的数据丢失),translog 大到一定程度,或者默认每隔 30mins,会触发 commit 操作,将缓冲区的数据都 flush 到 segment file 磁盘文件中。

可以通过 doc id 来查询,会根据 doc id 进行 hash,判断出来当时把 doc id 分配到了哪个 shard 上面去,从那个 shard 去查询。

客户端发送请求到任意一个 node,成为 coordinate node。
coordinate node 对 doc id 进行哈希路由,将请求转发到对应的 node,此时会使用 round-robin 随机轮询算法,在 primary shard 以及其所有 replica 中随机选择一个,让读请求负载均衡。
接收请求的 node 返回 document 给 coordinate node。
coordinate node 返回 document 给客户端。
搜索
es 最强大的是做全文检索,就是比如你有三条数据:
java真好玩儿啊
java好难学啊
j2ee特别牛
你根据 java 关键词来搜索,将包含 java的 document 给搜索出来。es 就会给你返回:java真好玩儿啊,java好难学啊。
1 客户端发送请求到一个 coordinate node。
2 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard,都可以。
3 query phase:每个 shard 将自己的搜索结果(其实就是一些 doc id)返回给协调节点,由协调节点进行数据的合并、排序、分页等操作,产出最终结果。
4 fetch phase:接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据,最终返回给客户端。

如果是更新操作,就是将原来的 doc 标识为 deleted 状态,然后新写入一条数据。
buffer 每 refresh 一次,就会产生一个 segment file,所以默认情况下是 1 秒钟一个 segment file,这样下来 segment file 会越来越多,此时会定期执行 merge。每次 merge 的时候,会将多个 segment file 合并成一个 (这里类似于Redis的RDB文件重写) ,同时这里会将标识为 deleted 的 doc 给 物理删除掉 ,然后将新的 segment file 写入磁盘,这里会写一个 commit point,标识所有新的 segment file,然后打开 segment file 供搜索使用,同时删除旧的 segment file。

以上是关于hvv蓝初面试常见漏洞问题(上)的主要内容,如果未能解决你的问题,请参考以下文章

安全测试面试常见问题有哪些?

权限提升和维持

护网行动面试题目汇总

2022HVV系列蓝队手册更新版(建议收藏)

文库 | web中常见中间件漏洞总结

WEB面试问题:什么是 XSS 攻击?