【Web渗透】Web渗透各类型问题总结

简单的总结web渗透中常见的问题，主要分享测试经验和防御措施

一、暴力破解

0x01漏洞介绍

使用字典不断尝试登录系统，猜解认证凭据，达到通过系统认证的目的。

0x02测试方法/工具

1.观察web应用是否有防暴力破解机制，比如验证码机制、ip锁定、账号锁定等。

2.尝试绕过防暴力破解机制。

3.使用burpsuite的intruder模块进行暴力破解。

0x03测试经验总结

1.验证码绕过技巧

1）观察验证码的生成方式，是否由服务端生成、是否安全随机。

2）观察验证码是否在使用一次之后失效，不管是登录成功还是登录失败，验证码在使用一次后就必须失效。

3）观察验证码是否跟账号密码是在同一个请求中提交，如果不在一个请求中，则可以尝试drop掉提交验证码的请求，查看是否能够绕过验证码的校验。

4）观察验证码是否由服务端校验，有的web应用验证码在客户端校验，通过请求中的某一字段来表示验证码是否通过校验，此时可以手工修改表单中的这一字段，绕过验证码校验机制。

2.账号/ip锁定机制

1）检查账号锁定是服务端锁定还是本地锁定，换一个浏览器或者换一台机器尝试。

3.有些应用在用户成功登录后，使用session、token来维持后续的会话以及认证，如果session、token本身不够随机，且有规律可循，则也可能被破解。

0x04防范措施

1.验证码，使用一些现成的验证码框架。

2.账号锁定跟IP锁定尽量组合使用，如果单单使用账号锁定，则恶意用户可以通过暴力破解锁定web应用中的其它用户，甚至是管理员账号，达到拒绝服务的目的。

3.除了登录场景外，还有密码修改场景也需要做防暴力破解。

4.sessionid、token要使用安全随机数生成（24byte以上的安全随机数），尽量使用web容器自带的生成机制。

二、XSS

0x01漏洞介绍

XSS即跨站脚本(Cross Site Scripting)，攻击者在web页面中插入恶意的JavaScript脚本，当用户访问到该页面时，就会执行该恶意脚本，包括但不限于获取用户cookie、获取用户键盘输入等。

XSS分为三种类型：

1.反射性XSS

攻击者诱导用户去访问一个包含恶意代码的URL。当受害者点击恶意链接url的时候，恶意代码会直接在受害者的浏览器上执行，但不会影响到该web系统及web系统的其他用户。

2.存储型XSS

恶意代码被提交到了服务器上，当用户访问到对应页面时，就会执行恶意代码。比方说一个帖子，所有访问到这个帖子的用户，都会受到影响。

3.DOM型XSS

JavaScript中有一些方法比如document.write可以改变页面的DOM结构，如下面代码，可以在HTML中插入一个a标签，但是当url参数外部可控时，可以修改成恶意的JavaScript代码，造成XSS攻击。DOM型不会影响服务端及其他用户。

document.body.innerHTML = "<a href='"+url+"'>"+url+"</a>";

0x02测试方法/工具

可以用一些扫描器，AWVS、burpsuite的scan模块、长亭的xray等。

0x03测试经验总结

1.一些不受同源策略影响的标签

<script src="">//js
<img src="">//图片
<link href="">//css
<iframe src="">//任意资源

2.xss绕过

1）绕过前端限制；

2）大小写混合：后端可能只采用了黑名单过滤了小写的<script>，但是<SCRIPT>也会被正常执行。

3）拼凑：后端通过替换<script>来防御，但是可能只替换了一次。可以使用类似这样的payload：<scr<script>ipt>alert(1)</scri<script>pt>

4）使用注释干扰：<scri<!--test-->pt>alert(1)</scr<!--test-->ipt>

5）编码，后台校验可能不会识别到编码是恶意输入从而绕过检查，但是前台会正确翻译成JavaScript执行。

0x04防范措施

1.输入过滤、输出编码。注意根据不同的输出点，使用不同的编码，输出到js中的进行js转义，输出到html中的做html实体转义。

2.白名单校验，只允许特定的标签传入。

3.使用前端安全框架、模板引擎。比如我了解到的thymeleaf模板引擎，只要正确使用，就会自动给输出做编码。

三、CSRF

0x01漏洞介绍

CSRF（Cross-site request forgery）跨站请求伪造，简单讲就是攻击者构造一个请求，受害者点击后向正在访问的站点发起攻击者构造的请求，并带上了受害者自身的cookie，从而使用了受害者自己的身份去发送了一个由攻击者构造的请求。举个例子，比如受害者在更改自己的收货地址时，不小心点到了攻击者的恶意URL，则会将收货地址更改成攻击者的收货地址。

0x02测试方法/工具

1.扫描器

2.观察敏感操作的请求头中是否有csrf-token字段、观察重要的cookie是否有httponly、secure属性。

3.白盒走读生成csrf-token的代码，主要关注是否使用安全随机数生成，随机数位数是否符合要求。

0x03防御措施

1.最好的办法：重要操作的请求头中添加csrf-token字段，该字段要使用安全随机数生成并不易猜解。csrf-token需要在隐藏域中，跟随表单一起提交。

2.给cookie设置httponly、secure属性。安全的会话管理。

3.敏感操作增加二次认证，比如验证用户密码、手机验证码等。

总之，在请求中添加一个攻击者构造不出来的信息即可。

四、SQL注入

0x01漏洞介绍

1.数字型

2.字符型

3.搜索型

0x02测试方法/工具

1.扫码器

2.找到注入点后，可以使用sqlmap深入探测

3.构造payload的一些方法：

select database(); //获取数据名称  可以当成一个字段 在union后
select user();//获取数据库当前用户
select version();//获取数据库版本

猜测查询语句的字段数：（order by）
order by 1//按照第一列进行排序
order by 2//按照第二列进行排序
如果报错，则没有当前列，通过这样就可以知道查询语句查了多少字段

通过联合查询和information_schema数据库可以获取到数据库相关的重要信息，比如数据库表名、列名等。

4.白盒测试，走读sql代码。

0x03测试经验总结

现在因为没有做预编译而引起的sql注入漏洞已经很少了，大多都是没法做预编译的字段引起的sql注入问题，但是开发都有很高的安全意识，一般都会做好参数校验，下面分享几个遇到的sql注入问题。

1.mybatis框架中，asc、desc字段没法做预编译，开发采用白名单的方式做校验：若传入的参数不是asc或者desc，则直接给参数赋值asc。但是开发在写if语句的时候，逻辑写反了，搞成了传入的参数不为asc或desc时，则不赋值，造成了sql注入。

2.mybatis框架，代码中有些语句在mapper.xml中，有些语句使用SQL构造器，开发可能一时疏忽，在使用SQL构造器构造sql语句时，直接拼接了参数。（不过这个payload略微有点复杂，纯黑盒的话，需要很大精力去构造，但是白盒走读过代码的话，payload就很容易理解）。

更多白盒测试经验参考：【SQL注入】Mybatis框架下的sql注入白盒审计_l1b2090的博客-CSDN博客

0x04防御措施

1.最好的办法：预编译（大部分持久层框架都是采用的预编译）

2.不能预编译的场景，做好严格的参数校验。不能预编译的，往往是表名、字段名、sql关键字等，值相对是确定的，所以最好采用白名单。

五、文件上传下载

以后再写