既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

五、为什么参数化查询可以防止SQL注入

原理:

使用参数化查询数据库服务器不会把参数的内容当作sql指令的一部分来执行，是在数据库完成sql指令的编译后才套用参数运行

简单的说: 参数化能防注入的原因在于,语句是语句，参数是参数，参数的值并不是语句的一部分，数据库只按语句的语义跑

六、SQL头注入点

UAREFERERCOOKIEIP

七、盲注是什么？怎么盲注？

盲注是在SQL注入攻击过程中，服务器关闭了错误回显，我们单纯通过服务器返回内容的变化来判断是否存在SQL注入和利用的方式。盲注的手段有两种，一个是通过页面的返回内容是否正确(boolean-based)，来验证是否存在注入。一个是通过sql语句处理时间的不同来判断是否存在注入(time-based)，在这里，可以用benchmark，sleep等造成延时效果的函数，也可以通过构造大笛卡儿积的联合查询表来达到延时的目的。

八、宽字节注入产生原理以及根本原因

1、产生原理

在数据库使用了宽字符集而WEB中没考虑这个问题的情况下，在WEB层，由于0XBF27是两个字符，在PHP中比如addslash和magic_quotes_gpc开启时，由于会对0x27单引号进行转义，因此0xbf27会变成0xbf5c27,而数据进入数据库中时，由于0XBF5C是一个另外的字符，因此\转义符号会被前面的bf带着"吃掉"，单引号由此逃逸出来可以用来闭合语句。

2、在哪里编码

3、根本原因

character_set_client(客户端的字符集)和character_set_connection(连接层的字符集)不同,或转换函数如，iconv、mb_convert_encoding使用不当。

4、解决办法

统一数据库、Web应用、操作系统所使用的字符集，避免解析产生差异，最好都设置为UTF-8。或对数据进行正确的转义，如mysql_real_escape_string+mysql_set_charset的使用。

5、SQL里面只有update怎么利用

先理解这句 SQL

UPDATE user SET password=‘MD5($password{)}^{\prime },homepage{=}^{\prime }$homepage’ WHERE id=‘$id’

如果此 SQL 被修改成以下形式，就实现了注入

a、修改 homepage 值为http://xxx.net
', userlevel='3

之后 SQL 语句变为

UPDATE user SET password=‘mypass’, homepage=‘http://xxx.net
‘, userlevel=‘3’ WHERE id=’$id’

userlevel 为用户级别

b、修改 password 值为mypass)’ WHERE username=‘admin’#

之后 SQL 语句变为

UPDATE user SET password=‘MD5(mypass)’ WHERE username=‘admin’#)', homepage=‘$homepag{e}^{\prime }WHEREid{=}^{\prime }$id’

c、修改 id 值为’ OR username='admin’之后 SQL 语句变为

UPDATE user SET password=‘MD5($password{)}^{\prime },homepage{=}^{\prime }$homepage’ WHERE id=‘’ OR username=‘admin’

九、SQL如何写shell/单引被过滤怎么办

写shell: root权限，GPC关闭，知道文件路径 outfile函数

http://127.0.0.1:81/sqli.php?id=1 into outfile 'C:\\wamp64\\www\\phpinfo.php' FIELDS TERMINATED BY '<?php phpinfo(); ?>'
http://127.0.0.1:81/sqli.php?id=-1 union select 1,0x3c3f70687020706870696e666f28293b203f3e,3,4 into outfile 'C:\\wamp64\\www\\phpinfo.php'

宽字节注入

1、代替空格的方法

%0a、%0b、%a0 等/**/ 等注释符<>

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

5.0以下没有information_schema这个系统表，无法列表名等，只能暴力跑表名。

5.0以下是多用户单操作，5.0以上是多用户多操做。

十、XSS

1、XSS原理

反射型

用户提交的数据中可以构造代码来执行，从而实现窃取用户信息等攻击。需要诱使用户“点击”一个恶意链接，才能攻击成功

存储型

存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。

DOM型

通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。

2、DOM型和反射型的区别

**反射型XSS：**通过诱导用户点击，我们构造好的恶意payload才会触发的XSS。反射型XSS的检测我们在每次请求带payload的链接时页面应该是会带有特定的畸形数据的。**DOM型：**通过修改页面的DOM节点形成的XSS。DOM-based XSS由于是通过js代码进行dom操作产生的XSS，所以在请求的响应中我们甚至不一定会得到相应的畸形数据。根本区别在我看来是输出点的不同。

3、DOM型和XSS自动化测试或人工测试

**人工测试思路：**找到类似document.write、innerHTML赋值、outterHTML赋值、window.location操作、写javascript:后内容、eval、setTimeout 、setInterval 等直接执行之类的函数点。找到其变量，回溯变量来源观察是否可控，是否经过安全函数。自动化测试参看道哥的博客，思路是从输入入手，观察变量传递的过程，最终检查是否有在危险函数输出，中途是否有经过安全函数。但是这样就需要有一个javascript解析器，否则会漏掉一些通过js执行带入的部分内容。

在回答这段问题的时候，由于平时对客户的检测中，基本是凭借不同功能点的功能加上经验和直觉来进行检测，对不同类型的XSS检测方式实际上并没有太过细分的标准化检测方式，所以回答的很烂。。。

4、如何快速发现XSS位置

5、对于XSS怎么修补建议

**输入点检查：**对用户输入的数据进行合法性检查，使用filter过滤敏感字符或对进行编码转义，针对特定类型数据进行格式检查。针对输入点的检查最好放在服务器端实现。

**输出点检查：**对变量输出到HTML页面中时，对输出内容进行编码转义，输出在HTML中时，对其进行HTMLEncode，如果输出在Javascript脚本中时，对其进行JavascriptEncode。对使用JavascriptEncode的变量都放在引号中并转义危险字符，data部分就无法逃逸出引号外成为code的一部分。还可以使用更加严格的方法，对所有数字字母之外的字符都使用十六进制编码。此外，要注意在浏览器中，HTML的解析会优先于Javascript的解析，编码的方式也需要考虑清楚，针对不同的输出点，我们防御XSS的方法可能会不同，这点可能在之后的文章会做下总结。

除此之外，还有做HTTPOnly对Cookie劫持做限制。

6、XSS蠕虫的生产条件

正常情况下，一个是产生XSS点的页面不属于self页面，用户之间产生交互行为的页面，都可能造成XSS Worm的产生。

不一定需要存储型XSS

十一、CSRF

1、CSRF原理

CSRF是跨站请求伪造攻击，由客户端发起,是由于没有在关键操作执行时进行是否由用户自愿发起的确认

2、防御

验证Referer

添加token

3、token和referer做横向对比，谁安全等级高？

token安全等级更高，因为并不是任何服务器都可以取得referer，如果从HTTPS跳到HTTP，也不会发送referer。并且FLASH一些版本中可以自定义referer。但是token的话，要保证其足够随机且不可泄露。(不可预测性原则)

4、对referer的验证，从什么角度去做？如果做，怎么杜绝问题

对header中的referer的验证，一个是空referer，一个是referer过滤或者检测不完善。为了杜绝这种问题，在验证的白名单中，正则规则应当写完善。

5、针对token,对token测试会注意哪方面被人，会对token的哪方面进行测试？

引用一段请教前辈的回答：

针对token的攻击，一是对它本身的攻击，重放测试一次性、分析加密规则、校验方式是否正确等，二是结合信息泄露漏洞对它的获取，结合着发起组合攻击信息泄露有可能是缓存、日志、get，也有可能是利用跨站很多跳转登录的都依赖token，有一个跳转漏洞加反射型跨站就可以组合成登录劫持了另外也可以结合着其它业务来描述token的安全性及设计不好怎么被绕过比如抢红包业务之类的

十一、SSRF

SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）

SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。

1、监测

SSRF漏洞的验证方法：

1）因为SSRF漏洞是让服务器发送请求的安全漏洞，所以我们就可以通过抓包分析发送的请求是否是由服务器的发送的，从而来判断是否存在SSRF漏洞

2）在页面源码中查找访问的资源地址 ，如果该资源地址类型为 www.baidu.com/xxx.php?image=
（地址）的就可能存在SSRF漏洞 4[1]

2、SSRF漏洞的成因 防御 绕过

**成因：**模拟服务器对其他服务器资源进行请求，没有做合法性验证。利用：构造恶意内网IP做探测，或者使用其余所支持的协议对其余服务进行攻击。防御：禁止跳转，限制协议，内外网限制，URL限制。绕过：使用不同协议，针对IP，IP格式的绕过，针对URL，恶意URL增添其他字符，@之类的。301跳转+dns rebindding。

十二、上传

1、文件上传漏洞原理

由于程序员在对用户文件上传部分的控制不足或者处理缺陷，而导致用户可以越过其本身权限向服务器上传可执行的动态脚本文件

2、常见的上传绕过方式

前端js验证：禁用js/burp改包

大小写

双重后缀名

过滤绕过 pphphp->php

3、防护

文件上传目录设置为不可执行

使用白名单判断文件上传类型

用随机数改写文件名和路径

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

img-tGEVJ024-1715623087812)]
[外链图片转存中…(img-tBwLJs16-1715623087813)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取