大家好，我是老李。最近工作有点忙，没有怎么更新内容了，趁今天周末休息，正好和大家聊聊常见的Web安全常见漏洞修复方法。

SQL注入

在服务器端要对所有的输入数据验证有效性。
在处理输入之前，验证所有客户端提供的数据，包括所有的参数、URL和HTTP头的内容。
验证输入数据的类型、长度和合法的取值范围。
使用白名单验证允许的输入字符而不是黑名单。
在危险字符输入后进行转义或编码。
明确所有输入正确的字符集。
不使用动态拼接的SQL语句，如果使用对特殊字符进行转义。
设置最小权限运行程序

OS命令注入

不仅要在客户端过滤，也要在服务器端过滤。
要用最小权限去运行程序，不要给予程序多余的权限，最好只允许在特定的路径下运行，可以通过使用明确运行命令。
在程序执行出错时，不要显示与内部实现相关的细节。
如果只允许运行有限的命令、使用白名单方式过滤。
对于需要运行命令的请求，尽可能减小需要从外部输入的数据。比如：传参数的地方不要传命令行。
有下载文件，给文件分配一个ID号来访问文件，拒绝文件名访问。如果需要用文件名，严格检测文件的合法性。

XPath注入

在服务器端开始处理用户提交的请求数据之前，对输入的数据进行验证，验证每一个参数的类型、长度和格式。
对于系统出现的错误信息，以IE错误编码信息替换，屏蔽系统本书的出错信息，这样可以向攻击者提供更少的信息进行下一步注入攻击。
检查是否有特殊字符，如果有特殊字符 ，就转义特殊字符或者替换。例：单引号、双音哈都转义或者替换。
XPath查询参数化，编译构建XPath表达式，将数据输入以 变量形式 传递。
敏感信息如密码之类，使用哈希值较长的算法处理。

LDAP注入

使用转义特殊字符和白名单来验证输入。

JSON注入

在特殊字符前加反斜杠()进行转义
使用Javascript编码
使用HTML编码

XSS

在输入过滤，在显示的地方做输出编码。
使用一个统一的规则做输出编码
富文本框，使用白名单控制输入。
使用HTTPOnly标志

CSRF

重要功能增加确认操作或重新认证，例如支付交易、修改手机号码等
加验证码
每个会话中使用强随机令牌（token）来保护。
检验HTTP Referer

会话攻击

采用强算法生成会话ID，会话ID必须具有随机性和不可预测性，长度至少为128位。
设定会话过期时间，如：在一定时间内没有与应用交互，设定在登录一定时间内要重新输入验证用户名密码，如一天等。
设置好Cookie的两个属性：secure和HttpOnly来防御嗅探和阻止JS操作。

身份认证

在用户注册时强制用户输入较高强度密码、
登录认证错误信息显示登录失败，用户名或 密码错误。
防止撞库等攻击，应该登录三次失败后下一次登录以5秒倍数，4次登录失败，让用户输入验证码。
如果每分钟进行几十次尝试登录，应该被阻止一段时间（如20分钟），给出清楚明白的信息，说明为什么会阻止登录一段时间。
使用HTTPS请求传输身份验证和密码、身份证、手机号码，邮箱等数据。
当密码重置时，以短信方式通知用户
用户账号上次使用信息在下一次成功登陆时向用户报告。
在执行关键操作（如：修改登录密码、支付密码、邮箱、手机号码等）使用多因子身份验证。

直接对象引用

使用的唯一标识可以通过随机数生成以难以猜测。
在进行页面显示或做处理之前对用户权限进行检查。
权限信息保存在session中。

Tomcat安全配置

Tomcat以没有特权的用户账户和组运行，没有执行交互shell命令权限。
Tomcat运行的版本必须打了所有安全补丁的版本。
Tomcat默认的例子相关路径和文件必须删除。
Tomcat管理员默认密码必须被修改成复杂密码。
页面出现信息不能显示Tomcat的版本信息和系统信息。
Tomcat配置文件执启用安全的http方法，如：GET POST。
应用程序和管理程序使用不同的端口。
部署前删除测试代码文件。
删除无用的文件如：备份文件、临时文件等。
配置文件中没有默认用户和密码。
不要在robot.txt中泄露目录结构。

Apache安全配置

选择漏洞较少的apache版本。
隐藏Apache版本号。
删除Apache欢迎页面。
配置只允许访问Apache的Web目录
应用程序和管理程序使用不同的端口。
管理额控制台必须使用SSL协议。
部署前删除测试代码文件。
删除无用的文件如：备份文件、临时文件等。
配置文件中没有默认用户和密码。
不要在robot.txt中泄露目录结构。

数据库通用配置

修改数据库默认用户名和密码。
数据库用户的密码要符合一定的复杂度。
访问数据库的用户要赋予所需要的最小权限。
启动应用的系统用户必须是专用的，没有系统级别权限的用户和组。

绕过认证

对登录后可以访问的URL做是否登录检查，如果没有登录将跳转到登录页面。
对于敏感信息的请求如登录时、修改密码等请求一定要用HTTPS协议。

越权访问

验证一切来自客户端的参数，重点是和权限相关的参数，比如用户ID或者角色权限ID等。
session ID 和认证的token做绑定，放在服务器的会话里，不发送给客户端。
对于用户登录后涉及用户唯一信息的请求，每次都要验证检查所有权，敏感信息页面加随机数的参数，防止浏览器缓存内容。
把程序分成匿名，授权和管理的区域，通过将角色和数据功能匹配。
不适用参数来区分管理员和普通用户。

文件上传

上传的路径要限制在固定路径下。
上传文件路径只给只读和写权限，不需要执行权限。
服务端文件类型要使用白名单过滤，后台不应有添加扩展名类型功能；通过配置文件添加文件类型。
文件上传使用自己的命名规则重新命名上传的文件。

文件目录遍历下载

使用ID替换文件夹和文件名。

网站重定向或转发

验证重定向的URL。
使用白名单验证重定向目标。
网站内重定向使用相对路径URL。
重定向或者转发之前，要验证用户是否有权限访问目标URL。

业务逻辑漏洞

应用系统必须确保所有输入和传递的时候必须经过有效验证，不仅仅是在刚进入应用系统的时候进行数据验证。应用程序应该有检查功能，避免攻击者可以通过预测、操作参数或者利用隐藏的功能（例如调试）来阻碍操作或者改变业务逻辑工作流程。

应用需要对输入进行检查，不允许用户直接提交未经过验证的数据到服务器，因为这些数据来不可编辑的控件，或者用户没有前端提交的权限，任何可编辑控件必须有阻止恶意的写入或修改的功能。开发应用的时候需要注意时间处理问题。攻击者可以简单地通过了解不同的处理时间、结果来获取一些参数，所以虽然他们提交的结果也在相同的时间，符合规则，但却添加了其他步骤或者处理。

应用程序需要有阻止攻击者通过延长允许的交易时间的功能，这种情况可以在操作超过规定的时间后通过取消或者重置交易。应用程序需要能够过滤检测的业务逻辑：当一个功能或者操作只允许被执行有限的几次 或者用户不再能够执行这个功能的时候，应用需要能够检测出来。为了阻止用户过多次的执行某个功能， 应用程序可以通过类似缓存这种机制来控制，或者使用不允许用户过多次执行功能的机制。

应有用户正确的按照业务流程来完成每一个步骤的检测机制，这样可以阻止黑客在业务流程中通过跳过、绕过、重复任何业务流程中的工序检查。开发这部分业务逻辑的时候应该测试一些无用或者误用的测试用例，当没有按照正确的顺序完成正确的步骤的时候，就不能成功完成业务流程。

转载自https://www.secquan.org/Share/1071270

看见最新的漏洞建议是18年的，所以自己也发一个最新的，整理不易。#

目录

• SQL注入
• OS命令注入
• XPath注入
• LDAP注入
• JSON注入
• XSS
• CSRF
• 会话攻击
• 身份认证
• 直接对象引用
• Tomcat安全配置
• Apache安全配置
• 数据库通用配置
• 绕过认证
• 越权访问
• 文件上传
• 文件目录遍历下载
• 网站重定向或转发
• 业务逻辑漏洞
• 转载自https://www.secquan.org/Share/1071270

问题归纳#
1.1 web安全#
1.1.1 sql注入#
1.1.1.1 漏洞描述#
SQL注入攻击主要是由于程序员在开发过程中没有对客户端所传输到服务器端的参数进行严格的安全检查，同时SQL语句的执行引用了该参数，并且SQL语句采用字符串拼接的方式执行时，攻击者将可能在参数中插入恶意的SQL查询语句，导致服务器执行了该恶意SQL语句。SQL注入漏洞主要影响是攻击者可利用该漏洞窃取数据库中的任意内容，在某些场景下，攻击者将有可能获得数据库服务器的完全控制权限。

1.1.1.2 修复建议#
修改Web应用服务的软件部分，增加对客户端提交数据的合法性验证，至少严格过滤SQL语句中的关键字，并且所有验证都应该在服务器端实现，以防客户端（IE页面代码部分）控制被绕过。

验证GET、POST、COOKIE等方法中URL后面跟的参数，需过滤的关键字为：

[1] ' 单引号

[2] " 双引号

[3] ' 反斜杠单引号

[4] " 反斜杠双引号

[5] ) 括号

[6] ; 分号

[7] -- 双减号

[8] + 加号

[9]SQL关键字，如select，delete，drop等等，注意对于关键字要对大小写都识别，如:select ;SELECT;seLEcT等都应识别

建议降低Web应用访问使用较低权限的用户访问数据库。不要使用数据库管理员等高权限的用户访问数据库。

1.1.2 跨站脚本攻击（xss）#
1.1.2.1 漏洞描述#
跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。在不同场景下，XSS有相应不同的表现形式，主要分为反射型、存储型以及DOM型的跨站脚本攻击，所造成的影响主要是窃取用户登录凭证（Cookies）、挂马攻击、页面访问挟持等。

1.1.2.2 修复建议#
建议过滤的关键字为：

[1] ' 单引号

[2] " 双引号

[3] / 斜杠

[4] \ 反斜杠

[5] ) 括号

[6] ; 分号

[7] [ 中括号

[8] < 尖括号

[9] > 尖括号

比如把<编码为<

在cookie中加入httponly属性可以在一定程度上保护用户的cookie，减少出现XSS时损失。

1.1.3 XML外部实体（XXE）注入#
1.1.3.1 漏洞概述#
XXE Injection即XML External Entity Injection,也就是XML外部实体注入攻击。漏洞是在对非安全的外部实体数据进⾏行处理时引发的安全问题。在XML1.0标准⾥里,XML文档结构里定义了实体(entity)这个概念，实体可以通过预定义在文档中调用,实体的标识符可访问本地或远程内容。如果在这个过程中引入了“污染”源,在对XML文档处理后则可能导致信息泄漏、文件读取、命令执行等安全问题。

1.1.3.2 修复建议#
对于PHP，常见的XML解析方法有：DOMDocument、SimpleXML、XMLReader，这三者都基于 libxml 库解析 XML，所以均受影响，xml_parse 函数则基于 expact 解析器，默认不载入外部 DTD ，不受影响。可以在php解析xml文件之前使用libxml_disable_entity_loader(true)来禁止加载外部实体（对上述三种 XML 解析组件都有效），并使用libxml_use_internal_errors()禁止报错；

对于Java，设置

DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();

dbf.setExpandEntityReferences(false);

对用户的输入做过滤，如<、>、'、"、&等

1.1.4 跨站点伪造请求（CSRF）#
1.1.4.1 漏洞概述#
CSRF（Cross-Site Request Forgery，跨站点伪造请求）是一种网络攻击方式，该攻击可以在用户毫不知情的情况下以用户自身的名义伪造请求发送给受攻击站点，从而在未授权的情况下执行在权限保护之下的操作。具体来讲，可以这样理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

1.1.4.2 修复建议#
检测HTTP header中的referer字段。服务器可以查看referer是否为自己的站点，如果不是，则拒绝服务。

在重要请求中的每一个URL和所有的表单中添加token

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

SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。最终将可能导致，攻击者可通过外网服务器端利用该漏洞访问内网服务器端的资源。

1.1.5.2 修复建议#
过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。

统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。

限制请求的端口为http常用的端口，比如80,443,8080,8090。

禁用不需要的协议。仅仅允许http和https请求。可以防止类似于file:///, gopher://,ftp://等引起的问题。

过滤内网ip，限制访问内网

1.1.6 任意文件上传#
1.1.6.1 漏洞概述#
任意文件上传漏洞主要是由于程序员在开发文件上传功能时，没有考虑对文件格式后缀的合法性进行校验或只考虑在应用前端（Web浏览器端）通过javascript进行后缀校验，攻击者可上传一个包含恶意代码的动态脚本（如jsp、asp、php、aspx文件后缀）到服务器上，攻击者访问该脚本时服务器将对包含恶意代码的动态脚本解析，最终执行相应的恶意代码。该漏洞最终将可能直接影响应用系统的服务器安全，攻击者可通过所上传的脚本完全控制服务器。

1.1.6.2 修复建议#
对上传文件格式进行严格校验及安全扫描，防止上传恶意脚本文件；

设置权限限制，禁止上传目录的执行权限；

严格限制可上传的文件类型；

严格限制上传的文件路径。

文件扩展名服务端白名单校验。

文件内容服务端校验。

上传文件重命名。

隐藏上传文件路径。

1.1.7 任意文件下载或读取#
1.1.7.1 漏洞概述#
任意文件下载或读取漏洞主要是由于应用系统在提供文件下载或读取功能时，在文件路径参数中直接指定文件路径的同时并没有对文件路径的合法性进行校验，导致攻击者可通过目录跳转(..\或../)的方式下载或读取到原始指定路径之外的文件。攻击者最终可通过该漏洞下载或读取系统上的任意文件，如数据库文件、应用系统源代码、密码配置信息等重要敏感信息，造成系统的敏感信息泄露。

1.1.7.2 修复建议#
对path参数进行过滤，依次过滤“.”、“..”、“/”、“\”等字符。

或者对于下载文件的目录做好限制，只能下载指定目录下的文件，或者将要下载的资源文件路径存入数据库，附件下载时指定数据库中的id即可，id即对应的资源。

1.1.8 任意目录遍历#
1.1.8.1 漏洞概述#
任意目录遍历主要原因是由于应用系统所提供的目录浏览或文件浏览功能中，在处理当前路径参数时没有对参数进行合法性校验，攻击者可通过目录跳转的方式（../或..\）浏览预想之外的目录信息。攻击者将可能利用该漏洞访问应用系统的任意文件目录，导致可浏览敏感目录下的文件信息，造成敏感信息泄露。

1.1.8.2 修复建议#
对参数进行过滤，依次过滤“.”、“..”、“/”、“\”等字符。
1.1.9 .svn/.git源代码泄露#
1.1.9.1 漏洞概述#
.svn/.git源代码泄露主要原因是由于应用系统开发人员或运维管理人员在对应用系统进行版本迭代更新时，没有及时对代码版本维护程序(svn或git)中所产生的代码索引或代码库文件进行及时清理，攻击者可通过读取该代码索引或代码库文件访问并下载应用系统的源代码信息，最终导致应用系统的源代码信息遭到泄露，攻击者可进一步通过源代码审计的方式挖掘应用系统中存在的安全隐患。

1.1.9.2 修复建议#
开发人员在使用 SVN/Git 时，严格使用导出功能，禁止直接复制代码部署上线。

在不影响代码运行的情况下，删除线上代码中所有目录下的 .svn/.git 目录。

1.1.10 信息泄露#
1.1.10.1 漏洞概述#
信息泄露主要是由于开发人员或运维管理人员的疏忽所导致。如未及时删除调试页面、未关闭程序调试功能、未屏蔽程序错误信息、备份文件未删除、数据库备份文件未删除、未屏蔽敏感数据信息等多个方面所导致的不同严重程度的信息泄露。攻击者可通过所掌握的信息进一步分析攻击目标，从而有效发起下一步的有效攻击。

1.1.10.2 修复建议#
对身份验证时传输的用户名密码等作加密处理，为了防止重放攻击可以在验证时加个随机数，以保证验证单次有效。

关闭错误输出，防止调试信息泄露，或者当web应用程序出错时，统一返回一个错误页面或直接跳转至首页

合理设置服务器端各种文件的访问权限

尽量避免跨域的数据传输，对于同域的数据传输使用xmlhttp的方式作为数据获取的方式，依赖于javascript在浏览器域里的安全性保护数据。如果是跨域的数据传输，必须要对敏感的数据获取做权限认证，例如对referer的来源做限制，加入token等

1.1.11 PHPinfo界面发现#
1.1.11.1 漏洞概述#
phpinfo泄露主要是由于开发人员或运维管理人员的疏忽所导致。如未及时删除调试页面、未关闭程序调试功能、未屏蔽程序错误信息、备份文件未删除、数据库备份文件未删除、未屏蔽敏感数据信息等多个方面所导致的不同严重程度的信息泄露。Web站点的某些测试页面可能会使用到PHP的phpinfo()函数，会输出服务器的关键信息，从而造成信息泄露，攻击者可通过所掌握的信息进一步分析攻击目标，从而有效发起下一步的有效攻击。

1.1.11.2 修复建议#
开发人员在使用phpinfo界面时，严格使用导出功能，禁止直接复制代码部署上线。

在不影响代码运行的情况下，删除线上代码中所有目录下的phphinfo目录。

1.1.12 IIS短文件名泄露#
1.1.12.1 漏洞概述#
Internet Information Services（IIS，互联网信息服务）是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。Microsoft IIS在实现上存在文件枚举漏洞，攻击者可利用此漏洞枚举网络服务器根目录中的文件。危害：攻击者可以利用“~”字符猜解或遍历服务器中的文件名，或对IIS服务器中的.Net Framework进行拒绝服务攻击。

　　黑客可通过该漏洞尝试获取网站服务器下存放文件的文件名，达到获取更多信息来入侵服务器的目的。

1.1.12.2 修复建议#
修改Windows配置，关闭短文件名功能。

关闭NTFS 8.3文件格式的支持。该功能默认是开启的，对于大多数用户来说无需开启。

如果是虚拟主机空间用户,可采用以下修复方案：

　 1） 修改注册列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1(此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除)。

　　2）如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 --- Web 服务扩展 - ASP.NET 选择禁止此功能。

　　3）升级net framework 至4.0以上版本。

将web文件夹的内容拷贝到另一个位置，比如D:\www到D:\www.back，然后删除原文件夹

D:\www，再重命名D:\www.back到D:\www。如果不重新复制，已经存在的短文件名则是不会消失的。

1.1.13 slow http Dos拒绝服务#
1.1.13.1 漏洞概述#
按照设计，HTTP协议要求服务器在处理之前完全接收请求。如果HTTP请求没有完成，或者传输速率非常低，服务器会保持其资源忙于等待其余数据。如果服务器保持太多的资源忙，这将造成一个拒绝服务。严重者一台主机即可让web运行缓慢甚至是崩溃！

1.1.13.2 修复建议#
对于 Apache 可以做以下优化：

　　设置合适的 timeout 时间（Apache 已默认启用了 reqtimeout 模块），规定了 Header 发送的时间以及频率和 Body 发送的时间以及频率

　　增大 MaxClients(MaxRequestWorkers)：增加最大的连接数。根据官方文档，两个参数是一回事，版本不同，MaxRequestWorkers was called MaxClients before version 2.3.13.Theold name is still supported.

　　默认安装的 Apache 存在 Slow Attack 的威胁，原因就是虽然设置的 timeoute，但是最大连接数不够，如果攻击的请求频率足够大，仍然会占满Apache的所有连接

1.1.14 T甲骨文Javaserver faces的多个漏洞#
1.1.14.1 漏洞概述#
甲骨文的JavaServer Faces包含多个漏洞，可能允许攻击者获得敏感信息。亚历克斯Kouzemtchenko和Coverity的安全研究实验室漏洞报告的乔恩Passki指出甲骨文的JavaServer Faces包含以下漏洞：偏目录遍历通过资源标识符（CWE-22）：存在缺陷，其允许在应用程序内的目录遍历。目录遍历是有限的，它不能被用来从应用逃脱和访问应用服务器上的任意文件。偏目录遍历通过库名称（CWE-22）。存在缺陷，其允许在应用程序内的目录遍历。目录遍历是有限的，它不能被用来从应用逃脱和访问应用服务器上的任意文件。

1.1.14.2 修复建议#
建议更新版本，更新公告中列出的建议关键路径的更新 - 2013年10月为CVE-2013-3827

1.1.15 CRLF注入#
1.1.15.1 漏洞概述#
CRLF注入即“HTTP响应头拆分漏洞”，主要是由于应用系统在接收用户浏览器发送的参数信息后，参数信息在HTTP响应头中进行了输出并未经过有效的校验，攻击者可提交恶意的参数信息(\r\n)从而对HTTP响应头进行控制。攻击者可通过该漏洞发起web缓存感染、用户信息涂改、窃取敏感用户页面、跨站脚本漏洞等攻击，从而造成普通用户遭受到恶意攻击。

1.1.15.2 修复建议#
限制用户输入的CR和LF，或者对CR和LF字符正确编码后再输出。CR、LF分别对应回车（%0d）、换行（%0a）字符。
1.1.16 命令执行注入#
1.1.16.1 漏洞概述#
命令执行注入主要是由于开发人员在处理应用系统发起操作系统命令时引用了客户端参数，同时没有对该参数进行合法性校验，攻击者可在参数中注入恶意的命令参数，致使执行命令的过程中执行了攻击者所指定的恶意命令。通过该漏洞攻击者可执行任意的操作系统命令，在权限配置不当的情况下可直接获得操作系统的完全控制权限。

1.1.16.2 修复建议#
尽量避免使用exec、system、passthru、popen、shell_exec、eval、execute、assert等此类执行命令/执行代码相关函数。

执行代码/命令的参数，或文件名，不要使用外部获取，禁止和用户输入相关，只能由开发人员定义代码内容，用户只能提交“1、2、3”参数，代表相应代码，防止用户构造。

1.1.17 URL重定向#
1.1.17.1 漏洞概述#
URL重定向主要是由于Web应用系统在处理URL重定向时没有对接收到的URL参数进行合法性校验，攻击者可指定URL路径为恶意URL或恶意域名，当用户访问该URL重定向页面时将可能跳转到攻击者所指定的恶意页面，从而造成用户遭受到恶意代码的攻击。

1.1.17.2 修复建议#
避免使用重定向和转发

如果使用了重定向和转发，则不要在接受目标时涉及到用户参数

如果无法避免使用用户参数，则应确保其提供的值对于当前用户是有效的，并已经授权

确定白名单及网络边界，限定协议以及可访问的网络

1.1.18 Json劫持#
1.1.18.1 漏洞概述#
Json劫持主要是由于网站页面在响应用户请求时采用Json数组的方式进行返回，而该页面没有进行相应的合法判断，攻击者可在恶意网站上构造访问该页面的URL并诱惑用户进行点击访问，最终攻击者可通过Javscript Hook的方式窃取用户在该页面上所返回的Json数组信息，从而造成用户的敏感信息泄露。

1.1.18.2 修复建议#
严格安全的实现 CSRF 方式调用 JSON 文件：限制 Referer 、部署一次性 Token等。

严格按照JSON格式标准输出 Content-Type 及编码（ Content-Type : application/json; charset=utf-8）。

严格过滤 callback 函数名及 JSON 里数据的输出。

严格限制对 JSONP 输出 callback 函数名的长度。

1.1.19 第三方组件安全#
1.1.19.1 漏洞概述#
第三方组件主要包括Ewebeditor、FCKeditor、Ueditor、JQuery等常用第三方组件，开发人员在开发过程中调用第三方组件时并未考虑组件当前的安全状况，攻击者可通过第三方组件上的安全漏洞攻击应用系统，从而影响应用系统自身的安全。

1.1.19.2 修复建议#
无

1.1.20 本地/远程文件包含#
1.1.20.1 漏洞概述#
本地/远程文件包含漏洞主要出现在采用PHP开发的应用系统中，在PHP代码开发过程中较常采用文件包含的方式进行对代码的引用从而提高编码效率以及代码扩展性，被包含的文件内容将被当作php代码进行解析。当所需要包含的文件路径通过客户端浏览器进行提交时，攻击者可指定文件路径到本地或远程的恶意代码文件，应用系统将执行该文件中的恶意代码，最终攻击者可通过该方式获取应用系统的控制权限。

1.1.20.2 修复建议#
保证参数用户不可控/不可构造性。

使用 basename() 函数处理参数。

对所有的变量初始化。

1.1.21 任意代码执行#
1.1.21.1 漏洞概述#
任意代码执行主要是由于应用系统在处理动态代码执行的过程中，部分代码片段可由客户端浏览器提交参数到服务器进行指定，从而攻击者可通过提交恶意的代码参数到服务器，应用系统将执行所提交的恶意代码，最终攻击者可通过该漏洞直接获得应用系统的控制权限。

1.1.21.2 修复建议#
尽量避免使用exec、system、passthru、popen、shell_exec、eval、execute、assert等此类执行命令/执行代码相关函数。

执行代码/命令的参数，或文件名，不要使用外部获取，禁止和用户输入相关，只能由开发人员定义代码内容，用户只能提交“1、2、3”参数，代表相应代码，防止用户构造。

1.1.22 Struts2远程命令执行#
1.1.22.1 漏洞概述#
Struts2远程命令执行主要是由于网站采用较低版本的Strut2框架，该框架低版本在处理远程客户端参数名、参数值、文件名参数等参数内容时没有经过严格的过滤，导致可注入到OGNL表达式中，从而造成任意代码执行漏洞。攻击者可通过构造恶意的OGNL表达式从而实现任意命令执行，最终可通过该漏洞完全获得网站权限甚至操作系统权限。

1.1.22.2 修复建议#
Struts2远程命令执行漏洞涉及多个漏洞编号，如S2-005、S2-008、S2-009、S2-016、S2-020、S2-029、S2-032、S2-037、S2-045、S2-046、S2-052、S2-055等等，根据实际情况，建议升级Struts2框架至最新版本即可。如：

系统存在S2-016 Struts2远程命令执行漏洞，建议升级升级Struts2框架至最新版本。

1.1.23 Spring远程命令执行#
1.1.23.1 漏洞概述#
Spring远程命令执行主要是由于网站采用较低版本的Spring框架，该框架低版本在处理Spring标签时没有进行合法性校验，导致可将标签内容信息注入到表达式中，从而造成任意代码执行漏洞。攻击者可通过构造恶意的标签内容到表达式从而实现任意命令执行，最终可通过该漏洞完全获得网站权限甚至操作系统权限。

1.1.23.2 修复建议#
该漏洞为Spring标签EL表达式注入，CVE编号为CVE-2011-2730。

建议升级Spring至Spring3.1以后版本，或修改web.xml配置关闭对EL表达式的支持：

Spring Expression Language SupportspringJspExpressionSupportfalse

1.1.24 反序列化命令执行#
1.1.24.1 漏洞概述#
反序列化命令执行主要是由于应用系统在通过反序列的方式处理字节序列时没有对该序列信息进行校验，攻击者可伪造恶意的字节序列并提交到应用系统时，应用系统将对字节序列进行反序列处理时将执行攻击者所提交的恶意字节序列，从而导致任意代码或命令执行，最终可完成获得应用系统控制权限或操作系统权限。

1.1.24.2 修复建议#
无

1.2 业务逻辑安全#
1.2.1 用户名枚举#
1.2.1.1 漏洞概述#
在应用系统登录过程中，当输入错误的用户名信息时，应用程序将反馈相应的诸如“用户不存在”的错误提示，攻击者可通过该提示为依据进行对用户名的枚举，猜解出已存在于应用系统的用户名信息，最终攻击者可进行一步发起对已有用户的密码猜解。

1.2.1.2 修复建议#
模糊登陆错误信息，对用户名错误及密码错误均提示”用户名或密码错误，请重新输入”。

户登录后需要对初始口令进行修改，防止攻击者利用初始口令进行暴力破解。

系统设置强密码策略，建议用户密码采用10位以上数字加大小写字母。

对密码暴力猜解行为进行图灵验证，一旦发现用户口令破解行为及时对账户进行限时封停处理。

1.2.2 用户密码枚举#
1.2.2.1 漏洞概述#
在应用系统登录过程中，由于并未限制用户的密码输入错误次数，攻击者可通过密码字典不断枚举指定用户的密码信息，最终用户密码将可能遭受到破解，攻击者可通过所破解的用户密码进入应用系统并发起进一步的攻击。

1.2.2.2 修复建议#
模糊登陆错误信息，对用户名错误及密码错误均提示”用户名或密码错误，请重新输入”。

用户登录后需要对初始口令进行修改，防止攻击者利用初始口令进行暴力破解。

系统设置强密码策略，建议用户密码采用10位以上数字加大小写字母。

对密码暴力猜解行为进行图灵验证，一旦发现用户口令破解行为及时对账户进行限时封停处理。

1.2.3 用户弱口令#
1.2.3.1 漏洞概述#
由于应用系统的相关用户的安全意识薄弱，同时应用系统并未有效的强制性密码策略要求，从而将可能存在弱口令用户，攻击者可轻易通过字典猜解的方式获得用户的密码并进入应用系统发起进一步攻击。

1.2.3.2 修复建议#
用户登录后需要对初始口令进行修改，防止攻击者利用初始口令进行暴力破解。

系统设置强密码策略，建议用户密码采用10位以上数字加大小写字母。

对密码暴力猜解行为进行图灵验证，一旦发现用户口令破解行为及时对账户进行限时封停处理。

1.2.4 网站后台弱口令#
1.2.4.1 漏洞概述#
由于网站后台管理员密码强度低，容易被攻击者暴力破解。攻击者可利用弱口令获得网站管理员权限，进入网站后台，严重者可导致服务器沦陷

1.2.4.2 修复建议#
用户用户登录后需要对初始口令进行修改，防止攻击者利用初始口令进行暴力破解。

系统设置强密码策略，建议用户密码采用10位以上数字加大小写字母。

对密码暴力猜解行为进行图灵验证，一旦发现用户口令破解行为及时对账户进行限时封停处理。

1.2.5 会话标志固定攻击#
1.2.5.1 漏洞概述#
应用系统在用户登录成功或登录失败后并未对当前的会话标志（Session ID）进行更新，从而攻击者可构造一个未登录且带有Session ID的URL并发送到用户，用户点击该URL并进行登录成功后，攻击者可通过该Session ID冒充用户并成功进入应用系统，从而可进一步发起对应用系统的攻击。

1.2.5.2 修复建议#
用户登录成功后重新创建一个Sesssion ID，并销毁该用户之前登陆使用的Sesssion ID。

限制Sesssion ID的时效性，一段时间后销毁Sesssion ID。

添加其他认证因素，如User-Agent验证及Token校验等。

1.2.6 平行越权访问#
1.2.6.1 漏洞概述#
应用系统在处理同一业务功能数据时，并未对数据与当前用户的权限进行合法性校验，从而导致用户可越权访问、篡改、删除、添加其他用户的信息，造成越权操作。常见如：访问任意用户订单、修改任意用户密码、删除任意用户信息等。

1.2.6.2 修复建议#
对于每个功能的访问，需要明确授予特定角色的访问权限。

如果某功能参与了工作流程，检查并确保当前的条件是授权访问此功能的合适状态。

1.2.7 垂直越权访问#
1.2.7.1 漏洞概述#
应用系统在处理各个角色业务功能时，并未对当前用户角色与该业务功能的权限标志进行判断，导致用户可越权访问非自身权限范围内的业务功能，造成越权操作。常见如：越权添加、修改、删除用户以及权限、越权访问系统管理功能等。

1.2.7.2 修复建议#
对于每个功能的访问，需要明确授予特定角色的访问权限。

如果某功能参与了工作流程，检查并确保当前的条件是授权访问此功能的合适状态。

1.2.8 未授权访问#
1.2.8.1 漏洞概述#
应用系统对业务功能页面并未进行有效的身份校验，在未登录且获知业务功能页面的访问地址前提下，可直接操作该页面下的功能，将可能对应用系统的恶意破坏。

1.2.8.2 修复建议#
对于每个功能的访问，需要明确授予特定角色的访问权限。

如果某功能参与了工作流程，检查并确保当前的条件是授权访问此功能的合适状态。

1.2.9 登录绕过漏洞#
1.2.9.1 漏洞概述#
由于对登录的账号及口令校验存在逻辑缺陷，或再次使用服务器端返回的相关参数作为最终登录凭证，导致可绕过登录限制，如服务器返回一个flag参数作为登录是否成功的标准，但是由于代码最后登录是否成功是通过获取这个flag参数来作为最终的验证，导致攻击者通过修改flag参数即可绕过登录的限制！

1.2.9.2 修复建议#
修改验证逻辑，如是否登录成功服务器端返回一个参数，但是到此就是最终验证，不需要再对返回的参数进行使用并作为登录是否成功的最终判断依据！

1.2.10 验证码缺陷#
1.2.10.1 漏洞概述#
常见于应用系统在登录处理流程过程中，当用户登录失败后并未对当前验证码进行注销并重新刷新验证码，攻击者可至始至终提交初始的验证码发起攻击穷举攻击；同时部分应用系统验证码只在客户端浏览器验证，并未经过服务器远程验证，将可能存在绕过验证码缺陷，另一方面，在生成或获取验证码的过程中存在缺陷，攻击者将可能成功预测验证码内容或直接解析验证码内容，从而使验证码失去原有意义，最终导致一系列的穷举或遍历数据攻击。

1.2.10.2 修复建议#
验证码使用一次后，立即销毁该验证码Session，防止验证码被多次使用。

对验证码添加干扰线，对验证码字符随机扭曲、粘连、翻转等处理。

1.2.11 任意注册他人手机号#
1.2.11.1 漏洞概述#
任意注册他人电话号码，先burp抓包，然后改成自己的电话号码，就会收到本该发给别人的验证码，由此成功注册他人手机号

1.2.11.2 修复建议#
无

1.2.12 短信轰炸#
1.2.12.1 漏洞概述#
由于没有对短信或者邮件发送次数进行限制，在测试的过程中，对短信验证码接口进行重放，导致可无限次发送短信或邮件给用户，造成短信轰炸，进而可能被大量用户投诉，从而影响公司声誉！

1.2.12.2 修复建议#
限制每个手机号的每日发送次数，超过次数则拒发送，提示超过当日次数。

每个ip限制最大限制次数。超过次数则拒发送，提示超过ip当日发送最大次数。

后台限制每个手机号发送的时间间隔，不允许频繁操作。

1.3 中间件安全#
1.3.1 中间件安全监测#
1.3.1.1 漏洞概述#
中间件配置缺陷主要是由于开发人员或运维人员在安装部署中间件后，并未对默认的中间件配置进行安全加固，导致产生一系列诸如目录遍历、默认示例文件、错误信息泄露等缺陷，从而导致应用系统产生信息泄露隐患。

1.3.1.2 修复建议#
设置自定义错误跳转页，避免非200响应状态返回默认错误信息

关闭调试信息、中间件版本信息等敏感信息的显示

1.3.2 第三方插件检测#
1.3.2.1 漏洞概述#
第三方插件主要使用在CMS网站（内容管理系统）中，由于一些插件的安装量较大，且不需要认证或者对服务器进行操作，攻击者可利用插件中的安全漏洞攻击网站，例如SQL注入、文件上传等漏洞，从而导致攻击者可能获得数据库服务器的完全控制权限。

1.3.2.2 修复建议#
设置自定义及时更新插件版本

不使用非正规渠道下载的插件

1.3.3 默认配置文件检测#
1.3.3.1 漏洞概述#
默认配置文件常见于系统或软件安装后默认生成的文件，由于这些文件中包含大量文件或系统的敏感信息，若被攻击者窃取，可造成敏感信息泄露，从而导致服务器被渗透的风险。

1.3.3.2 修复建议#
设置自删除不必要的配置文件

设置文件访问权限

1.3.4 常见冗余文件检测#
1.3.4.1 漏洞概述#
冗余文件常见于开发人员或管理员进行备份管理的文件，其中包含大量网站信息和数据库信息，由于文件存在于服务器中，若被攻击者窃取，可通过分析源码，拿到服务器权限。

1.3.4.2 修复建议#
设置自删除服务器中的冗余文件

设置文件访问权限

1.3.5 系统层漏洞（CVE风险漏洞）检测#
1.3.5.1 漏洞概述#
根据互联网中发布的CVE漏洞报告，攻击者可分析漏洞原理，使用脚本写出POC进行批量攻击。常见CVE漏洞如：远程命令执行、反序列化等

1.3.5.2 修复建议#
设置自及时更新系统补丁

根据官网中的漏洞修复方案进行修复

1.3.6 中间件配置缺陷#
1.3.6.1 漏洞概述#
中间件配置缺陷主要是由于开发人员或运维人员在安装部署中间件后，并未对默认的中间件配置进行安全加固，导致产生一系列诸如目录遍历、默认示例文件、错误信息泄露等缺陷，从而导致应用系统产生信息泄露隐患。

1.3.6.2 修复建议#
设置自定义错误跳转页，避免非200响应状态返回默认错误信息

关闭调试信息、中间件版本信息等敏感信息的显示

1.3.7 中间件弱口令#
1.3.7.1 漏洞概述#
中间件弱口令主要是由于开发人员或运维人员在部署中间件过程中，并未对中间件控制台进行口令配置或修改默认口令，从而攻击者可通过穷举猜解的方式进行中间件控制台，最终攻击者可通过控制台上传恶意脚本并获得应用系统权限。

1.3.7.2 修复建议#
用户登录后需要对初始口令进行修改，防止攻击者利用初始口令进行暴力破解。

系统设置强密码策略，建议用户密码采用10位以上数字加大小写字母。

对密码暴力猜解行为进行图灵验证，一旦发现用户口令破解行为及时对账户进行限时封停处理。

1.3.8 Webloigc反序列化命令执行#
1.3.8.1 漏洞概述#
由于Weblogic版本并未进行及时更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令执行漏洞，攻击者可远程构造恶意的字节序列发送到服务器端并执行，通过该漏洞攻击者可直接获得应用系统控制权限甚至操作系统权限。

1.3.8.2 修复建议#
Weblogic控制台端口(默认TCP 7001)迁移至内网，不对互联网开放。

Webloigc Java反序列化漏洞涉及多个CVE编号：CVE-2015-4852、CVE-2016-0638、CVE-2016-3510、CVE-2017-3248、CVE-2017-3506、CVE-2017-10352等，安装相应补丁即可，或更新Weblogic至最新版。

1.3.9 Jboss反序列化命令执行#
1.3.9.1 漏洞概述#
由于Jboss版本并未进行及时更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令执行漏洞，攻击者可远程构造恶意的字节序列发送到服务器端并执行，通过该漏洞攻击者可直接获得应用系统控制权限甚至操作系统权限。

1.3.9.2 修复建议#
JBoss控制台端口（默认TCP 8080）迁移至内网，不对互联网开放。

修改默认配置，关闭 EJB Invoker/JMXInvokerServlet对外开放接口。

升级JBoss至最新版。

1.3.10 Websphere反序列化命令执行#
1.3.10.1 漏洞概述#
由于Websphere版本并未进行及时更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令执行漏洞，攻击者可远程构造恶意的字节序列发送到服务器端并执行，通过该漏洞攻击者可直接获得应用系统控制权限甚至操作系统权限。

1.3.10.2 修复建议#
Qwer1、该漏洞Weblogic官方已经发布补丁，建议升级Weblogic至最新版。

1.3.11 Jenkins反序列命令执行#
1.3.11.1 漏洞概述#
由于Jenkins版本并未进行及时更新，在低版本中的Commoncollections.jar程序包中存在反序列化命令执行漏洞，攻击者可远程构造恶意的字节序列发送到服务器端并执行，通过该漏洞攻击者可直接获得应用系统控制权限甚至操作系统权限。

1.3.11.2 修复建议#
Jenkins Java反序列化漏洞涉及多个CVE编号：

CVE-2015-4852

CVE-2015-8103

CVE-2016-0792

CVE-2017-1000353

CVE-2017-1000354

CVE-2017-1000355

CVE-2017-1000356等等，安装相应补丁即可，或更新Jenkins至最新版。

1.3.12 JBoss远程代码执行#
1.3.12.1 漏洞概述#
由于Jboss版本未进行及时更新，在低版本中存在未授权访问漏洞从而可直接访问EJBInvokerServlet 或 JMXInvokerServlet功能模块，通过该功能模块攻击者可远程部署恶意的WAR应用程序包，最终攻击者可成功部署恶意代码到应用系统服务器上，从而获得应用系统权限。

1.3.12.2 修复建议#
无

1.3.13 文件解析代码执行#
1.3.13.1 漏洞概述#
由于网站所采用的中间件版本过低，不同的低版本中间件均存在文件解析执行漏洞，攻击者可直接上传包含恶意代码的图片文件或压缩文件到网站服务器上，该图片或压缩文件将以动态脚本代码的方式进行解析并执行，最终攻击者可通过执行恶意代码获得网站的控制权限。

1.3.13.2 修复建议#
IIS6解析漏洞修复建议：

IIS6微软已经不在维护，建议升级IIS至IIS8或更高版本。

IIS7.0/7.5解析漏洞修复建议：

修改php.ini中cgi.pathinfo为0，并重启IIS。

在IIS里找到“处理程序映射”，然后对PHP这一项进行编辑，点击“请求限制”，勾选“仅当请求映射至以下内容时才调用处理程序”。

Nginx解析漏洞修复建议：

升级Nginx版本

修改php.ini文件，将cgi.fix_pathinfo的值设置为0。完成后请重启PHP和Nginx。

Apache解析漏洞修复建议：

在httpd.conf或httpd-vhosts.conf中加入以下语句，从而禁止文件名格式为.php.的访问权限：

<FilesMatch ".(php.|php3.|php4.|php5.)">

Order Deny,Allow

Deny from all

1.3.14 HTTP.sys远程代码执行漏洞#
1.3.14.1 漏洞描述:#
远程代码执行漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中，当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。若要利用此漏洞，攻击者必须将经特殊设计的 HTTP 请求发送到受影响的系统。

1.3.14.2 修复建议:#
更新补丁KB3042553

1.4 服务器安全#
1.4.1 域传送漏洞#
1.4.1.1 漏洞概述#
域传送漏洞主要由于DNS服务器开启了域传送功能，同时并未采用有效的白名单机制指定域传送的传送范围，导致攻击者可远程获得DNS服务器上的DNS记录，造成网站的域名以及IP地址信息的泄露。

1.4.1.2 修复建议#
DNS区域传送（DNS zone transfer）指的是一台备用服务器使用来自主服务器的数据刷新自己的域（zone）数据库。这为运行中的DNS服务提供了一定的冗余度，其目的是为了防止主的域名服务器因意外故障变得不可用时影响到整个域名的解析。一般来说，DNS区域传送操作只在网络里真的有备用域名DNS服务器时才有必要用到，但许多DNS服务器却被错误地配置成只要有client发出请求，就会向对方提供一个zone数据库的详细信息，所以说允许不受信任的因特网用户执行DNS区域传送（zone transfer）操作是后果最为严重的错误配置之一。解决域传送问题只需allow-transfer限制可以进行同步的服务器，方式有两种，限制IP或使用TSIG key认证：

针对于bind软件，可以通过allowe-transfer指令来控制，

可以作为global选项或者zone选项的一个参数，我们可以使用地址列表如下：

allowe-transfer ｛192.168.1.1; 172.24.123.253;｝;

采用TSIG key来严格定义区域传送的关系，如下

allowe-transfer ｛key "dns1-slave1"; key "dns1-slave2";｝;

1.4.2 Redis未授权访问#
1.4.2.1 漏洞概述#
Redis未授权访问主要是由于默认安装的情况下并未对Redis配置身份校验功能，导致攻击者可非法访问Redis下的数据信息，同时可进一步通过配置文件功能对服务器文件进行写入，如写入SSH密钥或计划任务，从而获得服务器的控制权限。

1.4.2.2 修复建议#
以低权限运行Redis服务，严禁使用root用户等高权限用户运行Redis服务

为Redis添加密码验证

修改redis.conf，添加

requirepass mypassword

禁止外网访问Redis

修改redis.conf，添加或修改，使得Redis服务只在当前主机可用

bind 127.0.0.1

1.4.3 Pivotal Software Redis<2.8.21/3.x/3.0.2 RCE#
1.4.3.1 漏洞概述#
远程主机上安装的Redis版本受远程代码执行漏洞的影响。攻击者可以通过eval命令利用这个问题来执行任意Lua bytecote。

1.4.3.2 修复建议#
建议更新到Redis 2.8.21 / 3.0.2或更高版本。
1.4.4 MangoDB未授权访问#
1.4.4.1 漏洞概述#
MangoDB未授权访问主要是由于默认安装的情况下并未对MangoDB配置身份校验功能，导致攻击者可非法访问MangoDB下的数据信息，从而造成MangoDB中的数据库信息泄露。

1.4.4.2 修复建议#
修改默认的 MongoDB 端口(默认为: TCP 27017)为其他端口

禁止外网访问 MongoDB

修改 /etc/mongodb.conf，设置 bind_ip

bind_ip = 127.0.0.1

禁用 HTTP 和 REST 端口

MongoDB 自身带有一个 HTTP 服务和并支持 REST 接口。在 2.6 以后这些接口默认是关闭的。MongoDB 默认会使用默认端口监听 Web 服务，一般不需要通过 Web 方式进行远程管理，建议禁用。修改配置文件或在启动的时候选择 –nohttpinterface 参数：nohttpinterface = false

MongoDB 授权

在 admin 数据库中创建用户，并设置强密码，修改配置文件 /etc/mongodb.conf，开启授权：

auth = true

1.4.5 操作系统弱口令#
1.4.5.1 漏洞概述#
操作系统弱口令主要由于运维管理员的安全意识薄弱，对管理员账号设置了简单密码，攻击者可通过字典穷举的方式破解管理员密码并完全获得服务器控制权限。

1.4.5.2 修复建议#
用户登录后需要对初始口令进行修改，防止攻击者利用初始口令进行暴力破解。

系统设置强密码策略，建议用户密码采用10位以上数字加大小写字母。

对密码暴力猜解行为进行图灵验证，一旦发现用户口令破解行为及时对账户进行限时封停处理。

1.4.6 数据库弱口令#
1.4.6.1 漏洞概述#
数据库弱口令主要由于运维管理员的安全意识薄弱，对数据库管理员账号设置了简单密码，攻击者可通过字典穷举的方式破解管理员密码并完全获得数据库控制权限。在特定场景下，攻击者可通过数据库权限进行权限提升，从而进一步获得数据库所在服务器的控制权限。

1.4.6.1 修复建议#
用户登录后需要对初始口令进行修改，防止攻击者利用初始口令进行暴力破解。

系统设置强密码策略，建议用户密码采用10位以上数字加大小写字母。

对密码暴力猜解行为进行图灵验证，一旦发现用户口令破解行为及时对账户进行限时封停处理。

1.4.7 数据库结构泄露#
1.4.7.1 漏洞概述#
数据库结构泄露主要是由于开发人员或运维管理人员的疏忽所导致。如未及时删除调试页面、未关闭程序调试功能、未屏蔽程序错误信息、备份文件未删除、数据库备份文件未删除、未屏蔽敏感数据信息等多个方面所导致的不同严重程度的信息泄露。攻击者可通过所掌握的信息进一步分析攻击目标，从而有效发起下一步的有效攻击。

1.4.7.2 修复建议#
关闭错误输出，防止调试信息泄露，或者当web应用程序出错时，统一返回一个错误页面或直接跳转至首页

合理设置服务器端各种文件的访问权限

1.4.8 本地权限提升#
1.4.8.1 漏洞概述#
本地权限提升漏洞主要是由于服务器没有及时更新操作系统补丁、数据库补丁或其他第三方应用程序补丁，导致攻击者可利用存在的安全缺陷或配置缺陷进行普通权限到最高权限的权限提升，最终可直接获得服务器的最高权限。

1.4.8.2 修复建议#
无

1.4.9 已存在的脚本木马#
1.4.9.1 漏洞概述#
在渗透测试过程中发现非渗透测试人员所上传的脚本木马，主要是攻击者此前对应用系统发起了攻击并成功上传脚本木马并获得了相应的权限。

1.4.9.2 修复建议#
删除后门程序、对网站目录进行后门查杀

查看Web日志，进行攻击溯源

1.4.10 应用防护软硬件缺陷#
1.4.10.1 漏洞概述#
应用防护软硬件缺陷主要是由于第三方安全产品在安全设置或安全策略存在安全缺陷，导致攻击者可通过特定的方式绕过该安全产品的防护策略，从而突破防护进一步发起对应用系统的攻击。

1.4.10.2 修复建议#
无

1.4.10 Host头攻击#
1.4.10.1 漏洞描述#
Host首部字段是HTTP/1.1新增的，旨在告诉服务器，客户端请求的主机名和端口号，主要用来实现虚拟主机技术。

运用虚拟主机技术，单个主机可以运行多个站点。

例如：hacker和usagidesign两个站点都运行在同一服务器A上，不管我们请求哪个域名，最终都会被解析成服务器A的IP地址，这个时候服务器就不知道该将请求交给哪个站点处理，因此需要Host字段指定请求的主机名。

我们访问hacker域名，经DNS解析，变成了服务器A的IP，请求传达到服务器A，A接收到请求后，发现请求报文中的Host字段值为hacker，进而将请求交给hacker站点处理。

这个时候，问题就出现了。为了方便获取网站域名，开发人员一般依赖于请求包中的Host首部字段。例如，在php里用_SERVER["HTTP_HOST"]，但是这个Host字段值是不可信赖的(可通过HTTP代理工具篡改)。

1.4.10.2 修复建议#
对Host字段进行检测

Nginx，修改ngnix.conf文件，在server中指定一个server_name名单，并添加检测。

Apache，修改httpd.conf文件，指定ServerName，并开启UseCanonicalName选项。

Tomcat，修改server.xml文件，配置Host的name属性。

转载地址：https://security.pingan.com/blog/17.html