WEB应用漏洞简单总结
前言
终于开始写自己的文章,以己微薄之力来抒写,或多或少的,总有着不足 ,打算试着吸收网络中的信息,先从常见安全漏洞类型开始,从web安全——>系统安全——>中间件安全——>移动安全,一周一章的坚持下去。由于某某原因,文章不定时发表,或许有天就沉淀下来好好抒写了,哈哈哈。本文给web应用漏洞定个框架,后续会不断补起相关漏洞的原理、挖掘场景、实战利用等,如有不足,请多指教。

如果自己就是潮水的一部分,怎么能看见潮流的方向呢?
>——Paul Graham《黑客与画家》
先放两张渗透漏洞占比:
2018之前情况

2020情况

OWSAP TOP10 对比情况

在来张攻击面占比:

由上图可以看出目前安全的主要问题。借此,以本文为记,简单记录下自己所了解的web应用漏洞。
ps:图来源于网络
一、注入漏洞
1.1 SQL注入漏洞
漏洞描述:
SQL注入漏洞产生的原因:
网站应用程序编写时,未对用户的操作输入进行合法性校验,既没有进行有效地特殊字符过滤,导致在网络与数据库的交互过程中,操作输入的数据库语句能在前台执行数据库操作,达到攻击目的。
漏洞危害:
- 机密、业务等数据丢失、被窃取
- 核心业务数据被篡改
- 网页被篡改
- 主机可能会被完全接管。
- 进一步控制主机入侵内网,危害内网安全。
修复建议:
代码层
- 网页代码中对用户输入的数据进行严格过滤
- 使用安全的API
- 规范编码,字符集
- 服务器端在提交数据库进行SQL查询之前,对特殊字符进行过滤、转义、替换、删除。
- 对输入的特殊字符进行Escape转义处理
- 最佳防御:
- 采用SQL语句预编译和绑定变量,是防御SQL注入的最佳方法。
原因:采用了PreparedStatement,就会将sql语句:“select id, no from user where id=?” 预先编译好,也就是SQL引擎会预先进行语法分析,产生语法树,生成执行计划,也就是说,后面你输入的参数,无论你输入的是什么,都不会影响该sql语句的 语法结构了,因为语法分析已经完成了,而语法分析主要是分析sql命令,比如 select ,from ,where ,and, or ,order by 等等。所以即使你后面输入了这些sql命令,也不会被当成sql命令来执行了,因为这些sql命令的执行, 必须先的通过语法分析,生成执行计划,既然语法分析已经完成,已经预编译过了,那么后面输入的参数,是绝对不可能作为sql命令来执行的,只会被当做字符串字面值参数,所以sql语句预编译可以防御sql注入。
设备层
- 部署web应用防火墙
数据库层
- 对数据库操作进行监控。
其他防御方式:
- 正则过滤
- 使用白名单来规范化输入验证方法
1.2 XML实体注入(XXE)
漏洞描述:
XML注入类似于SQL注入,XML文件一般用作传输和存储数据及配置的,当允许引用外部实体时,在修改或新增数据时,没有对用户可控数据做转义,直接输入或输出数据,都会导致XML注入漏洞。
危害:
通过构造恶意内容,可导致读取任意文件、执行系统命令、探测内网端口、攻击内网网站等危害
**注意:**执行系统命令(安装expect扩展的PHP环境里才有)
漏洞产生原因:
- 允许引用外部实体
- 传输的数据包含了标签内容
- 修改数据时会覆盖缘由的标签
修复建议:
- 过滤用户提交的xml数据,对特殊字符进行转码

- 禁用开发语言提供的外部实体方法:
PHP:
1 | libxml_disable_entity_loader(true); |
JAVA:
1 | // 方法一 |
Python:
1 | from lxml import etree |
参考文献:
-
小试XML实体注入攻击
-
Web Hacking 101 中文版
https://wizardforcel.gitbooks.io/web-hacking-101/content/14.html -
OWASP XML防御备忘单
1.3 OS注入
风险等级:高危
漏洞描述:
网站应用程序在编写时未对用户提交至服务器的数据进行合法性校验,运行用户能够提交系统命令操作,会导致攻击者能控制整个服务器。
漏洞危害
攻击者可以执行任意操作系统命令,进行恶意攻击
修复建议:
- 禁止调用系统命令
- 通过输入检查,过滤用户输入。
- 根据需求进行编译转义。 在Linux/UNIX中,可将给定的字符串用单引号括起来,在windows中,可以将给定的字符用双引号括起来,使单引号中所有shell的特殊字符失去原来的意义。
- 不仅要在客户端过滤,也要在服务器端进行过滤。
- 要用最小权限去运行程序,不要给予程序多余的权限,最好只允许在特定的路径下运行,可以通过明确的路径运行命令。
- 在程序执行错误时不要显示与内部相关联的细节。
- 如果只允许运行有限的命令,使用白名单方式过滤。
- 对于需要运行命令的请求,尽可能减少外部数据的输入,比如,能传参数的就不要传命令行;web应用程 序,如果可以将一些数据保存在会话,就不要发给客户端。
- 如果存在下载文件,可以分配文件一个id号,通过id号来访问,而不通过文件名访问。如果允许输入文件名,就需要严格检查文件名的合法性,避免可能的命令注入。
- 在进程和操作系统之间强制实施严格边界的“监狱”或类似沙箱环境中运行代码。
1.4 SOAP注入漏洞
风险等级:高危
漏洞描述:
用户提交的数据直接插入到SOAP消息中,攻击者可以破坏消息的结构,从而实现SOAP注入。
漏洞危害:
攻击者可以改变应用程序的逻辑,修改数据。
修复建议:
在用户提交的数据被插入SOAP消息的实施边界进行过滤
1.5 XPATH注入漏洞
风险等级:高危
漏洞描述:
网站使用XPath访问数据,响应用户提交的输入。如果用户的输入未经过过滤就插入到XPath的查询中,攻击者就可以通过控制查询语句来破坏应用程序,或者获取未授权访问的数据。
漏洞危害:
攻击者可以改变应用程序的逻辑,修改数据。
修复建议:
1.在网页代码中对用户输入的数据进行严格过滤;
2.部署Web应用防火墙;
1.6 SMTP注入漏洞
风险等级:高危
漏洞描述:
在电子邮件功能中,攻击者可在会话中注入任意SMTP命令,完全控制应用程序的消息。
漏洞危害:
1)篡改用户的邮件内容
修复建议:
1)在客户端代码中对用户输入的数据进行严格过滤;
2)部署Web应用防火墙;
1.7 LDAP注入漏洞
风险等级:高危
漏洞描述:
LDAP是一种轻量级目录访问协议,可以用来保存信息。如果在查询语句中插入恶意代码,可以修改返回的结果
漏洞危害:
1)机密数据被窃取;
修复建议:
1)在查询中对用户输入的数据进行严格过滤;
2)部署Web应用防火墙;
1.8 HTTP消息头注入漏洞
漏洞描述:
用户控制的数据以不安全的方式插入到应用程序返回的HTTP消息头中,如果攻击者能够在消息头中注入换行符,就能在响应中插入其他HTTP消息头,并在响应主体中写入任意内容。
漏洞检测:
通过修改参数来判断是否存在漏洞。
漏洞危害:
利用HTTP消息头注入漏洞可以控制用户访问页面的返回结果,执行恶意代码。
修复建议:
1.不要把用户控制的输入插入到应用程序返回的HTTP消息头中;
2.部署Web应用防火墙。
2.1 在设置HTTP响应头的代码中,过滤回车换行(%0d%0a、%0D%0A)字符。
2.2 不采用有漏洞版本的apache服务器,同时对参数做合法性校验以及长度限制,谨慎的根据用户所传入参数做http返回包的header设置。
1.9 代码注入:
1.9.1 命令注入漏洞
风险等级:高危
漏洞描述:
命令执行漏洞是指代码未对用户可控参数做过滤,导致直接带入执行外部程序或系统命令实施攻击执行命令的代码中,对恶意构造的语句,可被用来执行任意命令。
漏洞危害:
黑客可在服务器上执行任意命令,写入后门,从而入侵服务器,获取服务器的管理员权限,危害巨大。
修复建议:
严格过滤用户输入的数据,禁止执行系统命令
1.9.2 文件包含漏洞
漏洞描述:
文件包含漏洞多数情况出现在PHP中,当然jsp中也存在,文件包含分为本地包含与远程包含。
漏洞危害:
- 绕过WAF上传木马文件
- 加载有害的远程内容,影响程序运行。
- 读取敏感文件信息。
漏洞修复:
- 关闭allow_url_fopen
- 避免使用include参数
- 使用web检测文件内容
1.10 DDE(CSV)注入
1.11 CRLF 注入
概念
CRLF 指的是回车符(CR,ASCII 13,\r,%0d) 和换行符(LF,ASCII 10,\n,%0a)。
利用
攻击者控制HTTP 消息头中的字符,向请求行或首部中的字段注入一些恶意的CRLF,这样我们就能注入一些会话首部字段(Cookie)或报文主体(HTML代码),所以CRLF Injection又叫HTTP响应拆分漏洞(HTTP Response Splitting),简称HRS
一般用于组合漏洞或waf绕过执行payload,如 ssrf redis getshell、短信轰炸限制绕过、会话国定漏洞测试、浏览器filter xss绕过等。
检测思路:
抓包——>在请求体url首部或其他头部中加入%0a{payload},如%0aSet-cookie:JSPSESSID%3Dhello——>响应返回信息中换行出现{payload}既存在。
危害:
-
缓存污染,它是一种场景,攻击者可以修改缓冲中的条目,并托管恶意页面(即包含 JavaScript)而不是合理的页面。
-
防火墙绕过,它是一种场景,请求被构造,用于避免安全检查,通常涉及 CRLF 和过大的请求正文。
-
请求劫持:它是一种场景,攻击者恶意盗取 HTTPOnly 的 Cookie,以及 HTTP 验证信息。这类似于 XSS,但是不需要攻击者和客户端之间的交互。
修复
过滤 \r 、\n 之类的行结束符,避免输入的数据污染其他 HTTP 首部字段。
二、请求伪造漏洞
2.1 SSRF
简介
SSRF,Server-Side Request Forgery,服务端请求伪造,是一种由攻击者构造形成由服务器端发起请求的一个漏洞。一般情况下,SSRF 攻击的目标是从外网无法访问的内部系统。而根据请求后续处理逻辑不同,又分为回显型SSRF和非回显型SSRF,回显型SSRF就是将访问到的信息响应返回给攻击者,非回显型SSRF则不会,但可以通过DNS log或访问开放/非开放的端口导致的延时来判断。
形成原因
由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤和限制。也就是说服务端能够对外发起网络请求的地方,都可能存在SSRF。如站点快照获取、收取邮箱邮件、文件处理、URL分享等。
攻击原理
通过控制功能中发起请求的服务来当做跳板机内网中其他服务。
危害:
- 最大的危害就是网络穿透,根据业务环境判断深入程序。
- 对外网、服务器所在内网、本地进行端口扫描,获取服务banner信息
- 攻击内网或本地的应用程序,(如溢出、Redis Getshell、内网web漏洞等)
- 内外网端口发送payload攻击内网服务(如weblogic、jboss、stauts2、sqli等)
- 利用file、gopher、dict协议读取本地文件、执行命令等。
- DOS攻击(请求大文件,一直保持keep-Alive Always)
出现的场景:
- 能够对外发起网络请求的地方,就可能存在 SSRF 漏洞
- 从远程服务器请求资源(Upload from URL,Import & Export RSS Feed)
- 数据库内置功能(Oracle、MongoDB、MSSQL、Postgres、CouchDB、redis、memcache)
- Webmail 收取其他邮箱邮件(POP3、IMAP、SMTP)
- 文件处理、编码处理、属性信息处理(ffmpeg、ImageMagic、DOCX、PDF、XML)
- 其他(https tls seesion)
SSRF漏洞的验证方法:
1)通过抓包分析发送的请求是否是由服务器的发送的,从而来判断是否存在SSRF漏洞
2)在页面源码中查找访问的资源地址 ,如果该资源地址类型为 www.baidu.com/xxx.php?image=(地址)的就可能存在SSRF漏洞
开发语言应用
可利用协议:
- file://
ssrf.php?url=file:///etc/password
- Dict://
dict://
ssrf.php?url=dict://attacker:11111/
- SFTP://
ssrf.php?url=sftp://example.com:11111/
- TFTP://
ssrf.php?url=tftp://example.com:12346/TESTUDPPACKET
- LDAP://
ssrf.php?url=ldap://localhost:11211/%0astats%0aquit
- Gopher://
一般情况:
- dict探测端口
- http获取指纹信息
- file协议读取内网文件
- Gopher打redis、fastcgi
PHP
SSRF出现常见函数cURL、file_get_contents、fsockopen()等
注:
file_get_contents的gopher协议不能 UrlEncode
file_get_contents关于Gopher的302跳转有bug,导致利用失败
curl/libcurl 7.43上gopher协议存在bug(截断),除v7.49外,7.45以上无此bug
. curl_exec()默认不跟踪跳转
file_get_contents() 支持php://input协议
python
urllib(urllib2)和requests库
JAVA
存在局限性,一般利用http协议来探测端口,利用file协议读取任意文件。常见的类中如HttpURLConnection,URLConnection,HttpClients中只支持sun.net.www.protocol里的所有协议:
http,https,file,ftp,mailto,jar,netdoc
JDK 1.8 移除gopher协议
JDK
1.7,可以看到有gopherfileftphttphttpsjarmailtonetdoc八种协议
防御
常见的修复方案如下:

常规修复
- 限制返回信息的,例如请求文件,只返回文件是否请求成功,没有请求成功到文件统一返回错误信息。
- 对请求地址设置白名单,只允许请求白名单内的地址。
- 禁用除http和https外的协议,如:file://,gopher://,dict://等
- 限制请求的端口为固定服务端口,如:80,443
代码层:
- 去除url中的特殊字符
- 判断是否属于内网ip
- 如果是域名的话,将url中的域名改为ip
- 请求的url为3中返回的url
- 请求时设置host header为ip
- 不跟随30x跳转(跟随跳转需要从1开始重新检测)
2.2 CSRF
跨站请求伪造,既CSRF,攻击者通过伪造来自受信任用户的请求,达到增加、删除、篡改网站内容的目的。
CSRF与XSS的区别:
| XSS | CSRF |
|---|---|
| XSS利用站点内的信任用户 | CSRF则通过伪装来自受信任用户的请求来利用受信任的网站 |
| 需要获取Cookie | 不需要盗取cookie而是直接利用 |
| 攻击者需要登录后台完成攻击。管理员可以看日志发现攻击者。 | 攻击一直是管理员自己实现的,攻击者只负责了构造代码。 |
XSS工作原理:
1 | 攻击者发现XSS漏洞——构造代码——发送给受害人——受害人打开——攻击者获取受害人的cookie——完成攻击 |
CSRF工作原理:
1 | 攻击者发现CSRF漏洞——构造代码——发送给受害人——受害人打开——受害人执行代码——完成攻击 |
漏洞条件:
- 受害者必须R陆过网站(或者有权限)
- 攻击者(或黑客)提供恶意链接受害者必须打开
- 网站除了验证Cookie,没有特殊验证方法
漏洞危害:
- 攻击者冒充用户/管理员,伪造请求,进行篡改、转账、改密码、发邮件、购买商品等非法操作。
- 可能与xss漏洞结合,盗取cookie或者Token

修复建议:
- 过滤用户输入,不允许发布含有站内操作URL的连接
- 改良站内API的设计,关键操作使用验证码,只接受POST其你去,GET请求应该只浏览而不改变服务器端资源。
- 对于web站点,将持久化的授权方法(例如cookie或者HTTP授权)切换为瞬时的授权方法(在每个from中提供隐藏field)
- 在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie
服务端的防御:
- 验证HTTP Referer字段
- 请求地址中条件Token并验证(token不放在cookie中,放在http请求参数中,服务端对其进行验证)
- 将token加入http头属性中,避免了token出现在浏览器中,被泄露。
客户端防御:
为了配置服务端对token的验证,那么客户端在访问时也需要生成token,这是利用js来给html中的链接和表单请求地址附加csrftoken代码,其中已定义token为全局变量,其值可以从session中得到。
跨站请求漏洞的危害与防御
2.3 URL Redirect漏洞(既URL重定向/跳转漏洞)
漏洞背景:
由于应用越来越多的需要和其他的第三方应用交互,以及在自身应用内部根据不同的逻辑将用户引向到不同的页面,譬如一个典型的登录接口就经常需要在认证成功之后将用户引导到登录之前的页面,整个过程中如果实现不好就可能导致一些安全问题,特定条件下可能引起严重的安全漏洞。
漏洞原因:
URL跳转漏洞是指后台服务器在告知浏览器跳转时,未对客户端传入的重定向地址进行合法性校验,导致用户浏览器跳转到钓鱼页面的一种漏洞。
对于URL跳转的实现一般会有几种实现方式:
- META标签内跳转
- javascript跳转
- header头跳转

应用场景:
常见于第三方授权登录功能,如QQ、百度、新浪等,可以在参数中传入Redirect_url地址时篡改成一个钓鱼恶意网址,就可以非法获取用户的授权信息。
有时也会用于突破长线的基于白名单方式的安全限制,如youku.com的视频,限制方式往往是检查URL是否是youku.com来实现,如果youku.com内含一个url跳转漏洞,将导致最终引入的资源属于不可信的第三方资源或者恶意站点,最终导致安全问题。
漏洞危害:
- web应用程序执行指向外部站点的重定向
- 攻击者可能会使用web服务器攻击其他站点,增加匿名性。
修复建议:
理论上讲,url跳转属于CSRF的一种,我们需要对传入的URL做有效性的认证,保证该URL来自于正确的地方,限制的方式同防止csrf一样可以包括:
代码层
- 在网页代码中需要对用户输入的数据进行严格过滤
- 服务端配置跳转白名单或域名白名单,只对合法的url做跳转
- 对请求参数做加密和签名,防止参数被篡改,服务端要能够合法解析url
- referer的限制
如果确定传递URL参数进入的来源,我们可以通过该方式实现安全限制,保证该URL的有效性,避免恶意用户自己生成跳转链接 - 加入有效性验证Token
我们保证所有生成的链接都是来自于我们可信域的,通过在生成的链接里加入用户不可控的Token对生成的链接进行校验,可以避免用户生成自己的恶意链接从而被利用,但是如果功能本身要求比较开放,可能导致有一定的限制。
设备层
- 部署web应用防火墙
三、文件处理漏洞
3.1 任意文件上传漏洞
网站存在任意文件上传漏洞,对文件上传功能没有进行格式限制,导致容易被黑客利用上传恶意脚本文件
漏洞危害:
- 攻击者通过此漏洞上传恶意脚本文件,对服务器的正常运行造成安全威胁
- 攻击者可上传可执行的webshell(如php、jsp、asp类型的木马病毒),或者利用目录跳转上传gif、html、config文件,覆盖原有的系统文件,导致获取系统权限的目的。
修复建议:
- 对上传文件格式进行严格校验及安全扫描,防止上传恶意脚本文件;
- 设置权限限制,禁止上传目录的执行权限
- 严格限制可上传的文件类型
- 严格限制上传的文件路径
- 文件扩展名服务端白名单校验
- 文件内容服务端校验
- 上传文件重命名
- 隐藏上传文件路径
3.2 任意文件下载
漏洞描述:
一些网站由于业务需求,往往需要提供文件查看或文件下载功能,但若对用户查看或下载的文件不做限制,则恶意用户就能够查看或
下载任意敏感文件,这就是文件查看与下载焉洞
漏洞危害:
- 下载服务器任意文件,如脚本代码、服务及系统配置文件等,可用得到的代码进一步代码审计,得到更多可利用漏洞
- 可能存在被攻陷、恶意利用的敏感信息泄漏。
- 攻击者可构造恶意请求下载服务器上的敏感文件,进而植入网站后门控制网站服务器主机。
如何查找任意文件下载漏洞:
- 查找传入文件名的参数:
2. 导入文件等参数,要是直接输入文件名,就有可能有注入点
3. 常见问题参数名:
RealPath, FilePath , filepath , Path , path ,inputFile, url, urls , lang , dis, data, readfile, filep, src menu, META-INF , WEB-INF - 代码中如何查找漏洞:
3. PHP为例,常见问题代码:
4. readfile
5. fopen
6. file_get_contents
常见敏感文件路径:
Windows:
C:\boot.ini———— //查看系统版本
C:\Windows\System32\inetsrv\MetaBase.xml———— //IIS配置文件
C:\Windows\repair\sam ————//存储系统初次安装的密码
C:\Program Files\mysql\my.ini ————//Mysql配置文件
C:\Program Files\mysql\data\mysql\use. MYD ————//Mysql root
C:\Windows\php.ini ————//php配置信息
C:\Windows\my.ini ————//MySQL配置信息Linux :
/root/.ssh/authorized_keys
/root/.ssh/id_rsa
/root/.ssh/id_ras.keystore
/root/.ssh/known_hosts
/etc/httpd/conf/httpd.conf
/root/.bash_history
/root/.mysql_history
/proc/self/fd/fd[0-9]*( 文件标识符 )
/proc/mounts
/porc/config.gz
/etc/passwd
/etc/shadow
/etc/my.cnf
修复建议:
一般根据自身业务需要修改,常见修复方法如下:
- 对文件下载进行过滤,过滤掉“ ./ ”、“ …/ ”、“ % ”等
- 对下载的文件路径进行严格控制,只允许下载某部分目录下的文件:
- 对下载文件后缀名做严格控制
- 升级您正在使用的 CMS 或插件至最新版本。
- 如果漏洞文件不再使用,请删除文件。
注意:删除前请做好备份。
3.3 File Operation-Web.xml漏洞
攻击者可以通过文件内容泄漏漏洞获取敏感文件的内容,或直接执行其指定的恶意脚本,进得Web服务器的控制权限。
漏洞危害:
- 文件内容泄漏漏洞允许攻击者读取服务器中的任意文件,或通过特殊的指令将脚本源码文件的内容合并至当前的文件中执行。
- 很多脚本语言允许通过特殊的指令(如PHP 通过require关键字)将其他脚本源码文件的内容合并至当前的文件中执行,如果这些特殊的指令在包含的文件路径中含有用户提交的数据,则恶意攻击者就有可能通过构造特殊的数据将WEB服务器限制访问的文件内容(如操作系统或某些重要应用的配置文件)包含进来并通过浏览器获取其内容,这种方式通常称为本地文件包含;如果应用程序的配置还允许包含远程的其他服务器上的文件,恶意攻击者就有可能构造特殊的脚本然后通过包含并予以执行,进而获取WEB应用的敏感数据或控制权。
修复建议:
- 如果可能,使用包含指令时显式指定包含的文件名称;
- 如果必须通过用户的输入指定包含的文件,则最好分析用户的输入,然后从文件白名单中显式地选择;
- 请对用户的输入进行严格的过滤,确保其包含的文件在预定的目录中或不能包含URL参数。
3.4 Zip Slip任意文件写漏洞
3.5 任意文件删除
四、访问控制漏洞
4.1 横向越权
4.2 垂直越权
4.3 后台弱口令漏洞
网站管理后台用户名密码较为简单或为默认,易被黑客利用。
漏洞危害:
- 攻击者利用弱口令登录网站管理后台,可任意增删文章等造成负面影响
- 攻击者可进一步查看网站信息,获取服务器权限,导致局域网(内网)被入侵。
修复建议:
- 对管理后台进行访问控制,修改后台弱口令,加强口令强度并定期修改。
- 增加验证机制,防爆破机制,限制ip+cookie访问次数。
4.3 后台登陆页面绕过
由于一些开发语言的不安全配置导致越权操作(如vue认证界面、shiro绕过漏洞等),可直接通过访问后台地址进行访问,绕过登陆限制
漏洞危害:
- 一旦入侵者发现后台url,便可进入后台页面,进行非法操作。
修复建议:
- 对后台所有url做好权限设置
- 禁止外网访问后台地址
4.4 验证机制缺陷漏洞
风险等级:中危
漏洞描述:
由于网站管理后台系统登录无验证码校验,可导致后台用户名密码被暴力破解。
漏洞危害:
1.攻击者可利用该漏洞无限次提交用户名密码,从而可以暴力破解后台用户名及密码;
2.暴力破解后登录其中一个帐号可进管理后台,攻击者登录网站后台任意增删文章等造成负面影响;
3.攻击者可进一步登陆后台查看网站信息、上传恶意脚本文件,获取服务器权限,导致局域网(内网)被入侵。
修复建议:
1.对该页面进行访问控制,禁止外网IP或非法IP访问后台页面,并增加验证码校验,加强帐号锁定机制。
五、会话管理漏洞
5.1 会话劫持
5.2 会话固定
六、XSS漏洞
XSS的漏洞主要成因是后端接收参数时未经过滤,导致参数改变了HTML的结构,可以在网站中插入任意代码,以获取网站管理员或者普通用户的cookie,隐藏运行网页木马,甚至获取浏览者主机操作权限,格式化浏览者的硬盘。
危害:
- 可以劫持浏览器用户的会话
- 窃取客户端cookies
- 网络钓鱼。
- 强制弹出广告页面、刷流量等
- 网页挂马、隐藏运行网页木马
- 进行恶意操作,如任意篡改页面信息、删除文档等
- 进行大量的客户端攻击,比如DDOS攻击
- 获取客户端信息,例如用户的浏览历史、真实IP、开放端口等
- 获取浏览者主机操作权限,进一步渗透网站
- 传播跨站脚本蠕虫
- 结合其他漏洞,如CSRF漏洞,进一步作恶。
6.1 反射型XSS
只是简单地把用户输入的数据“反射”给浏览器,恶意JS代码会直接在受害者主机上的浏览器执行。但需要用户配合点击,才能利用,且只能执行一次,所以也叫“非持久性攻击”
6.2 存储型XSS
会把用户输入的数据“存储”在服务器端,只要受害者浏览包含此恶意js代码的页面就会执行恶意代码,所以也叫“持久性xss”,常见留言板等可以提交展示用户输入内容的功能点。
6.3 DOM 型XSS
通过修改页面的DOM节点形成xss漏洞。
6.4 DOM 与反射型区别:
反射型和存储型,都需要与服务端交互的,即服务端将提交的内容反馈到了html源码内,导致触发xss,也就是说返回到html源码中可以看到触发xss的代码
而DOM型不与服务端交互的,只与客户端上的JS交互,也就是说提交的恶意代码,被放到了JS中执行。
根本区别: 输出点的不同。
6.4 修复建议
6.4.1 设置httponly
规定了不能使用js去获取cookie的内容,因此只能防御xss进行cookie劫持的问题。
Httponly是在set-cookie时标记的,可对单独某个参数标记也可对全部参数标记。
因为设置httponly的方法比较简单,使用也很灵活,并且对防御cookie劫持非常有用,因此已经渐渐成为一种默认的标准。
6.4.2 输入点检查:
输入的数据进行合法性检查:
1. 使用xss filter 与编译转义
XSS filter是一个文本文件,里面包含了允许被用户输入提交的字符(也包含不允许用户提交的字符)。
在用户输入的时候, 设置白名单与黑名单(推荐使用白名单),过滤敏感字符,结合编译转义,避免被浏览器当成JS代码执行。
XSS filter方式 配置编码,将一些敏感字符通过编码的方式改变原来的样子,避免被浏览器当成JS代码执行。编码方式如html编码、url、编码、16进制编码、javascript编码等。
2. 处理富文本
网页编辑器允许用户提交一些自定义的html代码,称为“富文本”。在富文本处防御xss漏洞,最简单有效的就是控制用户能使用的标签,限制为只能使用a、div等安全的标签。
- 针对特定的数据进行格式检查
- 针对输入点的检查最好放在服务器端实现。
6.4.3 输出点检查:
1. 对输入内容编码转义
2. 处理所有输出类型的XSS漏洞
xss漏洞本质上是一种html注入,也就是将html代码注入到网页中。那么其防御的根本就是在将用户提交的代码显示到页面上时做好一系列的过滤与转义。
6.4.4 其他:
1. 开发者应该严格按照openid和openkey的校验规则判断openid和openkey是否合法,且判断其它参数的合法性,不合法不返回任何内容。
2. 严格限制URL参数输入值的格式,不能包含不必要的特殊字符(%0d、%0a、%0D、%0A等)
七、安全配置错误
7.1 数据库运行出错
网站存在数据库运行出错,由于网页数据交互出错,攻击者可获取报错中的敏感信息。
漏洞危害:
- 机密数据被窃取
- 攻击者通过构造特殊URL地址,触发系统web应用程序报错,在回显内容中,获取网站敏感信息。
- 攻击者利用泄露的敏感信息,获取网站服务器web路径,为进一步攻击利用提供帮助。
修复建议
- 检查数据库缓存是否溢出,是否具有失效的配置管理、禁用一切不必要的功能。
- 对网站错误信息进行统一返回,模糊化处理。
7.2 Flash安全配置缺陷漏洞
网站存在Flash安全配置缺陷,该漏洞可导致跨域访问,让用户访问非法Flash文件。
7.3 敏感信息泄漏
由于网站运维人员疏忽,存放敏感信息的文件被泄露或由于网站运行出错导致敏感信息泄露,以及不对登录认证的敏感信息进行加密,敏感信息以明文形式进行传输,导致易被攻击者利用
一张图道出这个漏洞的危害情况

漏洞危害:
- 攻击者可直接下载用户的相关信息,包括网站的绝对路径、用户的登录名、密码、真实姓名、身份证号、电话号码、邮箱、QQ号等;
- 攻击者通过构造特殊URL地址,触发系统web应用程序报错,在回显内容中,获取网站敏感信息;
- 攻击者利用泄漏的敏感信息,获取网站服务器web路径,为进一步攻击提供帮助。
- 对未加密的敏感信息,攻击者可以直接窃取密钥、发起中间人攻击,或从服务器端窃取明文数据。
- 易造成用户敏感信息泄露与篡改。
修复建议:
- 对网站错误信息进行统一返回,模糊化处理
- 对存放敏感信息的文件进行加密并妥善储存,避免泄露敏感信息。
- 禁止缓存对包含敏感数据的响应
- 对传输过程中的敏感数据加密,且保证使用算法的安全,如使用加密连接SSL方式等。
- 对密码使用专用算法存储密码。
- 对于没必要存放的、重要的敏感数据,应当尽快清除,或者通过PCI DSS标记或拦截。未存储的数据不能被窃取。
7.4 ASP.net 错误事件
既Possible .Net Error Message
漏洞等级:中危
网站存在.net报错信息,由于网站未配置同一错误返回页面,导致aspx出错并显示出错误信息。
漏洞危害
- 攻击者可通过特殊的攻击向量,有可能泄露如绝对路径、源代码、sql语句等敏感信息,这些信息都有可能被进一步的利用攻击,造成更大的危害。
修复建议:
- 关闭PHP错误回显,或者修正代码。
- 在出错时,不要直接输出一条消息就完事,可重定向至一个专门的报错提示页面
在显示用户输入数据时注意HtmlEncode
参考文献:
针对IIS7以上的ASP.NET网站自定义错误页面与异常日志总结https://edi.wang/post/2014/1/11/iis7-aspnet-custom-error-best-practice
7.5 PHP 错误事件
既Possible PHP Error Message
网站存在Possible PHP Error Message,由于网站未配置统一错误返回页面,导致PHP出错并显示出错误信息。
漏洞危害:
- 攻击者可通过特殊的攻击向量,有可能泄露如绝对路径、源代码、sql语句等敏感信息,这些信息都有可能被进一步的利用攻击,造成更大的危害
修复建议:
- 关闭PHP错误回显,或者修正代码。
- 在出错时,不要直接输出一条消息就完事,可重定向至一个专门的报错提示页面
在显示用户输入数据时注意HtmlEncode
7.6 Application error message
信息泄漏是指因程序BUG,或者由于攻击者对程序的参数等输入接口进行填充非法的数据,使程序崩溃,输出一些调试信息以及源代码等数据。当攻击者得到此数据后,可以了解到很多隐私的敏感的数据,进而结合其他漏洞进行下一步的攻击。 信息泄漏分为多种泄漏方式,一般常见的为:
1、物理路径泄漏
当攻击者通过接口输入非法的数据时,应用程序出现错误,并返回网站物理路径。攻击者利用此信息,可通过本地文件包含漏洞直接拿到 webshell。
2、程序使用版本泄漏
通过传送大量的数据时,应用程序报错,并返回应用程序版本。攻击者利用此信息,查找官方漏洞文档,并利用现有expolit code实施攻击。
3、源代码泄漏
利用程序扩展名解析缺陷,访问隐藏的文件,并获取源代码。或者通过程序BUG,直接返回源代码,获取重要数据,进而实施下一步攻击。
4、其他信息
如返回所使用的第三方软件信息,比如程序使用了zend framework、数据库使用的 mysql 等。
漏洞描述:
这个漏洞是因为前台参数传到后台的时候属性没有对应上导致
修复建议:
1.该后台对应的实体中需要有各自属性的set/get方法。
2.将这两个属性放置到try…catch…语句中就行了。
3.如果还是不可以那就得前台代码对这两个属性进行验证,确保传递到后台参数的格式类型与后台的数据类型对的上。
7.7 SVN源代码泄漏
由于目标网站没有及时清除SVN服务器连接时的残留信息,导致存在此漏洞
漏洞危害:
- 攻击者可利用该漏洞下载网站的源代码,获取数据库的连接密码等敏感信息
- 攻击者可通过源代码分析出新的系统漏洞,从而进一步入侵系统。
修复建议:
- 删除指定SVN生成的各种文件,如"/.svn/entries"等
7.8 CVS信息泄漏
由于目标网站没有及时清除CVS服务器连接连接时的残留信息,导致存在此漏洞。
漏洞测试(借鉴)
访问/cvs/等页面,若出现下图内容,则表示存在此漏洞。

前面是用户名 后面是服务器地址
漏洞危害:
- 攻击者可利用该漏洞下载网站的源代码,获得数据库的连接密码等敏感信息。
- 攻击者可通过源代码分析出新的系统漏洞,从而进一步入侵系统。
修复建议
删除指定CVS生成的各种文件,如“/cvs/root”等。
7.9 Elasticsearch未授权访问漏洞
漏洞描述
elasticsearch 是一款java编写的企业级搜索服务,启动此服务默认会开放9200端口,可被非法操作数据。
漏洞检测
检测:默认端口9200
相当于一个API,任何人访问这个地址,就可以调用api,进行数据的增删改操作。

漏洞危害
可被非法操作数据,对网站数据造成影响。
修复方案
1.关闭9200端口
2.防火墙上设置禁止外网访问此端口。
7.10 crossdomain.xml配置不当漏洞
漏洞描述:
网站根目录下的文件crossdomain.xml指明了远程flash是否可以加载当前网站的资源(图片、网页内容、flash等)。
如果配置不当,可能带来CSRF攻击。如下图所示:

检查方法:
访问http://[domain]/crossdomain.xml
修复建议:
对于不需要外部加载资源的网站,crossdomain.xml中更改allow-access-from的domain属性为域名白名单。
修复大致样本参考如下(备注:示例中的app10000.qzoneapp.com,app10000.imgcache.qzoneapp.com请修改为自己指定的站点):
1 | <?xml version="1.0"?> |
八、其他
8.1 目录遍历漏洞
风险等级:中危
漏洞描述
通过该漏洞可以获取系统文件及服务器的配置文件。利用服务器API、文件标准权限进行攻击。
漏洞危害
- 通过遍历、穷举等方式非法获取到文件目录结构
- 通过敏感目录下载敏感文件。
- 如果存在包含用户、密码、数据库等敏感信息,可能会导致管理后台登陆、数据库连接等危险操作。
修复建议
- 修改配置文件,去除中间件(如IIS、Apache、tomcat)的文件目录索引功能
- 设置目录权限(禁止读写等)
- 在每个目录下创建一个空的index.html页面。
8.2 未过滤HTML代码漏洞
由于页面未过滤HTML代码,攻击者可通过精心构造XSS代码(或绕过防火墙防护策略),实现跨站脚本攻击等。
漏洞危害:
- 恶意用户可以使用JavaScript、VBScript、ActiveX、HTML语言甚至Flash利用应用的漏洞,从而获取其他用户信息;
- 攻击者能盗取会话cookie、获取账户、模拟其他用户身份,甚至可以修改网页呈现给其他用户的内容。
修复建议
- 严格过滤用户输入的数据
- 参考跨站脚本漏洞修复方案。
8.3 FCK 编辑泄露漏洞
漏洞描述
利用此漏洞攻击者可访问编辑器页面,上传图片
漏洞危害
- 由于网站编辑器没有对管理员登录进行校验,导致任意用户访问编辑器。
- 利用编辑器漏洞查看网站全硬盘目录
修复建议
对编辑器页面进行访问控制,禁止未授权访问,并升级FCK编辑版本。
8.4 FCKeditor任意文件上传漏洞
FCKeditor版本低于或等于2.4.3时网站存在任意文件上传漏洞,可以利用该漏洞上传任意文件。
漏洞危害
- 由于目录网站未做上传格式的限制,导致网站、数据库和服务器有被入侵的风险。
- 可能导致网站被攻击者控制,网站数据被窃取、网页被篡改等。
修复建议
- 设置FCKeditor编辑器相关页面在未授权的前提下无法正常访问,和限制FCK上传文件的格式。
- 下载并更新至FCKeditor的最新版本。
8.5 Unicode 编码转换漏洞
漏洞等级:中危
该漏洞由于Unicode在编码转换过程中会忽略某些字符,导致攻击者可插入该字符绕过安全设备的检测。

漏洞危害
- 黑客可通过插入特殊字符,可拆分攻击的关键词,绕过安全设备的检测。
- 利用unicode编码转换绕过XSS过滤器
修复建议
- 修改中间件,过滤特殊字符。
- 部署Web应用防火墙
8.6 发生内部错误
漏洞描述:
500 Internal Server Error。
漏洞危害:
攻击者向服务器提交精心构造的恶意数据后,有可能导致服务器出现内部错误、服务器宕机或数据库错乱。
修复建议:
- 严格过滤用户输入的数据
- 服务器错误同一模糊处理,或者跳转到首页/404页面。
参考文献:
内部服务器500错误(500 Internal server error)内部服务器500错误(500 Internal server error) 总结
http://blog.windigniter.com/2013/11/500-internal-server-error/
8.7 旁站攻击漏洞:
多家网站在同一台服务器上,因一个网站存在致命高危漏洞,导致整台服务器被入侵。
漏洞危害:
- 服务器上的所有网站均可被利用获取控制权限,从而达到网站任意增删改恶意操作、数据盗取等非法操作
- 攻击者可通过旁站服务器漏洞进入相应的内网,进一步内网渗透,拿下整个网络服务器。
修复建议:
- 修补同一台服务器上的其他网站漏洞
- 建议每个网站单独服务器运行。
- 定时对被引入网站的资源文件进行篡改检测,如果被篡改,则修正引入资源。
8.8 HPP漏洞:
即http参数污染,它是web容器处理http参数时的问题。
比如访问URL:http://www.xxx.com/index.php?str=hello此时,页面显示hello。但如果访问:http://www.xxx.com/index.php?str=hello&str=world&str=nmask此时,页面显示nmask,把前面参数的值给覆盖了,这就是http参数污染。
漏洞危害:
用来绕过WAF
修复建议:
1.修改web容器处理机制
8.9 Git源代码泄露漏洞
漏洞描述
服务器将.git文件放在了web目录下,导致可以访问git文件内容,获取源代码。
漏洞验证
验证访问网站.git目录:

可以看到git目录可以被访问,即存在此漏洞。
漏洞危害
可以通过此漏洞,获取项目源代码。
漏洞修复
1.删除网站目录下的.git文件
2.中间件上设置.git目录访问权限,禁止访问
3.防火墙上设置禁止访问此目录
8.10 PHPInfo()信息泄漏漏洞:
漏洞描述:
Web站点的某些测试页面可能会使用到PHP的phpinfo()函数,会输出服务器的关键信息。如下图所示:

检测方法:
访问http://[ip]/test.php 以及http://[ip]/phpinfo.php看是否成功。
修复方案:
删除该PHP文件。
8.9 短文件名泄漏漏洞
漏洞等级:中危
漏洞描述:
该漏洞由于Windows处理较长文件名时为方便,使用较短的文件名代替,攻击者可利用该漏洞尝试获取网站服务器下的文件名。
漏洞危害:
黑客可通过该漏洞尝试获取网站服务器下存放文件的文件名,达到获取更多信息来入侵服务器的目的。
修复建议:
- 修改Windows配置,关闭短文件名功能。
- 部署Web应用防火墙,防止攻击者批量尝试。
附录一: 漏洞定级:
DREAD模型:

DREAD模型,包括5个方面:
DREAD模型5个方面
a.危害性 (damage):如果被攻击了,会造成怎样的危害
b.持续生产 (reproducibility):攻击后恢复运营的简易度?
c.难度系数 (exploitability): 实施此项攻击的难度是如何?
d.受影响用户数 (affected users): 有多少用户会受到此项攻击影响?
e.发现系数 (discoverability): 这项威胁是否容易被发现?
如何计算漏洞等级:
按照DREAD标准,计算给定威胁的值(1-3),结果范围为5-15.
威胁值标准
12-15的威胁值为高度危险
8-11的威胁值为中度危险
5-7的威胁值为帝都危险
道哥的《白帽子讲web安全》给出了如下例子:
a.网站登陆页面存在暴利破解:D(3)+ R(3) + E(3) + A(3) + D(3) = 15
b.密码找回存在逻辑漏洞:D(3)+ R(3) + E(3) + A(3) + D(2) = 14
c.密码可能被嗅探:D(3) + R(3) + E(3) + A(1) + D(3) = 13
d.服务端脚本漏洞(如SQL等): D(3) + R(3) + E(2) + A(3) + D(1) = 12
e.钓鱼网站:D(3) + R(1) + E(3) + A(2) + D(3) = 12
f.XSS或其他客户端威胁:D(3) + R(2) + E(2) + A(2) + D(2) = 11
g.病毒或木马:D(3) + R(1) + E(2) + A(1) + D(1) = 8
实践中
实践中要将DREAD模型、企业核心业务、企业业务性质和漏洞本身的危害来梳理漏洞类型的默认等级。
总结:
漏洞定级的三个维度:
漏洞影响、可利用性、受影响范围
确定漏洞等级三个维度的综合评判计算公式:
基础分值+漏洞影响分值+可利用性分值+受影响分值=最终漏洞等级
附录二:参考文献
- Vulnerability box
https://book.nmask.cn/ - URL重定向/跳转漏洞
http://drops.xmd5.com/static/drops/papers-58.html - 浅谈跨站脚本攻击与防御
https://thief.one/2017/05/31/1/ - 国内外敏感信息泄露案例汇总分析
https://www.aqniu.com/industry/26957.html - 从零开始学CSRF
http://www.freebuf.com/articles/web/55965.html - 白帽子挖洞—跨站请求伪造(CSRF)篇http://www.freebuf.com/column/153543.html
- 骚姿势:当XSS与CSRF相遇
http://www.freebuf.com/column/184589.html - 100件xss能做到的事情,你知道多少?
https://pockr.org/guest/activity?activity_no=act_017d460d4e5988dad2&speech_no=sp_5b8b031ee65e0f6e41 - 针对IIS7以上的ASP.NET网站自定义错误页面与异常日志总结https://edi.wang/post/2014/1/11/iis7-aspnet-custom-error-best-practice
- 内部服务器500错误(500 Internal server error)内部服务器500错误(500 Internal server error) 总结
http://blog.windigniter.com/2013/11/500-internal-server-error/ - 分类:旁站攻击https://www.219.me/posts/category/security/%E6%94%BB%E9%98%B2%E5%AE%9E%E9%AA%8C%E5%AE%A4/%E6%97%81%E7%AB%99%E6%94%BB%E5%87%BB
-------------------------------------------------------------------------------- If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. If the images used in the blog infringe your copyright, please contact the author to delete them. Thank you !